On 12/04/16(Tue) 12:34, Stefan Sperling wrote: > On Tue, Apr 12, 2016 at 08:34:08AM +0200, Martin Pieuchot wrote: > > As reported by jsg@ the wifi stack should use if_start() just like the > > rest of the kernel. One of the patterns can even be converted to > > if_enqueue(). > > Note that if_enqueue() checks for a bridge port and, if present, sends > frames to the bridge unless the M_PROTO1 flag is set on the mbuf. > This looks like a potential change in behaviour. > > In case the wifi interface is in a bridge, could we end up sending the > EAPOL key packet to members of that bridge? Would this be a problem?
What's the use case of bridging wireless interfaces. Does that work? > These are unicast frames. I'm not entirely sure what the bridge would > really do here. It seems unlikely that a situation where it hasn't already > learned the WPA peer's MAC is even possible, i.e. where it would broadcast > the frame to all members. But if this did happen, could it expose bugs where > (ethernet) drivers for other bridge members choke on IEEE 802.11 frames? Well bridge(4) is supposed to be used on IFT_ETHER devices because it deals with Ethernet framces. Since we do not set the IFT_IEEE80211 type in our wireless drivers, they can be part of the bridge(4), but does that make sense? Note that ieee80211_output() already calls if_enqueue() so if this is a problem we already have it. > It looks like we could set the M_PROTO1 flag to skip the bridge just > to be sure it won't interfere. > But I don't know what other side effects this may have. Please don't. No not set this flag outside of if_bridge.c
