Re: npppd with two pppx interfaces causes kernel panic
On Thu, Mar 20, 2014 at 01:43:59PM +0900, YASUOKA Masahiko wrote: On Wed, 19 Mar 2014 21:05:35 -0700 Paul B. Henson hen...@acm.org wrote: On Thu, Mar 20, 2014 at 10:22:51AM +0900, YASUOKA Masahiko wrote: pppx will be fixed. Great :). This is a known bug then? It's new for me. I had not even try MAKEDEV pppx1 yet. The following diff prevents the panic here: Index: if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.26 diff -u -p -r1.26 if_pppx.c --- if_pppx.c 19 Oct 2013 14:46:30 - 1.26 +++ if_pppx.c 20 Mar 2014 10:21:04 - @@ -590,7 +590,8 @@ pppxclose(dev_t dev, int flags, int mode rw_enter_write(pppx_devs_lk); - pxd = pppx_dev_lookup(dev); + if ((pxd = pppx_dev_lookup(dev)) == NULL) + return (ENXIO); /* XXX */ while ((pxi = LIST_FIRST(pxd-pxd_pxis)))
Re: npppd with two pppx interfaces causes kernel panic
From: YASUOKA Masahiko Sent: Wednesday, March 19, 2014 9:44 PM Should I just keep an eye on the changelog for mention of pppx changes to tell when it's safe to try again? Sorry I cannot understand the point of this question. Sorry to be confusing; I switched to tun because of this bug, but I would prefer to use pppx once it has been fixed. The question was regarding how to know when the bug has been fixed. As I am unaware of any publicly accessible bug tracking system for openbsd, I was thinking of just watching the change log (http://www.openbsd.org/plus.html) for any mention of pppx. Thanks.
Re: npppd with two pppx interfaces causes kernel panic
From: Jonathan Gray Sent: Thursday, March 20, 2014 3:36 AM The following diff prevents the panic here: Interesting, given the XXX, it seems somebody was already a little suspicious of this section :). From a cursory glance, it seems pppx_dev_lookup is supposed to return data about a particular instance if it is in use, or NULL otherwise. So it seems for some reason pppxclose is being called for device that isn't open? While avoiding a panic is a plus :), it seems there is perhaps a logic error somewhere else resulting in an attempt to close a device that isn't open? Index: if_pppx.c == = RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.26 diff -u -p -r1.26 if_pppx.c --- if_pppx.c 19 Oct 2013 14:46:30 - 1.26 +++ if_pppx.c 20 Mar 2014 10:21:04 - @@ -590,7 +590,8 @@ pppxclose(dev_t dev, int flags, int mode rw_enter_write(pppx_devs_lk); - pxd = pppx_dev_lookup(dev); + if ((pxd = pppx_dev_lookup(dev)) == NULL) + return (ENXIO); /* XXX */ while ((pxi = LIST_FIRST(pxd-pxd_pxis)))
npppd with two pppx interfaces causes kernel panic
After successfully setting up an L2TP VPN with npppd and pppx, I tried
to add a second VPN subnet with a different authentication base. I was
working remotely, and after starting npppd in debug mode:
bash-4.2# npppd -d
2014-03-19 14:41:50:NOTICE: Starting npppd pid=32407 version=5.0.0
2014-03-19 14:41:50:WARNING: pptpd GRE protocol not allowed
2014-03-19 14:41:51:NOTICE: Load configuration
from='/etc/npppd/npppd.conf' successfully.
2014-03-19 14:41:51:INFO: pppx0 Started pppx
2014-03-19 14:41:51:INFO: pppx1 Started pppx
2014-03-19 14:41:51:INFO: Listening /var/run/npppd_ctl (npppd_ctl)
2014-03-19 14:41:51:INFO: ipcp=IPCP_admin pool
dyn_pool=[10.128.120.0/25] pool=[10.128.120.0/25]
2014-03-19 14:41:51:INFO: ipcp=IPCP pool dyn_pool=[10.128.120.128/25]
pool=[10.128.120.128/25]
2014-03-19 14:41:51:INFO: Loading pool config successfully.
the box stopped responding :(. When I got on site, it was frozen and
nonresponsive. I rebooted, and on the way back up it panic'd when
starting npppd:
starting early daemons: syslogd pflogd named ntpd isakmpd npppd.
uvm_fault(0xfe812f620e00, 0x30, 0, 1) - e
fatal page fault in supervisor mode
trap type 6 code 0 rip 81385b40 cs 8 rflags 10257 cr2 30 cpl 0
rsp 8000221fdd38
panic: trap type 6, code=0, pc=81385b40
Starting stack trace...
panic() at panic+0xf5
trap() at trap+0x7f1
--- trap (number 6) ---
mtx_enter() at mtx_enter
VOP_KQFILTER() at VOP_KQFILTER+0x2b
kqueue_register() at kqueue_register+0x332
sys_kevent() at sys_kevent+0x115
syscall() at syscall+0x249
--- syscall (number 270) ---
end of kernel
end trace frame: 0x11be0a5e, count: 250
0x11be006eca6a:
It then said Syncing disks and sat there for 30 minutes, at which
point I gave up, booted in single user, and disabled npppd.
Unfortunately I don't have a serial console logger at the moment, so
while I assume it did the same panic when I was working remotely I don't
have logs for it. This is a 5.4 box with a generic kernel, other than
using config -e to enable ipmi and change the irq for com2.
Any thoughts on this? Here is the npppd config that causes it to blow
up:
authentication LOCAL_admin type local {
users-file /etc/npppd/npppd-users
username-suffix @admin
}
authentication LOCAL type local {
users-file /etc/npppd/npppd-users
}
tunnel L2TP_ipv4 protocol l2tp {
listen on 96.251.22.154
# l2tp-require-ipsec yes # buggy, doesn't work currently
}
ipcp IPCP_admin {
pool-address 10.128.120.0/25
dns-servers 10.128.0.4
allow-user-selected-address no
}
ipcp IPCP {
pool-address 10.128.120.128/25
dns-servers 10.128.0.4
allow-user-selected-address no
}
interface pppx0 address 10.128.120.1 ipcp IPCP_admin
interface pppx1 address 10.128.120.129 ipcp IPCP
bind tunnel from L2TP_ipv4 authenticated by LOCAL_admin to pppx0
bind tunnel from L2TP_ipv4 authenticated by LOCAL to pppx1
Re: npppd with two pppx interfaces causes kernel panic
On Wed, 19 Mar 2014 16:45:46 -0700 Paul B. Henson hen...@acm.org wrote: After successfully setting up an L2TP VPN with npppd and pppx, I tried to add a second VPN subnet with a different authentication base. I was working remotely, and after starting npppd in debug mode: pppx will be fixed. You can use tun(4) instead if you want to use multiple interfaces for that purpose. --yasuoka
Re: npppd with two pppx interfaces causes kernel panic
On Thu, Mar 20, 2014 at 10:22:51AM +0900, YASUOKA Masahiko wrote: pppx will be fixed. Great :). This is a known bug then? Should I just keep an eye on the changelog for mention of pppx changes to tell when it's safe to try again? You can use tun(4) instead if you want to use multiple interfaces for that purpose. Yes, I switched to tun for now pending the ability to have multiple pppx interfaces defined. It was a rather big surprise for the box to disappear on me while I was working with it, I don't have any out of band access to it so it was offline until I got to it sigh. Thanks...
Re: npppd with two pppx interfaces causes kernel panic
On Wed, 19 Mar 2014 21:05:35 -0700 Paul B. Henson hen...@acm.org wrote: On Thu, Mar 20, 2014 at 10:22:51AM +0900, YASUOKA Masahiko wrote: pppx will be fixed. Great :). This is a known bug then? It's new for me. I had not even try MAKEDEV pppx1 yet. Should I just keep an eye on the changelog for mention of pppx changes to tell when it's safe to try again? Sorry I cannot understand the point of this question. You can use tun(4) instead if you want to use multiple interfaces for that purpose. Yes, I switched to tun for now pending the ability to have multiple pppx interfaces defined. It was a rather big surprise for the box to disappear on me while I was working with it, I don't have any out of band access to it so it was offline until I got to it sigh. Sorry too. I cannot see the problem you entered. --yasuoka
