On Thu, 20 Jan 2011 23:14:10 +1100
Joel Sing <j...@sing.id.au> wrote:
> On Thursday 20 January 2011, Gregory Edigarov wrote:
> > On Wed, 19 Jan 2011 20:14:01 +1100
> >
> > Joel Sing <j...@sing.id.au> 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.
then the question is: why is it dropping out?
pppoe(8) and ppp(8) are working quite happy on the wire. but pppoe(4) -
doesn't.
--
With best regards,
Gregory Edigarov
