Marco Jakobs wrote:
Wireshark gives this output:
Has anyone on this list ever heard that we favour pcap files over short
text cutouts? ;-)
55 13:40:56.348413 192.168.4.11 192.168.0.221 TCP 60
49153 > 14713 [SYN] Seq=6509 Win=2048 Len=0 MSS=1024
56 13:40:56.348517 192.168.0.221 192.168.4.11 TCP 60
14713 > 49153 [ACK] Seq=1144619934 Ack=6510 Win=65535 Len=0
57 13:40:56.348986 192.168.4.11 192.168.0.221 TCP 60
49153 > 14713 [RST, ACK] Seq=6510 Ack=1144619934 Win=2048 Len=0
So right after the acknowledgement from the server, LwIP now sends a
RST,ACK instead a single ACK (what it did in 1.4.0 and what I'd expect).
I cannot be sure because I don't have the pcap (which contains much more
info on the packets above), but I guess your TCP client just booted up
and reuses the same port as before (which the server already knows), but
the SYN has a Seqno that is not valid for the server, so it sends an ACK
with the Seqno it expects (note the server sends an ACK, not a SYN/ACK).
This leads to the device sending a RST. Perfectly valid so far.
Any idea how to fix this?
Yes.
a) Make the device use a different initial Seqno on every boot (i.e.
random number). You can do that in lwIP by defining
TCP_LOCAL_PORT_RANGE_START and TCP_LOCAL_PORT_RANGE_END yourself (see
tcp.c).
b) Just live with the RST once (now you know where it comes from) and
open the connection a second time. The RST from packet 57 should ensure
that the first connection is closed on the server as well.
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
