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.