--- On Wed, 8/5/09, David Christensen <davi...@broadcom.com> wrote:
> From: David Christensen <davi...@broadcom.com> > Subject: RE: em(4): sending ARP regardless of NOARP flag > To: "Jack Vogel" <jfvo...@gmail.com>, "Julian Elischer" <jul...@elischer.org> > Cc: "Jack F Vogel" <j...@freebsd.org>, "freebsd-net@freebsd.org" > <freebsd-net@freebsd.org>, "d...@delphij.net" <d...@delphij.net> > Date: Wednesday, August 5, 2009, 3:54 PM > > >> I don't see how arping > or not can be a driver problem, the driver > > >> just sends packets queued by the stack, there > exists NO > > mechanism to > > >> communicate that kind of thing down into the > driver, -arp is > > >> something that must be negotiated in the > stack somewhere, > > as for it > > >> working with broadcom... > > >> <shrugs> > > >> > > >> > > > except for the system management stuff. > > On the bce(9) driver does it display the "MFW" flag during > driver load? That would indicate whether NC-SI style > management > firmware is running which would be unexpected on a NIC > card. > If the Intel LOM is connected to a baseboard management > controller > or service processor then the BMC or SP are likely > generating > the ARP. What's the source MAC address of the > ARP? Does it > match the LOM's MAC address or the MAC address of any BMC > or SP? > The latter would generally be printed on a tag on the > system or > perhaps in a BMC setup screen visible during POST. The em driver calls arp_ifinit() when an address is set which causes an ARP to go out when a new address is set. It seems that the ARP logic should know not to send it out, but you could certainly add a check in if_em to avoid calling that. It seems that Bill Paul cloned drivers don't use such logic so the broadcoms don't have it. Barney _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
