Resumable Downloads corruption due to ISP redirection

2

I have a Bsnl bradband connection in India.

Whenever I turn on router and open any link the first time, it gets redirected to mail.bsnl.in page. That could be a way of promoting their email service. The Broadband service is poor with many signal drops specially in rainy season. Whenever a signal drop occurs and connection gets resetted, such webpage redirection occurs.

And the redirection isn't restricted to browser. I use linux distro and do apt-get update && apt-get upgrade frequently. When the connection gets resetted the partial downloads are meant to be resumable when reconnected. But since redirection occurs system wide, the downloads are redirected and are overwritten by a small html file with html headers and link containing mail.bsnl.in.

I got a lot of big files corrupted in this way. How can I prevent this?

Bharat G

Posted 2015-08-30T07:28:09.847

Reputation: 524

Answers

1

nKn may have been more pessimistic than need be. He took seriously your comment that

And the redirection isn't restricted to browser. I use linux distro and do apt-get update && apt-get upgrade frequently. When the connection gets resetted the partial downloads are meant to be resumable when reconnected.

The reason why this is unlikely to be relevant is that apt-get contacts an http site, i.e. a site on port 80: this is an excerpt from my `/etc/apt/sources.list} file:

 deb http://us.archive.ubuntu.com/ubuntu/ trusty main restricted
 deb-src http://us.archive.ubuntu.com/ubuntu/ trusty main restricted
 deb http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
 deb-src http://us.archive.ubuntu.com/ubuntu/ trusty-updates main restricted

which shows exactly this.

This is relevant because it means not all ports and/or protocols need be intercepted by your ISP. The reason why I am saying this is that doing so is a very heavy burden on their infrastructure.

What is generally done to keep the amount of traffic to analyze manageable is to intercept DNS requests, which precede most communication attempts, for obvious reasons. Their firewall can identify DNS requests based upon either port or protocol, or, most likely, both.

There is a way to circumvent this, and it is to use dnscrypt, a very valuable tool provided by OpenDNS. The Web page has links for the Windows and MacOS versions of the package, while for Linux you will find it in your distro's repos.

The advantage of dnscrypt is that it both uses a non-standard port, and it encrypts communication with your DNS server, so that firewalls cannot identify the nature of your connection attempt. You may choose your DNS servers freely, they provide several options besides their own, OpenDNS.

This may or may not work, but it is certainly worth a try.

The reason why it might not work is that your ISP may have setup a timer, so that, if your line is quiet longer than a fixed amount of time, then all communications are blocked, irrespective of port/protocol, and whatnot. This would be a very aggressive move, but some ISPs are not used to competent users.

What you may do in that case is to write a simple shell script, myping.sh, containing the following lines,

 #!/bin/bash
 ping -c1 8.8.8.8

make it executable,

 chmod 755 myping.sh

and have it execute automatically every minute by adding this line

  * * * * * /path/to/myping.sh

to your crontab, by means of the command:

   crontab -e

This will consume a trivial amount of bandwidth, and will keep your connection alive all of the time.

MariusMatutiae

Posted 2015-08-30T07:28:09.847

Reputation: 41 321

0

Unfortunately, I'm afraid there's not much you can do in this case. Using a proxy, TOR, forwarding requests to a different server, changing your DNS servers etc. won't help since the very first hop in your request will be your ISP, so you cannot change the behavior of the first request upon a reconnection.

A "poorman" and very rudimentary workaround would be having a script in a linux box that would do a wget to some website (e.g., http://www.google.com) every minute and forward the result to /dev/null, so if your link disconnects and reconnects you would just notice the redirect within the first minute, otherwise you wouldn't notice anything.

There are some other evident solutions, as complaining to your ISP for such behavior or changing your ISP, but that latter depends on your circumstances.

nKn

Posted 2015-08-30T07:28:09.847

Reputation: 4 960