Hi Guys,

I am dealing with WLAN on embedded Linux (mobile device). Sometimes the RF connection is lost, but that's ok since things like that tend to happen with wireless techniques. :-) After the connection is back, the mobile device tries to re-connect to the server via TCP. And most of the times, this works fine as well.

But in some cases it took very long until the device was connected via TCP again. On Wireshark I saw that the device sends "SYN" and after let's say 100ms receives a "SYN-ACK" from the server. That's fine so far. But now, instead of sending the required "ACK" back to the server (in order to finish TCP channel buildup), it sends a RST packet nearly immediately. Sometimes in even less than 4ms after receiving SYN-ACK.

In another linux forum I found something quite similar, but that guy had the "PUSH" bit set in SYN-ACK from the server, and somebody claimed that this must not be the case in packets which don't contain data. In my case the PUSH bit is definitely not set in neither SYN packets.

Some other people mentioned that this could be "by design" regarding some timers inside TCP. But I cannot imagine that TCP could be designed so poorly. I also looked at the TCP "variables" in /proc/sys/net/ipv4/tcp_* but didn't find anything suitable.

I must admit that I'm using quite an old Monta Vista linux stack. So maybe there is already a solution of which I don't know.

I would greatly appreciate your help, since this is a customer issue and they are already getting angry about this. ;-)

Thanks a lot!

Bernd

How do customer complaints normally get handled in a situation like this? I'd think you would want to reproduce the problem in your testing environment (which it sounds like you have). What next? Can you test with a newer Linux installation to see if the issue is resolved? And, if so, come up with a bug fix deployment plan?

The behavior you're describing doesn't sound normal to me. I wouldn't expect a tcp handshake to time out after 4 milliseconds...

Thanks for your fast reply! Yes indeed I can see the issue in our lab as well. But it happens only very sporadically. Using a new distribution release is not possible, since the code is frozen regarding the OS but of course I could ask Monta Vista whether there have patches for the TCP stack on top of our version. But first of course, I need to be sure that it is really a TCP issue and I didn't just missunderstand the behaviour of TCP. But right now I don't have an explanation for what I see in Wireshark.