How does Linux TCP stack handle invalid ACK sequence numbers?

0
votes

I'm just debugging a very strange issue with mobile client getting stuck while downloading a file from my HTTP server. The client is running on a Sierra Wireless Q2687 GSM module.

Each time the transmission hangs after exactly 13480 bytes (10 packets, 1348 worth of payload each). I only see this problem with the GSM module mentioned above, other clients work well.

I've done some Wireshark debugging to note the following:

  • last packet from server to client has a (relative) sequence number of 12133 with 1348 bytes of payload
  • client then ACKs the packet, sending ACK sequence number of 13482, which is off-by-one compared to expected 12133 + 1348 = 13481
  • after that ACK, server sends no more packets at all and connection is stuck (I'm sure nginx has more data to send, checked).

So, for me it looks like a Sierra Wireless TCP stack off-by-one bug - ACK'ing more data that has actually been received.

Questions:

  • can anyone confirm, that ACK'ing with sequence number higher than the highest (received sequence number + length) violates the TCP specification?

  • given the above is true, how does Linux TCP stack handle such a situation? (TCP stack source code is a bit hard to follow without prior experience, so pointers to particular checks in the source code are more than welcome).

1
linuxtcp
If you don't get an answer here, maybe also try linux.stackexchange.com - Peter Cordes

1 Answers

1
votes

can anyone confirm, that ACK'ing with sequence number higher than the highest (received sequence number + length) violates the TCP specification?

If a packet has a FIN flag set then the ACK to the packet will be sequence+1. So it might just be that you've missed this flag. This would also explain that you don't see any more data because FIN means that no more data will follow (i.e. end of connection).

If there was no FIN flag than this would indeed be invalid and I assume that the kernel would simply discard the invalid ACK.