Re: [lwip-users] Router issues with lwip

[Martin . Glunz]

Zitiere "K.J. Mansley" <address@hidden>:

> 
> OK, I've had a look to see what the standard means of informing a
> process that is only using send()/write()/etc that a FIN/RST has been
> received is:
> 
...
> 
> So, there does appear to be some incorrect behaviour from the
> non-lwip-PC with a RST being sent when a process has closed a
> connection
> (rather than the process having terminated) - unless I've
> misunderstood
> the example anyway. 
In my examples the remote process was terminated, as this was
the easiest way to test. But the same behaviour appeared with
the real application (both sides hang, the RST is sent when
the PC application terminates). In any case, lwip didn't get
the RST packet as it believed the sequence number to be invalid.

My test setup is the following:
Lwip sends data, netcat receives and writes to /dev/null,
then i manually terminated netcat.
Works fine with a direct connection and with the Dlink-Router,
fails with the Netgear.

>  Regardless of that though the solution to
> preventing the lwip (sending) application from hanging is for us to
> send
> SIGPIPE and return EPIPE in this eventuality.  I'll file a bug report
> to
> this effect, and if there are any volunteers to do something about it,
> that would be great!

Sending SIGPIPE (or any kind of signal) in a simple cooperative 
multi-threading environment (which lwip is headed to in my opinion)
could be rather nasty to implement. And it's not really neccessary
because send() returns an error (in this particular case I do not
mind which error) when the RST packet is received.

Martin Glunz