Re: multicast packets from bpf

Andrew Thompson wrote:
> I had originally started to put it there but realised that I need a
> pointer to the ifnet to read if_broadcastaddr, I didnt think it was
> worth changing the function parameters when the check can also just go
> in bpfwrite. I dont mind moving it if its the more correct place to put
> it.
>   

It's already got a switch..case breakout for the DLTs and knows how to 
grok the 802.11 header format which can have up to 6 (yes, 6) 802.3 
style MAC addresses, all of which mean different things depending on 
whether you are STA, AP, Mesh Portal, Mesh AP... :-)

So it seems like the right place. bpf_movein() is static and referenced 
once within its translation unit, so it is a candidate for inlining; I 
would change ifp-»if_mtu to ifp in the call.

> Is the tapwrite patch still needed? The mbuf is passed to ether_input
> which should do the right thing.
>   

Good point. A casual reading suggests it *may* no longer be needed since 
my pass over ether_input(), but seeing as we're due to branch and all, 
I'll leave garbage collecting the 10 lines in tapwrite() to someone 
else. :-)

> I could go with this but it seems wrong to be passed a mbuf which has
> incorrect flags, there may be other places in the stack that look for
> M_*CAST that also have quirks.
>   

Yup. Someone could potentially drive a netgraph stake between the 
producer and the if_bridge consumer...

Thank you for looking at this btw.

regards,
BMS