Page MenuHomeFreeBSD

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

Authored by kevans on Mar 14 2019, 6:23 PM.



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.

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped
Build Status
Buildable 23102

Event Timeline

kevans created this revision.Mar 14 2019, 6:23 PM
kevans updated this revision to Diff 55092.Mar 15 2019, 3:50 AM

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.

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 abandoned this revision.Mar 17 2019, 5:02 PM

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.