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=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULT
ICAST> mtu 1500
address: 08:00:20:77:a4:79
...
le2:
flags=8b63<UP,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:
000000 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
