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