if_bridge: Give bpf a shot at packets passed over the bridge

[kevans]

Summary

As described in the comment: packets passed to another interface on the bridge via bridge_input will not be exposed to bpf for that interface in any way. They will be passed promptly back up the stack and dispatched almost directly into the next layer up or discarded.

This corrects the accounting for packets flowing in on an interface (either physically or through a bridge) and allows, for instance, an interface directly attached to the bridge pull a DHCP address if it so desires.

It's not clear to me if anything 'out there' relies on bpf to only reflect traffic physically flowing in on an interface and specifically *not* traffic flowing in from the bridge. This doesn't seem likely to me, though.

[kevans]

Correct slight oversight: don't double-tap packets that are being received by the same interface that they came in on. Those take the same path.

[kp]

I don't see any obvious problems, but I don't think I know this part of the code well enough to say for sure.

[kevans]

Abandoning for this now; further contemplation leads me to think my local hack should stay local on this one. I do think there's a tangentially related problem here, though, that I'll likely address in a different review: consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 that gets forwarded *through* em1 will increment bridge0 IPACKETS/IBYTES and get passed through bridge0 bpf. Unicast traffic specifically for em1, though, will *not* have any of this accounting done and not get passed to bridge0 bpf, just em0 bpf, despite still having passed over the bridge in the same fashion. It strikes me as incorrect to treat this traffic any differently than in the bridge_forward case.