Hi!
"Rich Wales" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Robert Watson wrote:
>
> > There used to be a kludge that mapped the ether_header.ether_type
> > field of non-IP packets into the UDP port number for the purposes
> > of certain IPFW rules when bridging. This was pretty awful. :-)
>
> I should add something else. My bridge =does= pass ARP info between
> the two bridged NIC's. Thus, for example, a machine on the "rl0" side
> of the bridge can successfully use a default Internet gateway which is
> on the "xl0" side of the bridge (and "arp -a" on the rl0-side machine
> shows the hardware address of the xl0-side gateway).
>
> So the problem doesn't seem to have anything to do with ARP bridging.
> Even though ARP packets are being passed through the bridge, the bridge
> itself doesn't reply to ARP requests asking it for its own MAC address.
> (Or, to be more precise, it sometimes does send out ARP replies, but
> only sporadically and unpredictably.)
I am seeing exactly the same behaviour here. I have up-to-date
FreeBSD -STABLE code. What I am seeing is that the FreeBSD machine running
bridging does not answer ARP request asking for its own mac address. At
first I thought I was seeing a me-only problem, but it seems that it is not
the case. Also as Rich mentions, this problem is sporadic: it will work
sometimes (i.e. FreeBSD answers the ARP request) but not at other times. I
have not been able to determine the set of conditions that make the problem
occur. The behaviour seems consistent for an entire "booted" session: if it
works when the machine starts, it will always work, if it does not work when
the machine starts, it will never work.
Also I am using a combination of "rl", "ed" and "xl" cards.
I have all the setup to do testing and tracing of this problem. So if
anybody has suggestions I am available, this very problem is #1 on my work
list...
Patrick.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
