On Sat, Jan 30, 2016 at 11:03:06AM +0000, Stuart Henderson wrote:
| Replying to Paul's post and adding CCs, but Lars' post is also related
| http://marc.info/?l=openbsd-bugs&m=145409292029625&w=2
|
| Lars, and anyone else seeing this, what interface types do you have?
| Any tunnels (gif gre tun vxlan, etc.) or anything else out of the ordinary
| (bridges? don't know what else..)?
I've got a bit more than the "just regular" home gateway setup:
em0, em1, em3: my home network
em2: upstream
bridge0: bridge for home network with em0, em1 and em3
bridge1: bridge for MAC address changing on vlan4 (only em2)
gif0: SixXS IPv6 tunnel
tun0: OpenVPN tunnel (remote end comes and goes)
vlan4: (parent em2) TV network from upstream (changed lladdr), DHCP
vlan34: (parent em2) internet access from upstream, DHCP
I NAT the home network out over vlan34. The TV network needs the
igmpproxy to run, and indeed I have:
pass on vlan4 proto igmp allow-opts
In my pf ruleset. Of course, I also have multicast=YES in
/etc/rc.conf.local
| On 2016/01/30 01:09, Paul de Weerd wrote:
| > I've just confirmed this still happens with the latest snap (OpenBSD
| > 5.9-beta (GENERIC.MP) #1865: Thu Jan 28 20:18:15 MST 2016) and with a
| > kernel built from the latest sources (checkout from less than an hour
| > ago).
| >
| >
| > panic: kernel diagnostic assertion "pd.m->m_pkthdr.pf.statekey == NULL"
failed: file "../../../../net/pf.c", line 6569
| > Stopped at Debugger+0x9: leave
| > TID PID UID PRFLAGS PFLAGS CPU COMMAND
| > * 4209 4209 0 0x14000 0x210 2 softnet
| > Debugger() at Debugger+0x9
| > panic() at panic+0xfe
| > __assert() at __assert+0x25
| > pf_test() at pf_test+0xe26
| > ipv4_input() at ipv4_input+0x240
|
| So this is the code by the assert
|
| 6563 if (pd.dir == PF_IN && s && s->key[PF_SK_STACK]) {
| 6564 /*
| 6565 * ASSERT() below fires whenever caller forgets to call
| 6566 * pf_pkt_addr_changed(). This might happen when we deal
with
| 6567 * IP tunnels.
| 6568 */
| 6569 KASSERT(pd.m->m_pkthdr.pf.statekey == NULL);
| 6570 pd.m->m_pkthdr.pf.statekey =
| 6571 pf_state_key_ref(s->key[PF_SK_STACK]);
| 6572 }
|
| and pf_pkt_addr says
|
| /*
| * must be called whenever any addressing information such as
| * address, port, protocol has changed
| */
|
| ipv4_input isn't changing the packet address but maybe the 'IP tunnels'
| comment is relevant, since I see openvpn is running on Paul's machine
| which is going to either use tun(4) or tap(4).
|
| However it is not running on Lars' machine.
|
| igmpproxy is also running on Paul's so I am assuming there are likely to
| be multicast packets floating around, probably with ip options. Don't
| know if that is relevant.
|
| We could do with figuring out what packets are triggering this.
| Something like this before the KASSERT maybe,
|
| if (pd.m->m_pkthdr.pf.statekey != NULL)
| printf("mbuf 0x%p\n", pd.m);
|
| then "show mbuf 0x(addr)" in ddb...?
|
| I have not yet run into this assert myself - I am running the 28 Jan
| snapshot with vlan carp pppoe ipsec trunk..
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
