Thanks Jonathan, this fixes my issue. Michel
> On May 12, 2016, at 3:10 AM, Jonathan Gray <[email protected]> wrote: > > On Wed, May 11, 2016 at 10:20:29PM -0400, [email protected] wrote: >>> Synopsis: attempt to execute 0x0, arping to bridge >>> Category: system >>> Environment: >> System : OpenBSD 5.9 >> Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST >> 2016 >> >> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> Architecture: OpenBSD.amd64 >> Machine : amd64 >>> Description: >> panic: attempt to execute user address 0x0 in supervisor mode >> Stopped at Debugger+0x9: leave >> TID PID UID PRFLAGS PFLAGS CPU COMMAND >> *20236 20236 32767 0x13 0 0 arping >> Debugger() at Debugger+0x9 >> panic() at panic+0xfe >> trap() at trap+0x7dd >> --- trap (number 6) --- >> (null)() at 0 >> spec_write() at spec_write+0xbe >> VOP_WRITE() at VOP_WRITE+0x3f >> vn_write() at vn_write+0x98 >> dofilewritev() at dofilewritev+0x205 >> >> Not sure if relevant in this bug report, but my Ferrari is a PC Engines APU2. >> >>> How-To-Repeat: >> # create a bridge interface >> bridge28: flags=41<UP,RUNNING> >> groups: bridge >> priority 57344 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp >> designated: id 00:00:00:00:00:00 priority 0 >> vlan28 flags=7<LEARNING,DISCOVER,BLOCKNONIP> >> port 8 ifpriority 0 ifcost 0 >> vlan128 flags=7<LEARNING,DISCOVER,BLOCKNONIP> >> port 7 ifpriority 0 ifcost 0 >> Addresses (max cache: 100, timeout: 240): >> ac:f1:df:65:11:15 vlan28 0 flags=1<STATIC> >> # note my two underlying interfaces are down >> vlan28: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 >> lladdr 00:0d:b9:41:5d:2d >> priority: 0 >> vlan: 28 parent interface: trunk0 >> groups: vlan >> status: active >> vlan128: flags=8942<BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 >> lladdr 00:0d:b9:41:5d:2d >> priority: 0 >> vlan: 128 parent interface: trunk0 >> groups: vlan >> status: active >> # arping -0 -B -i bridge28 -c 2 -P -s "00:11:22:33:44:55" -q >> ## also had the same results trying it with dnet arp op rep sha >> "00:11:22:33:44:55" | dnet eth type arp dst ff:ff:ff:ff:ff:ff | dnet send >> bridge28 >> # boum. >>> Fix: >> Fix is unknown > > This sounds like the problem that was fixed in if_bridge.c 1.278 > > revision 1.278 > date: 2016/04/12 06:20:30; author: mpi; state: Exp; lines: +12 -2; > commitid: Itzt9gWTLLzkrbM4; > Set bridge(4)'s if_output to a dummy function returning EAFNOSUPPORT as > it should not be used to output packets but we have to respect the ifp > driver API to some extend. > > Prevent a panic found the hardway by espie@. > > ok claudio@, mikeb@, jsg@, krw@ > > Index: if_bridge.c > =================================================================== > RCS file: /cvs/src/sys/net/if_bridge.c,v > retrieving revision 1.275 > diff -u -p -r1.275 if_bridge.c > --- if_bridge.c 5 Dec 2015 10:07:55 -0000 1.275 > +++ if_bridge.c 12 May 2016 07:06:20 -0000 > @@ -127,6 +127,8 @@ struct mbuf *bridge_ip(struct bridge_sof > struct ether_header *, struct mbuf *m); > int bridge_ifenqueue(struct bridge_softc *, struct ifnet *, struct mbuf *); > void bridge_ifinput(struct ifnet *, struct mbuf *); > +int bridge_dummy_output(struct ifnet *, struct mbuf *, struct sockaddr *, > + struct rtentry *); > void bridge_fragment(struct bridge_softc *, struct ifnet *, > struct ether_header *, struct mbuf *); > #ifdef IPSEC > @@ -187,7 +189,7 @@ bridge_clone_create(struct if_clone *ifc > ifp->if_softc = sc; > ifp->if_mtu = ETHERMTU; > ifp->if_ioctl = bridge_ioctl; > - ifp->if_output = NULL; > + ifp->if_output = bridge_dummy_output; > ifp->if_start = NULL; > ifp->if_type = IFT_BRIDGE; > ifp->if_hdrlen = ETHER_HDR_LEN; > @@ -203,6 +205,14 @@ bridge_clone_create(struct if_clone *ifc > if_ih_insert(ifp, ether_input, NULL); > > return (0); > +} > + > +int > +bridge_dummy_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, > + struct rtentry *rt) > +{ > + m_freem(m); > + return (EAFNOSUPPORT); > } > > int
