Re: [lwip-users] Some insights on Router issues with lwip

[Martin Glunz]

Hi Leon, Hi Kieran

Today I've done some more tcpdumping and lwip-debugging:

In my opinion, the router problem is a bug of the netgear router.
As you can see from the debug traces and tcpdumps at
http://martins.wunderkis.de/lwip/netgear1.log and
http://martins.wunderkis.de/lwip/dlink1.log
the Netgear router stops forwarding packets after receiving the
first RST packet. The other one forwards all of the RST packets.
As the acknowledge from LWIP for the FIN packet gets delayed,
the PC sends the first packet before it has received the ack,
so the sequence number is one less than expected by LWIP.
LWIP discards this RST but won't receive the right one (when
using the Netgear). The Dlink Router forwards all RST packets,
an LWIP will receive the one with the expected sequence number.

As consequence of this, I won't recommend using Netgear routers
with my target, but for now, I'll keep the hack (for the case
someone ignores my recommendation).


"K.J. Mansley" wrote:
> 
> On Tue, 2004-06-22 at 06:20, Martin Glunz wrote:
> > "K.J. Mansley" wrote:
> > >
> > > > I've done a simple (and obvious) workaround:
> > > >
> > > >       if (TCP_SEQ_GEQ(seqno, pcb->rcv_nxt - pcb->rcv_wnd) &&   //
> > > > workaround for rp614v2
> > > >         TCP_SEQ_LEQ(seqno, pcb->rcv_nxt + pcb->rcv_wnd)) {
> > > >
> > > > Any comments?
> > >
> > > That's a rather hacky solution, and I'm not convinced that it is correct
> > > to send a RST with an out-of-window sequence number.  Can you provide a
> > > tcpdump or ethereal trace (from the PC node) showing the seq numbers,
> > > flags, and the times they are sent/received?
> > >
> > I totally agree that this a quick and dirty hack, but I needed to get
> > the device to work ...
> >
> > OK, here's the tcpdump:
> 
> As I understand there seems to be two problems here:
> 
> 1) The missed FIN
> 
> 2) The missed RST
> 
> With the latter, it seems odd to me that the sequence number of the RST
> is the same as that of the FIN.  As I understand TCP, SYN and FIN
> packets increment the sequence number, so you would expect the RST to
> have (in your trace) a sequence number of 3780613832 rather than
> 3780613831.  Does anyone else have any thoughts on this?
> 
> Perhaps the easiest thing to do here would be less picky about the
> sequence numbers of RST packets that we except?
> 

-- 
MfG
Martin Glunz

fortune says today:
The road to hell is paved with good intentions.  And littered with
sloppy analysis!

WANTED: Schroedinger's Cat. Dead or Alive.

Isn't vi that text editor with two modes... one that beeps and one that
corrupts your file?