/bsd: splassert: assertwaitok: want -1 have 1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

/bsd: splassert: assertwaitok: want -1 have 1

Gregory Edigarov-2
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

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.



--
With best regards,
        Gregory Edigarov

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Bret S. Lambert-2
Set kern.splasssert=2 and report the debugging info that ddb gives.

On Wed, Jan 19, 2011 at 9:49 AM, Gregory Edigarov
<[hidden email]> 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
>
> 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.
>
>
>
> --
> With best regards,
>        Gregory Edigarov

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Joel Sing-3
In reply to this post by Gregory Edigarov-2
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.

--

   "Stop assuming that systems are secure unless demonstrated insecure;
    start assuming that systems are insecure unless designed securely."
          - Bruce Schneier

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Gregory Edigarov-2
On Wed, 19 Jan 2011 20:14:01 +1100
Joel Sing <[hidden email]> 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
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
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.


--
With best regards,
        Gregory Edigarov

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Mike Belopuhov
On Thu, Jan 20, 2011 at 10:31 +0200, Gregory Edigarov wrote:

> --- 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
> 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
> 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.
>

seems like this is the only plausible way to fix it:

Index: net/if.c
===================================================================
RCS file: /home/cvs/src/sys/net/if.c,v
retrieving revision 1.231
diff -u -p -r1.231 if.c
--- net/if.c 29 Nov 2010 19:38:59 -0000 1.231
+++ net/if.c 20 Jan 2011 11:11:53 -0000
@@ -2213,7 +2213,7 @@ ifa_item_insert(struct sockaddr *sa, str
 {
  struct ifaddr_item *ifai, *p;
 
- ifai = pool_get(&ifaddr_item_pl, PR_WAITOK);
+ ifai = pool_get(&ifaddr_item_pl, PR_NOWAIT);
  ifai->ifai_addr = sa;
  ifai->ifai_ifa = ifa;
  ifai->ifai_rdomain = ifp->if_rdomain;

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Joel Sing-3
In reply to this post by Gregory Edigarov-2
On Thursday 20 January 2011, Gregory Edigarov wrote:

> On Wed, 19 Jan 2011 20:14:01 +1100
>
> Joel Sing <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Henning Brauer-5
In reply to this post by Mike Belopuhov
* Mike Belopuhov <[hidden email]> [2011-01-20 13:31]:
> seems like this is the only plausible way to fix it:
>
> - ifai = pool_get(&ifaddr_item_pl, PR_WAITOK);
> + ifai = pool_get(&ifaddr_item_pl, PR_NOWAIT);

no way. this has consequences you don't even envision.

ifa_add in int context is verboten, period. use a workq or sth. rtsol
has been fixed that way, pppoe apparently still needs that fix.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Joel Sing-3
In reply to this post by Mike Belopuhov
On Thursday 20 January 2011, Mike Belopuhov wrote:

> On Thu, Jan 20, 2011 at 10:31 +0200, Gregory Edigarov wrote:
> > --- 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
> > 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
> > 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.
>
> seems like this is the only plausible way to fix it:
>
> Index: net/if.c
> ===================================================================
> RCS file: /home/cvs/src/sys/net/if.c,v
> retrieving revision 1.231
> diff -u -p -r1.231 if.c
> --- net/if.c 29 Nov 2010 19:38:59 -0000 1.231
> +++ net/if.c 20 Jan 2011 11:11:53 -0000
> @@ -2213,7 +2213,7 @@ ifa_item_insert(struct sockaddr *sa, str
>  {
>   struct ifaddr_item *ifai, *p;
>
> - ifai = pool_get(&ifaddr_item_pl, PR_WAITOK);
> + ifai = pool_get(&ifaddr_item_pl, PR_NOWAIT);
>   ifai->ifai_addr = sa;
>   ifai->ifai_ifa = ifa;
>   ifai->ifai_rdomain = ifp->if_rdomain;

pool_get() with PR_NOWAIT... and then not checking the return value? That's
got null pointer dereference written all over it... :)

However, the bigger problem is what can you then do if the pool_get() fails?
This then results in the interface address not being allocated and in most
cases there is no way to propagate/handle the error. The solution here is to
add the interface address from process context and not from interrupt
context.
--

   "Stop assuming that systems are secure unless demonstrated insecure;
    start assuming that systems are insecure unless designed securely."
          - Bruce Schneier

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Mike Belopuhov
On Thu, Jan 20, 2011 at 1:57 PM, Joel Sing <[hidden email]> wrote:
> pool_get() with PR_NOWAIT... and then not checking the return value? That's
> got null pointer dereference written all over it... :)
>
> However, the bigger problem is what can you then do if the pool_get() fails?
> This then results in the interface address not being allocated and in most
> cases there is no way to propagate/handle the error. The solution here is to
> add the interface address from process context and not from interrupt
> context.
> --

yes yes, i pushed reply button too soon this time (:

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Gregory Edigarov-2
In reply to this post by Joel Sing-3
On Thu, 20 Jan 2011 23:14:10 +1100
Joel Sing <[hidden email]> wrote:

> On Thursday 20 January 2011, Gregory Edigarov wrote:
> > On Wed, 19 Jan 2011 20:14:01 +1100
> >
> > Joel Sing <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Stuart Henderson
On 2011/02/02 09:35, Gregory Edigarov wrote:

> On Thu, 20 Jan 2011 23:14:10 +1100
> Joel Sing <[hidden email]> wrote:
>
> > On Thursday 20 January 2011, Gregory Edigarov wrote:
> > > On Wed, 19 Jan 2011 20:14:01 +1100
> > >
> > > Joel Sing <[hidden email]> 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.

Is it quietly dropping out + reconnecting with pppoe(8)? Or is it not
dropping out at all there?

Looking at packet traces from the pppoedev interface might give clues.

Reply | Threaded
Open this post in threaded view
|

Re: /bsd: splassert: assertwaitok: want -1 have 1

Gregory Edigarov-2
On Wed, 2 Feb 2011 09:48:44 +0000
Stuart Henderson <[hidden email]> wrote:

> On 2011/02/02 09:35, Gregory Edigarov wrote:
> > On Thu, 20 Jan 2011 23:14:10 +1100
> > Joel Sing <[hidden email]> wrote:
> >
> > > On Thursday 20 January 2011, Gregory Edigarov wrote:
> > > > On Wed, 19 Jan 2011 20:14:01 +1100
> > > >
> > > > Joel Sing <[hidden email]> 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.
>
> Is it quietly dropping out + reconnecting with pppoe(8)? Or is it not
> dropping out at all there?
There is NO dropouts with pppoe(8). No, completely.
 

 


--
With best regards,
        Gregory Edigarov