Bug #110

bug in route tables handling triggered by ppp

Added by fgudin about 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Hello,

i posted this as a blog entry on GoBSD.com because of the lack of useful
details to build a bug-report. I still think this is a bug (a badly
configured userland program leads to a kernel panic):
http://gobsd.com/node/225

Have a nice day,
Francis.
--
Creators Admit Unix, C Hoax
http://www.elsop.com/wrc/humor/unixhoax.htm

History

#1 Updated by corecode about 8 years ago

On 13.03.2006, at 10:43, Francis Gudin wrote:
> i posted this as a blog entry on GoBSD.com because of the lack of
> useful
> details to build a bug-report. I still think this is a bug (a badly
> configured userland program leads to a kernel panic):
> http://gobsd.com/node/225

could you please post such things nevertheless on the mailing lists,
even if just for archiving purposes.

thanks
simon

#2 Updated by fgudin about 8 years ago

On 13-03-2006, Simon 'corecode' Schubert <> wrote:
>
> could you please post such things nevertheless on the mailing lists,=20
> even if just for archiving purposes.
>
> thanks
> simon

Yep, here's a wild snarf/paste from gobsd:

I worked around an annoying bug this morning by cleaning up my ppp.conf.
As my only storage is ips, i can't provide any dump; hence, i decided to
post this here instead of bothering the developpers with an almost
useless bug-report. It's a bit of a reminder, and i also wish it could
avoid a nervous breakdown to anyone facing the same problem, maybe. Now
the story:

My system is a dual-cpu, DragonFly 1.5.1 and i use userland ppp in PPPoE
mode. When booting from my -DEVELOPMENT slice, i regularly experimented
panics (something like 1 out of 20 boots) and inconsistencies with the
route tables (default route entries missing because ppp couldn't "add
default HISADDR"). Until now, i just did this on startup:route delete
default && route add default -interface tun0
This morning, i decided to have a look closer at this issue. The problem
was that in single-user mode, panic'ing was 1/1 ! If this may help,
here's a transcript:
#/etc/rc.d/ppp-user start
Starting ppp as "root"
Warning: Add! route failed: ff02:: errno: Operation not supported
Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
Note: panic took place two seconds after the shell prompted again.
db> trace
Debugger(c02cc075) at Debugger+0x3d
panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
lwkt_exit() at lkwt_exit

At complete random, i had a look at ppp(8) and found my set ifaddr line
quite wrong:
set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
After fixing that to:
set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
i no longer see panics, even in the 100% reproductible case (single-user
mode), and my route tables are ok. ppp properly adds default routes (i
have a native ipv6 link, thanks Nerim!), though it still warns about the
"ff02::" route entry, which i'll investigate later on.

If anyone really want it thoroughly debugged, i can provide informations
with kgdb instead of a dump, just let me know.

Francis.

#3 Updated by dillon about 8 years ago

:...
:#/etc/rc.d/ppp-user start
:Starting ppp as "root"
:Warning: Add! route failed: ff02:: errno: Operation not supported
:Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
:#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
:Note: panic took place two seconds after the shell prompted again.
:db> trace
:Debugger(c02cc075) at Debugger+0x3d
:panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
:rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
:rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
:lwkt_exit() at lkwt_exit
:
:At complete random, i had a look at ppp(8) and found my set ifaddr line
:quite wrong:
:set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
:After fixing that to:
:set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
:i no longer see panics, even in the 100% reproductible case (single-user
:mode), and my route tables are ok. ppp properly adds default routes (i
:have a native ipv6 link, thanks Nerim!), though it still warns about the
:"ff02::" route entry, which i'll investigate later on.
:
:If anyone really want it thoroughly debugged, i can provide informations
:with kgdb instead of a dump, just let me know.
:
:Francis.

This is going to be hard to find without a dump. I know there are
definitely issues related to the default route and also issues with IPV6.

That particular panic occurs if a route table request succeeds on cpu #0
but then fails on cpu #1's route table, indicating a synchronization
issue between the replicated route tables.

-Matt
Matthew Dillon
<>

#4 Updated by drhodus about 8 years ago

On 3/13/06, Matthew Dillon <> wrote:
>
> :...
> :#/etc/rc.d/ppp-user start
> :Starting ppp as "root"
> :Warning: Add! route failed: ff02:: errno: Operation not supported
> :Warning: tun0: AIFADDR 213.41.166.51 -> 10.0.0.2 returns 0
> :#panic: rtrequest1_msghandler: rtrequest table error was not on CPU #0:
> :Note: panic took place two seconds after the shell prompted again.
> :db> trace
> :Debugger(c02cc075) at Debugger+0x3d
> :panic(c02d2b07,c9390c5c,0,c5c9fa00,ff808000) at panic+0x162
> :rtrequest1_msghandler(c9390c5c) at rtrequest1_msghandler+0x83
> :rtable_service_loop(0,0,0,0,0) at rtable_service_loop+0x13
> :lwkt_exit() at lkwt_exit
> :
> :At complete random, i had a look at ppp(8) and found my set ifaddr line
> :quite wrong:
> :set ifaddr 213.41.166.51 10.0.0.2 255.255.255.0 0.0.0.0
> :After fixing that to:
> :set ifaddr 213.41.166.51 62.4.16.246 255.255.255.255 213.41.166.51
> :i no longer see panics, even in the 100% reproductible case (single-user
> :mode), and my route tables are ok. ppp properly adds default routes (i
> :have a native ipv6 link, thanks Nerim!), though it still warns about the
> :"ff02::" route entry, which i'll investigate later on.
> :
> :If anyone really want it thoroughly debugged, i can provide informations
> :with kgdb instead of a dump, just let me know.
> :
> :Francis.
>
> This is going to be hard to find without a dump. I know there are
> definitely issues related to the default route and also issues with IPV6.
>
> That particular panic occurs if a route table request succeeds on cpu #0
> but then fails on cpu #1's route table, indicating a synchronization
> issue between the replicated route tables.
>
> -Matt

On my machine I can trigger a panic just like this by doing `sh
/etc/rc` on a machine that is already booted and has ifconfig
information in /etc/rc.conf.

-DR

Also available in: Atom PDF