[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