Hello We've noticed an issue with RST ACK sequence number. It is +1 compared to ACK received. This causes long delays in reopening new connection.
This is the test setup: 1. PC 2. Switch 3. Device with LwIP PC opens a TCP connection to device and they start to exchange data. Then I'll unplug the device's Ethernet cable from the switch for a few seconds. PC starts to send retransmissions, then I restore the cable. Wireshark is taking log in the PC and I can see the retransmissions and then RST ACK from the device where seq number is +1 to what is expected. While tracing Lwip I found out that when cable is unplugged, it tries to send FIN ACK, but because there is no physical connection, the packet does not leave the device. When FIN ACK packet is created, it will add +1 to 'snd_nxt'-variable. This variable is then used when sending the RST ACK packet, but because FIN ACK did not leave the device, it's seq number is wrong. Sometimes when the cable is plugged in, it will send the FIN ACK and then RST ACK will have proper sequence number. I "fixed" this issue by changing tcp_abandon-method: seqno = pcb->snd_nxt; => seqno = pcb->lastack; Now, at least in these few tests I've run, it seems to work (PC accepts RST ACK and immediately opens new connection), but I have no idea what problems this change could cause. While writing this I started to wonder, that do we have a bug: something causes FIN ACK send even though cable is unplugged or is this an issue with LwIP's sequence numbers? Esa
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
