Re: bridge changes traffic interface for pf, but not for tcpdump
I found this: http://openbsd.automagic.org/plus.html Apply bridge filter rules to frames destined for the local machine, so a single-interface bridge can do filtering and tagging. And then searched on that phrase, and found this: http://www.monkey.org/openbsd/archive/misc/0411/msg01144.html Which sounds similar to the problems I'm seeing, but not quite the same scenario. The follow-up: http://www.monkey.org/openbsd/archive/misc/0411/msg01560.html Maybe you should add the warning: if the vlan interfaces have IP addresses the bridge will misbave. They all have the same MAC as the parent, so the bridge's choice for the source interface rewrite will be arbitrary). Since I'm running an SS20, all of my _real_ interfaces have the same MAC address (for Sparc 32-bit, it's a property of the machine, not the NIC). So: (a) Does anyone know if the first bit, about applying bridge filter rules to frames destined for the local machine, has been implemented in -stable yet? I'd been working with 3.5, and recently updated to 3.6, and then to -current, but I hadn't re-tried the bridge filter tagging rules since. (b) If not, it's off to try this patch... JMF
Re: bridge changes traffic interface for pf, but not for tcpdump
On Feb 27, 2005, at 2:00 PM, Camiel Dobbelaar wrote: On Sun, 27 Feb 2005, Jim Fron wrote: Yes, I'm getting the feeling that what I'm seeing is not normal. As I've said, I have a suspicion that it's due to the le[dma] SBUS interfaces not having their own MAC address, and that somehow getting confused at the bridge level. I'm thinking about getting a QFE to test this out. To determine if traffic is destined for one of its member interfaces, the bridge walks the member list and compares the destination MAC with that of the interface. Because LIST_INSERT_HEAD() is used, the interface you added last to the bridge is checked first, etc. So, that explains why traffic always arrives destined for the OpenBSD box on le2. I presume a similar search happens for outbound, and that's why all traffic is said to originate on le0, even if it is physically sent out le2? You probably added le2 to the bridge last, so that one will always get the traffic destined for the le MAC. Yup! Maybe sea.c is worth a try to change the MAC of one of the interfaces... http://www.monkey.org/openbsd/archive/tech/9810/msg00022.html Worth a try, but it doesn't help. le0: flags=8b63UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULT ICAST mtu 1500 address: 08:00:20:77:a4:79 ... le2: flags=8b63UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULT ICAST mtu 1500 address: 08:00:20:77:a4:7b But a tcpdump from a machine connected to le2 says: 00 08:00:20:77:a4:79 ... Looks like the kernel thinks the address changed, but the le card overrides the hardware address supplied. Before you ask, yes, local-mac-address?=true Now ALL of the PF rules for traffic to and from the OpenBSD box from any machine, any interface, match le0 (rather than all in on le2, all out on le0). ;-) Thanks, though. Camiel, since you're the one who wrote the patch for vlan that I googled up, am I right in thinking that PF is confused about the interface because the bridge is changing the arriving interface, and that bridge rules for tagging aren't working properly, because of the same-MAC-address thing? Do you have any idea where I should start looking, in the source, for the place where bridge is confusing these interfaces? Basically, I would think that: frame arrives: if destined for some machine on the same interface, don't touch it (behave as it does now) if destined for some machine on the other side of the bridge (or unknown), behave as it does now. if destined for some machine on the NAT, behave as it does now. if destined for local machine, DON'T modify the interface it came in on by searching the list by MAC address, just pass it on to bridge rules and PF with the interface it was received on. I'm mucking about in src/sys/net/if_bridge.c, and I think I'm starting to follow it. Thanks, Jim
Re: bridge changes traffic interface for pf, but not for tcpdump
I've been informed, if I understand correctly, that bridge isn't intended to do
what I want to do with it.
FWIW, anyone who is interested, I'm hanging up the modification effort at half
complete, because it accomplishes everything I need. That is, I'm interested
in blocking traffic to the router differently depending on which leg of the
bridge it arrives on. I've solved that, and PF sees the correct inbound
interface. The only reason I can think of to care about blocking outbound
traffic originating from the router differently--that is, the only reason that
inbound rules alone would not be sufficient--would be in the event that the
OpenBSD router were compromised. If that were the case, PF rules wouldn't do a
bit of good anyway.
My thanks to everyone who has helped, especially Camiel Dobbelaar for the vlan
patch I found in the archives, which helped me significantly in making my own
patch (appended).
Jim
# Patch to allow machines with multiple interfaces with the same MAC
# address on a bridge to send inbound frames to PF with the correct
# interface. JMF 2005.02.28
#
--- if_bridge.c Wed Aug 18 08:07:47 2004
+++ if_bridge.c Mon Feb 28 11:30:00 2005
@@ -1289,6 +1289,7 @@
struct bridge_iflist *ifl, *srcifl;
struct arpcom *ac;
struct mbuf *mc;
+ int ifsrch = 1;
/*
* Make sure this interface is a bridge member.
@@ -1383,6 +1384,14 @@
* Unicast, make sure it's not for us.
*/
srcifl = ifl;
+
+ /* check to see if it arrived on the destination MAC address */
+ if (srcifl-ifp-if_type == IFT_ETHER) {
+ ac = (struct arpcom *)srcifl-ifp;
+ if (bcmp(ac-ac_enaddr, eh-ether_dhost, ETHER_ADDR_LEN) == 0)
+ ifsrch = 0;
+ }
+
LIST_FOREACH(ifl, sc-sc_iflist, next) {
if (ifl-ifp-if_type != IFT_ETHER)
continue;
@@ -1397,7 +1406,10 @@
m_freem(m);
return (NULL);
}
- m-m_pkthdr.rcvif = ifl-ifp;
+ /* don't rewrite the packet header interface if the
+ source interface header matched */
+ if (ifsrch)
+m-m_pkthdr.rcvif = ifl-ifp;
if (ifp-if_type == IFT_GIF) {
m-m_flags |= M_PROTO1;
ether_input(ifl-ifp, eh, m);
