On Sat, Sep 13, 2003 at 03:35:30PM +0200, Torsten wrote:
(lan_A)-----( if_A: noIP )-|bridge|-( if_B: ip_B )----(lan_B)
IP datagram from (lan_A) to ip_B First appearance of the ip datagram within pf is: IN if_B (!)
IP comes in a ethernet frame with dst mac for if_A and can only arrive on if_A due cabling.
Why would the destination MAC be for if_A? Normal ARP should respond with if_B's MAC over the bridge.
Sorry, i made a typo there. The dst MAC is the MAC of if_B
Why would a frame from lan_A (to anywhere) come in on if_B (and not, first, on if_A)? That makes no sense, indeed. Either you were not tcpdumping on if_A correctly, or you were seeing a reply in reverse direction. A packet from a host on lan_A to ip_B should be seen only incoming on if_A, then the stack on the bridge will notice that the destination is itself (if the destination MAC address is that of if_B), and consume it. There's no reason why it would pass if_B at > all.
tcpdump will only see it on if_A, because the driver will bpf_mtap() it there. L2 processing is where things get screwy. If only the stack were really on the bridge...
Why is there no way for gettin the physical interface the packet comes in? this is the *only* thing that ain't spoofable.. i would love to filter that in the pf :)
If you update to -current, you can use tags for that. Either bridge or pf can add a tag ('packet came in on interface fxp0'), and you can filter based on that tag.
Bridge tagging won't work either; the bridge interface technically never sees this packet.
The frame hits ether_input(), which notices the interface is a bridge member, and kicks it to bridge_input(). bridge_input() realizes the destination MAC is one of ours, so it resets m_pkthdr.rcvif to the matching interface, and drops the packet back to ether_input(). Normal processing from there.
The bridge filters never get hit until it's queued on a softnet for the bridge interface itself, which will only happen for packets not to us.
Personally, I think the entire implementation of bridging in the BSDs and Linux is an ugly hack. Microsoft's method makes a lot more sense: the bridge interface supersedes L3 on the member interfaces, and gets an address of its own. It's easier to follow logically.
Anyway, back to OpenBSD, this internal transit to the matching interface makes sense from an L3 perspective (which is probably why it's done, to keep the upper layers happy). Bypassing bridge ether filtering on the real receive interface is a problem though.
