[PATCH] info to atm layer about broken connection

Duncan Sands duncan.sands at math.u-psud.fr
Fri Nov 4 03:22:57 EST 2005


Hi Stanislaw,

> > I've committed the vcc_release_async stuff (check it out from
> > cvs.infradead.org).  My experiments so far show that it works
> > as expected, i.e. if you have an open socket then when the
> > device is disconnected, it is the same as the connection being
> > closed, eg: if you were reading from the socket, then the read
> > completes; any writes get EPIPE, etc.  So it should cause pppd
> > to shut down.  My ISP doesn't support pppoa or pppoe, so I can
> > only do artificial tests - I haven't done any yet, but I will.
> > Can you please try it out?
> As I wrote before vcc_release_async() don't work for ppp. 

well, my patch does a tiny bit more: it stops new connections being
opened once the device is disconnected.  I had the idea that maybe
pppd was seeing problems with its first socket, and was opening a
new one, and so on, keeping the device in use.  Well, this seems
very unlikely for many reasons, but maybe it is relevant.

> I tried to investigate how does ppp driver work (I don't finished yet, and
> i really don't know as much text below is true ).
> 
> Pppoatm plugin for pppd ceate pvc socket,
> and only configure it (by setsockopt, ioclt, connect). 
> It is not used for sending/receiving any data, 
> syscall on socket are preformed only for proper
> merge atm layer with ppp net driver. 
> Vcc_release_async() only stop working pvc socket, 
> but in ppp it's not used, so release_async() do nothing. 
> To disable ppp connection low level kernel driver
> need to call ppp_unregister_channel() as do push
> function in pppoatm.ko when it receive NULL skb.

I see, thanks for the explanation.

> I will try to track problem down, it's quite difficult
> cause it cross many kernel layers (net core, atm, ppp).

I will also try.

Thanks for looking into this.

Ciao,

Duncan.



More information about the Usbatm mailing list