On Wed, May 11, 2016 at 10:20:29PM -0400, michel.bell...@malaiwah.com 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
>
> dera...@amd64.openbsd.org:/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
