lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] LWIP 1.2 issue.


From: Robert Morse
Subject: Re: [lwip-users] LWIP 1.2 issue.
Date: Tue, 17 Apr 2007 08:43:32 -0400


On Apr 17, 2007, at 8:28 AM, Kieran Mansley wrote:

On Tue, 2007-04-17 at 13:25 +0200, Goldschmidt Simon wrote:
Also I am getting the following Messages: (I have some debugging
turned on).

tpc_listen_input: ACK in LISTEN, sending reset.
tcp_rst: seqno 5984823 ackno 3514939349.

This suggests that packets are being sent or delivered to the
listening socket when there should obviously be none other
than SYNs going there.
If you can get a packet capture of one of these that might
through some light on it.

Could it be that the same pcb was set to listening state through
tcp_listen() and at
the same time (the same pcb) was used to connect somewhere (using
tcp_connect())?

I think it more likely that it is two separate PCBs, but they both have
the same local port.  This is quite common: when doing a passive open
(i.e. at the listening end of a TCP connection), the listening PCB
spawns a new "data transfer" PCB that has the same local address and
port.  This is OK because they will all have different remote
addresses/ports and so can be told apart. When the data transfer PCB is finished and closed however, only the listening PCB will be left on that
local port, and so it will receive any packets that were in fact
destined for the data PCB. Things like the TIME_WAIT state are designed
to protect against this causing too many problems, but there can still
be occasions where a packet ends up getting through.  This is why the
listening PCB sends a RST to the other end when it receives the packet -
it knows that the connection it was for is long gone, and so a RST
should get the other end to notice.

Kieran

The problem is that the lwip stack did not send out an [ACK] to the clients [FIN ACK], but lwip thinks it did, LWIP did send out its [FIN ACK] and received the [ACK] from the client, so the socket is closed. So the client keeps sending a [FIN ACK] (For about 3 tries), which the LWIP stack has the socket already closed. So the stack is right about what it saying, that the client is trying to send data, be it a [FIN ACK] to a socket that is closed.

I am trying to tack down how to catch the problem, and figure out who is dropping the packet. As I cannot see any other packets being dropped, and the dropping of the [ACK] is
rare.

Robert





reply via email to

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