lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Router issues with lwip


From: Martin Glunz
Subject: Re: [lwip-users] Router issues with lwip
Date: Wed, 23 Jun 2004 11:41:31 +0200

"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:

> 
> Perhaps the easiest thing to do here would be less picky about the
> sequence numbers of RST packets that we except?
Maybe, this was my solution to get around the problem. But further
investigation showed that this seems to apply only to the mentioned
Netgear router, I do not have this problem with other routers
(tested Linux and a D-Link box so far). With these other routers,
lwip accepts the first RST packet, but in the tcpdump traces
I can't spot a significant difference in the sequence numbers.

<wild guessing follows> 
Perhaps the Netgear corrupts the packets
in some way I can't see with tcpdump ... 
Somehow Netgear seems not to like Linux (or vice versa):
If I'm trying to connect the device by netcat via
Netgear/Internet/Linux,
to connection fails. Using telnet works ...
Then I've tried netcat to lwip via Netgear/Internet/D-Link -> works.
Netcat to lwip via Linux/Internet/Netgear leads to the above problem.
</>


> 
> As far as the missed FIN goes, that is indeed odd, and difficult for me
> to debug.  It does get acknowledged, after a short delay and a couple of
> other packets being sent out (as you might expect), but nothing seems to
> be acting on that.  Is it possible that whatever application you have
> using the lwIP stack is not responding to the EOF, or whatever? 
Yes indeed, I'm using the sockets api to send the data and there seems
no way the get the EOF via the send() call. The application never calls
recv() as no data shall be received. Getting the EOF should be easier
using the event based api, but I absolutely do not want to restructure
the application.

> If
> everything is OK there, any chance you could turn some of the debug
> flags on to see if anything interesting is output there?
I've done some debugging to get to my hack, but I used some printf
statements of my own, not the debug flags. I've tried to turn on the
debug
flags, this seems to produce lots of messages (I'm not sure how
to turn on special debug flags only). I've uploaded the logs
to http://wunderkis.de/lwip/netgear.log and
http://wunderkis.de/lwip/dlink.log
if you like to look at them. 

-- 
MfG
Martin Glunz

fortune says today:
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
                -- Winston Churchill

WANTED: Schrödinger's Cat. Dead or Alive.

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




reply via email to

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