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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
