On Thursday 20 January 2011, Gregory Edigarov wrote:
> On Wed, 19 Jan 2011 20:14:01 +1100
>
> Joel Sing <[email protected]> wrote:
> > On Wednesday 19 January 2011, Gregory Edigarov wrote:
> > > Hello,
> > >
> > > I have my home system connected via pppoe(4) to a provider and
> > > connection disapears very frequently some once an hour.
> > > Just before connection is gone I always see the following in my
> > > logs:
> > >
> > > /bsd: splassert: assertwaitok: want -1 have 1
> >
> > Please set kern.splassert = 2 and provide a stack trace.
> >
> > > My first thought was that something happens on provider's side but I
> > > eliminate this reason connecting one of my other boxes(with linux)
> > > directly to my provider. The linux box is working correctly.
> > > I've also tryed to change the nic. It was rl(4) now it is vr(4).
> > > Result is the same.
> > >
> > > System is:
> > > # uname -a
> > > OpenBSD edigarov.sa.net.ua 4.9 GENERIC#11 amd64
> > > rebuilt on Sun 16 Jan.
>
> --- interrupt ---
> end trace frame: 0x0, count: 245
> 0x8:
> End of stack trace.
> pppoe0: received unexpected PADO
> pppoe0: chap failure
> pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated
This message is not being generated by from pppoe(4), rather it is originating
from the remote end. Looks like the remote end is running Roaring Penguin
(RP) PPPoE and that for some reason the pppd process is terminating. The
preceeding unexpected PADO (PPPoE Active Discovery Offer) and chap failure
suggest that the other end is making an unsolicity offer that then fails
authentication and therefore results in session disconnection.
> pppoe0: received unexpected PADO
> pppoe0: chap failure
> pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated
> pppoe0: received unexpected PADO
> pppoe0: chap failure
> pppoe: GENERIC ERROR: RP-PPPoE: Child pppd process terminated
> pppoe0: received unexpected PADO
> splassert: assertwaitok: want -1 have 1
This part is a bug in OpenBSD - an IPCP message is trigging the addition of an
interface address from interrupt context, which is no longer permitted. The
dropout and reconnection is however triggering it.
> Starting stack trace...
> assertwaitok() at assertwaitok+0x1c
> pool_get() at pool_get+0x95
> ifa_item_insert() at ifa_item_insert+0x35
> ifa_add() at ifa_add+0x43
> in_ifinit() at in_ifinit+0x16f
> sppp_set_ip_addrs() at sppp_set_ip_addrs+0x107
> sppp_ipcp_tlu() at sppp_ipcp_tlu+0x4e
> sppp_input() at sppp_input+0x594
> pppoeintr() at pppoeintr+0x41d
> netintr() at netintr+0x97
> softintr_dispatch() at softintr_dispatch+0x5d
> Xsoftnet() at Xsoftnet+0x28
> --- interrupt ---
> end trace frame: 0x0, count: 245
> 0x8:
> End of stack trace.
--
"Stop assuming that systems are secure unless demonstrated insecure;
start assuming that systems are insecure unless designed securely."
- Bruce Schneier
