[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LwIP 1.4.1: Outgoing TCP connection does not work - LwI

From: address@hidden
Subject: Re: [lwip-users] LwIP 1.4.1: Outgoing TCP connection does not work - LwIP sends RST, ACK
Date: Thu, 20 Dec 2012 09:12:31 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

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 TCP      60        49153 > 14713 [SYN] Seq=6509 Win=2048 Len=0 MSS=1024

56        13:40:56.348517   TCP      60        14713 > 49153 [ACK] Seq=1144619934 Ack=6510 Win=65535 Len=0

57        13:40:56.348986 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?

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]