Re: [lwip-users] Handling sudden disappearance of network i/f

[Clive Wilson]

At 11:24 19/09/2006, you wrote:
> On Mon, 2006-09-18 at 13:00 +0100, address@hidden wrote:
> > Hello,
> >
> > I have a problem whereby if the low-level comms supporting a network
> > interface I'm using for LwIP suddenly (and unexpectedly) disappears,
> > the upper stack layers don't seem to be becoming aware of this. I'm
> > using the PPP network interface, but I don't think that should make
> > any difference to the question in principle.
> >
> > I am able to determine when the data channel goes down (via a
> > callback), so can anyone say if there is a variable or data member in
> > the upper layers that I should be modifiying on this event, to
> > indicate that there is no longer a means of tx'ing/rx'ing packets?
> > Perhaps the variable is actually in the network layer (PPP in this
> > instance)?
>
> Are you hoping to notify the application, or TCP/IP layers?  TCP/IP
> would do very little with this information as it tries to be resilient
> across temporary network outages.  E.g. if you unplug an ethernet cable,
> then plug it back in again after a few seconds, the TCP connections will
> all still be there.  There are timer mechanisms that try to notice if a
> link has gone away for longer than you're willing to wait (in order that
> the connection gets closed locally and so frees resources).
>
> If the physical layer has really gone away for good, I think the
> appropriate action would be to unconfigure the network interface, using
> netif_remove() (I think - haven't checked the source).

Kieran,

Yes, in the LwIP PPP layer I'm using ipcp_down(), which calls sifdown(), 
which in turn calls netif_remove().

Unfortunately, this doesn't have the desired result. If the serial link 
that LwIP's PPP layer depends upon suddenly disappears, then on this event 
I call pppSigHUP to inform PPP of the low-level link's absence. This in 
turn calls netif_remove as you mention. However, if a socket call such as 
read(), write() etc is made after the serial link dies, I don't see these 
calls returning with an error to indicate a timeout waiting for response. 
Is this how they should respond? I assume that there is some kind of 
retransmission limit for un-ACKed outgoing packets, after which the socket 
API calls return with a failure. What I am actually seeing is my app 
hanging forever for response to some data it thinks it has sent, when in 
fact the data went nowhere.

I would be very grateful if someone could advise whether I have the wrong 
end of the stick with this.

Many thanks in anticipation,

Clive Wilson