ISP malpractices

This thing is followed my almost all local cable operators across India..
Dont find anything fishy here.

Data Caching for faster results is much more equivalent to same ??
 
This was being done by an ISP in North India as well - I am not sure, but I was getting a response from Google DNS, but records were being fetched extremely slowly and sometimes, getting timeouts. In the end, we terminated the contract.[DOUBLEPOST=1520055622][/DOUBLEPOST]The reason the ISPs do this is to try to save on bandwidth costs. They have no idea what they are doing is technically breaking the internet.

Additionally, some ISPs (again mainly the same ISP from North India) show speedtests to convince that they are fast or there is no issue from their end. At this, I ask them to show ping tests.
 
run a ping test to the following

Google DNS (8.8.8.8, 8.8.4.4)

See what is the response. This is an ICMP ping. If it is less 30ms, either you have a very good ISP (usually in India these do not exist) or a very bad ISP who is screwing around with you.

If you want to still check, run TCP and UDP ping as well, the difference should not be more than the earlier ping +/- 20%, usually. Ensure this is done when traffic usage is lowest.[DOUBLEPOST=1520071562][/DOUBLEPOST]As for the dumbing down -

Basically, the ISP is doing a man in the middle attack, if you want to call it that.

You are wanting to get a response from 8.8.8.8 and he is doing a conversion to his local IP and giving a response back from that local IP to you saying that it is from 8.8.8.8

In short, he is masquerading as that particular IP.
 
Last edited:
Hathway did a similar thing for me. When I downloaded an Ubuntu distro from an obscure but official http server, I got 150mbit/s meaning that was being downloaded from cache. Whereas normal connection to that country gave me 10mbit/s in Hathway. I don't thing it is proper for ISP to judge the file from the url and dl it from cache?
 
Here is a comparison of Airtel ADSL vs Comcast cable.

Comcast
Code: 
# mtr -n -r -c 100 8.8.8.8
Start: Sat Mar  3 17:22:30 2018
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                 0.0%   100    0.3   0.2   0.2   0.8   0.0
  2.|-- 96.120.xx.xx                0.0%   100    8.0   8.3   6.2  26.0   2.8
  3.|-- 69.139.210.5               0.0%   100   10.1  10.7   5.9  41.1   4.3
  4.|-- 68.85.244.81               0.0%   100    8.1  10.4   6.1  39.6   4.8
  5.|-- 68.86.92.61                0.0%   100   14.4  15.5   9.0  43.8   4.3
  6.|-- 68.86.85.194               0.0%   100   13.2  13.6   9.3  23.4   1.4
  7.|-- 66.208.228.66              0.0%   100   12.8  14.4   9.7  35.9   3.7
  8.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  9.|-- 108.170.229.115            0.0%   100   15.4  14.9   9.3  51.6   4.1
 10.|-- 8.8.8.8                    0.0%   100   12.4  13.6   8.6  31.5   2.5

Airtel
Code: 
# mtr -n -r -c 100 8.8.8.8
Start: Sun Mar  4 04:56:20 2018
HOST:                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   100    0.3   0.2   0.2   0.7   0.0
  2.|-- 122.169.xx.xx               0.0%   100   27.1  28.9  26.0  53.0   5.3
  3.|-- 59.145.160.65              0.0%   100   28.0  27.8  26.1  44.0   1.7
  4.|-- 182.79.198.218             0.0%   100   81.1  81.6  78.5 116.6   6.3
  5.|-- 72.14.197.166              0.0%   100   79.3  80.1  78.5  95.1   1.6
  6.|-- 74.125.242.146             0.0%   100   82.2  82.0  80.4  89.0   1.1
  7.|-- 209.85.248.251             0.0%   100  114.7 116.6 112.4 154.2   8.5
  8.|-- 216.239.51.61              0.0%   100  111.5 114.1 110.9 130.1   4.5
  9.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0

Both have similar number of hops. But Airel traversal over the big pond takes its toll on latency.
 
Last edited:
Was testing another ISP - WNET (My current ISP. Rajesh Hathway is refusing static IP)

Guess what -

ping times to 8.8.8.8 are in the ~ 60 ms range. But for 8.8.4.4, they are 3ms!

So a bit of sleuthing and voila, they seem to be using some caching. Bloody buggers. I have half a mind to cancel the connection.

upload_2018-3-4_20-10-27.png


upload_2018-3-4_20-12-33.png


upload_2018-3-4_20-12-42.png


EDIT

Weirdly, checked with multiple ISPs, and all of them are reporting lesser times to 8.8.4.4 compared to 8.8.8.8

Can anyone check with ISPs other than these and revert?

Hathway/WNET/Joister/Jio
 
Last edited:
Reply from 8.8.8.8: bytes=32 time=92ms TTL=47

Reply from 8.8.4.4: bytes=32 time=2ms TTL=60

ISP is Spectranet (1Gbps)
 
Code: 
@desktop ~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=63.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=63.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=63.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=63.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=62.9 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 62.994/63.455/63.764/0.385 ms
@desktop ~ $ ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=59 time=3.71 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=59 time=3.62 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=59 time=4.01 ms
64 bytes from 8.8.4.4: icmp_seq=4 ttl=59 time=3.69 ms
64 bytes from 8.8.4.4: icmp_seq=5 ttl=59 time=3.73 ms
^C
--- 8.8.4.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 3.620/3.758/4.018/0.135 ms
@desktop ~ $
 
Back
Top