1

We have an apache server that hosts firmware files for some embedded devices. These files are not very large, only about 160kb. The embedded devices use an EDGE mobile connection to connect to this server and download an update when needed. The problem we are having is that there is a software bug in some of this devices that causes high packet loss. If the network connection is really good, the devices will manage to download the file and update. The problem is in most cases this doesn't happen.

I don't think the packet loss is caused by the network because the download always begins well. After about 4KB, when the device starts writing the data to flash and the connection slows to a crawl and never recovers. Normally this slowdown should be temporary, once the data is saved the download speed should improve.

Looking at the network traffic packets are still being sent by both sides but there are losses and the server just spends most of the time waiting for acknowledgment.

I was wondering if there is any way to force the server to resend the packets more often. I've tried changing the tcp congestion control to westwood but it doesn't help. Is there any setting in the web server (any web server) that could do this? Or maybe a way to write our own for this purpose? This is just a temporary solution until we update the buggy devices.

sorin.silaghi
  • 131
  • 1
  • 4
  • 1
    AFAIK retransmission of lost TCP packets isn't done at the application layer by your webserver, but at the OS level in your TCP stack and depending on your OS there are more settings than just the congestion control algorithm. – HBruijn Aug 24 '17 at 09:28
  • @HBruijn could you point me to these settings? We're running Ubuntu 14.04 on the server, although, if needed, I could install a server just for this with any OS. – sorin.silaghi Aug 24 '17 at 09:42
  • 1
    Yeah. If you have a broken network, fix it - standard technologies can not handle this. You decided to use a standard technology. In this csae you would best need your own download protocol which is UDP based and especially prepared to handle this type of broken environment. – TomTom Aug 24 '17 at 10:13
  • `tcp_retries1` & `tcp_retries2` might be what you're after https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt – HBruijn Aug 24 '17 at 10:18
  • @TomTom none of this was my decision and I can't change the protocol if I can't update the firmware. So far the only option for doing that is a recall and the customer is not exactly keen on it. – sorin.silaghi Aug 24 '17 at 10:54
  • Then you are stuck. Problem is that no web server setting will handle this type of TCP problem and TCP is not designed for that type of extreme loss scenarios. This is a recall and blame whoever failed Qality Control scenario - there is nothing you can do here. – TomTom Aug 24 '17 at 10:56

0 Answers0