LWIP 1.2 issue.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LWIP 1.2 issue.

Robert Morse
Hi,
        Maybe some one can point me at a place to look at for the following
issue I am seeing.

I have have ported LWIP to an Turbo186, I have the stack up and
running, but seeing some
strange problems.

Looking at wireshark/Ethereal  I see the following: (pcap file attached)

[Client] -- SYN
[LWIP]   -- SYN ACK
[Client] -- ACK
[Client] -- Sends Soap Message.
[LWIP] -- TCP Window Update to 2448
[LWIP] -- TCP Window Update to 3072
[LWIP] -- Responds with answer to Soap Message
[CLIENT] -- FIN, ACK
[LWIP] -- FIN, ACK
[CLIENT] -- ACK
[LWIP] -- ACK
[LWIP] -- DUP ACK (About 2 MS after ACK).

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 is repeated once in a while.

Any helps on where to look or any suggestions would be great.

Robert





_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users

dup.pcap (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LWIP 1.2 issue.

Kieran Mansley
On Mon, 2007-04-16 at 10:39 -0400, Robert Morse wrote:

> Hi,
> Maybe some one can point me at a place to look at for the following
> issue I am seeing.
>
> I have have ported LWIP to an Turbo186, I have the stack up and
> running, but seeing some
> strange problems.
>
> Looking at wireshark/Ethereal  I see the following: (pcap file attached)
>
> [Client] -- SYN
> [LWIP]   -- SYN ACK
> [Client] -- ACK
> [Client] -- Sends Soap Message.
> [LWIP] -- TCP Window Update to 2448
> [LWIP] -- TCP Window Update to 3072
> [LWIP] -- Responds with answer to Soap Message
> [CLIENT] -- FIN, ACK
> [LWIP] -- FIN, ACK
> [CLIENT] -- ACK
> [LWIP] -- ACK
> [LWIP] -- DUP ACK (About 2 MS after ACK).

That is a bit odd.  I can't see any reason for the duplicate ACK.  

> 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.  

Kieran  



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: LWIP 1.2 issue.

Robert Morse

>> 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.

Looking at a capture, I have found out what is happening, but not yet
as why.

It seems like LWIP is not sending a [ACK] to a [FIN ACK], but believes
that
it did.  Because the client did not see the [ACK] it keeps sending [FIN
ACK]
which lwip believes that it is in the listen state, thus giving the
error. I
am currently putting in error/status counters into the driver to see
why the
packet is not being sent.

On a side note: I am using a AM79C960 like ethernet chip, that uses DMA
buffers,
my question, on a transmitted packet, I do not know if it was
transmitted ok
until an interrupt is generated (both receive/transmit).  I can then
look at
some flags to see the state of the transmitted buffer. If I get an
error back
saying that the packet was not transmitted correctly, how should I pass
that
back up the stack so the packet can be retransmitted.  Now, I don't
think I want
to wait in the low_level_output() of the driver, until the packet has
been fully
transmitted, as that would eliminate any buffering that the ethernet
chip can
do.  I have the AM79C960 setup for 16 transmit buffers.  Just a quick
question.

Robert

>
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: LWIP 1.2 issue.

Jonathan Larmour
Robert Morse wrote:

> On a side note: I am using a AM79C960 like ethernet chip, that uses DMA
>  buffers, my question, on a transmitted packet, I do not know if it was
>  transmitted ok until an interrupt is generated (both
> receive/transmit).  I can then look at some flags to see the state of
> the transmitted buffer. If I get an error back saying that the packet
> was not transmitted correctly, how should I pass that back up the stack
> so the packet can be retransmitted.  Now, I don't think I want to wait
> in the low_level_output() of the driver, until the packet has been
> fully transmitted, as that would eliminate any buffering that the
> ethernet chip can do.  I have the AM79C960 setup for 16 transmit
> buffers.  Just a quick question.

Either you attempt to resend the failed packet inside the driver
immediately on an error indication[1], or you let higher layers retransmit
it in their own time. You don't pass anything up to the stack to get it to
retransmit.

Jifl
[1] Probably only a limited number of times though.
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
   **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> **
   **  April 3-5 2007, Booth 1922, San Jose McEnery Convention Center  **
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: LWIP 1.2 issue.

Goldschmidt Simon
In reply to this post by Kieran Mansley

> > 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())?
That way, it could be that the pcb is on both lists (tcp_active_pcbs &
tcp_listen_pcbs),
which could be the reason a LISTEN pcb gets data...?

If I'm right, this could be tested by inserting the following line into
tcp_listen():

  LWIP_ASSERT("connected pcb can't change to listen state!", (pcb->state
== LISTEN) || (pcb->state == CLOSED));

And the following line into tcp_connect():
  LWIP_ASSERT("connected pcb can't change from listen state to
connect!", (pcb->state != LISTEN));

Any comments from Kieran are welcome, as I can't tell if this is right
or not, just seems right to me ;-)


Simon


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: LWIP 1.2 issue.

Kieran Mansley
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



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: LWIP 1.2 issue.

Robert Morse

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