Date: Sun, 4 Feb 2001 11:47:21 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Rich Wales <richw@webcom.com> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? Message-ID: <Pine.NEB.3.96L.1010204114004.65610J-100000@fledge.watson.org> In-Reply-To: <20010203220223.86591.richw@wyattearp.stanford.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Feb 2001, Rich Wales wrote: > I'm running -STABLE (cvsup'ed on 26jan2001) on a machine with the BRIDGE > option, bridging between two PCI NICs (rl0 and xl0). > > I'm having ARP problems. Machines on the "rl0" card are unable to get a > hardware address for the bridge. (For whatever reason, I have no > problems talking via the "xl0" interface.) > > I've done "tcpdump" on the bridge, and it's receiving ARP queries on the > "rl0" interface, but it doesn't appear to be sending replies. I did a > "tcpdump" on the "xl0" interface too, just in case ARP replies were > going out over the wrong interface, but no such luck. > > If I turn off bridging (sysctl -w net.link.ether.bridge=0), the ARP > problem quickly resolves itself. So the problem would seem to be > related somehow to the bridge code. > > I can sidestep the problem by using "arp -s" commands on the other > machines to tell them the bridge's hardware address -- but I really > shouldn't have to do this. So at one point I was experimenting with userland bridging software based on BPF, and supported that through an additional option I added to BPF, BIOCSSEESENT. Normally, BPF will provide access to both ethernet packets that come off the wire, and those that are locally sourced. Toggling off BIOCSSEESENT causes BPF to not push looped back ethernet packets into the BPF device -- this is determined by looking at the ifnet (interface) pointer in the mbuf for the packet. This allowed the userland software to simply open a BPF device for each interface desired, and then to propagate any packets received on any BPF device to all other bridged BPF devices, optionally with filtering (which was the real goal of the exercise, I wanted to work with bridged filtering without hacking up the kernel). An interesting side effect of this was that locally sourced packets that came out of the IP stack would not be bridged, as they would have a NULL source interface (this is because most ethernet cards do not deliver locally sourced packets back in the interface, so we rely on a software loopback to provide this service, which in turn doesn't set the interface pointer, I believe -- both convenient and inconvenient). So when the bridge was in operation, nodes on either side of the bridge could talk to each other just fine, but not to the bridge *unless* they were talking to the bridge on an IP address configured on the interface on their side of the bridge. Due to limitations in our IP stack and routing code, it's not possible to bind two identical subnet address/masks to two different interfaces, meaning that in effect, unless I used different subnets for both interfaces in the bridge, only one set of hosts could communicate with the bridge. So my question for you is, does this behavior sound like something you're experiencing: if you have the bridge ping the broadcast address on the side of the bridge where the IP address is configured on the interface, does packet sniffing on the other side see the bridged packets? If you configure the IP address on the other interface, does ARPing the bridge host from that side work? I.e., do you see behavior where the bridge is only IP-reachable from one side of the bridge, and not the other? This might suggest a problem with bridging of software-looped back packets, possibly specific to the interfaces you're using. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010204114004.65610J-100000>