On Fri, 9 Jul 2004, Matchstick wrote:

> Basically, as the OPT1 interface was running in promiscuous mode (so it
> could form the bridge) it was responding to all ARP requests for the
> LAN interface hardware address, before the LAN interface itself
> managed to reply which meant that traffic for the LAN interface get
> redirected through the bridge.

I'd expect it to be the other way around if both responses were really
sent.  Since each ARP packet is supposed to update any cache entries
associated with the sender, the *last* answer usually wins.

This problem has nothing to do with promiscuous mode.  Promiscuous mode
only affects filtering based on unicast MAC addresses.  Since ARP requests
are sent as broadcasts, promiscuous mode has absolutely no effect on their
visibility.

What you're seeing here is a different sort of "promiscuity".  Since BSD
implements the usual "weak end-system model", an IP packet is considered
locally deliverable if its destination address matches *any* of the local
machine's IP addresses, regardless of whether the address is associated
with the packet's interface of arrival.  Although that's only a "layer 3
issue" per se, for consistency ARP needs to use the same criterion for
matching the target IP address (and perhaps even uses the same lookup
routine).  Hence it may reply to a request for a different interface's IP
address, but of course in many cases this is exactly what's wanted.

It sounds like you're connecting the LAN and the OPT1 to the same physical
network (presumably to get around the limitations of the bridging code),
and the problem only exists for that reason.  There's no conflict in
principle between having a given device act as both a bridge and an
endpoint, but apparently the FreeBSD bridging code can't handle that, thus
requiring the extra interface.  If the two interfaces were on physically
separate networks, you'd have no problem.

> To actually fix the problem once I'd identified it (and that took me
> quite a while) I simply swapped the Network Ports for LAN and OPT1
> over in the Assign Network Ports page on M0n0 and I haven't had a

It sounds like the MAC address chosen for the ARP reply may depend on the
order of interfaces in the system, and that's why the swap fixed it.  But
in principle, the bridging interface (assuming that in can *only* be used
for bridging) doesn't need to support IP or ARP at all.  Perhaps disabling
IP isn't feasible due to other implementation limitations (e.g., perhaps
not bringing the interface "up" prevents bridging), but it should at least
be possible to disable ARP on a given interface with "ifconfig -arp".

You might try that and see if it cures the problem even with the "wrong"
interface order.  If so, then as long as the restriction that bridging
interfaces are "otherwise useless" remains, then having the bridging setup
disable ARP would be desirable, and might cure some of the "I enabled
bridging and everything stopped working" problems.

> problem since (though an alternative if this doesn't work is to set up
> your client PCs to load the static ARP entry into the table at boot).

Static ARP entries should always be regarded as a measure of desperation,
since they're just "time bombs" waiting to bite you when you swap some
hardware.  And it sounds like there are better solutions for this.

					Fred Wright