Date: Thu, 6 Aug 2009 04:20:01 -0700 (PDT) From: Barney Cordoba <barney_cordoba@yahoo.com> To: Jack Vogel <jfvogel@gmail.com>, Julian Elischer <julian@elischer.org>, David Christensen <davidch@broadcom.com> Cc: Jack F Vogel <jfv@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "d@delphij.net" <d@delphij.net> Subject: RE: em(4): sending ARP regardless of NOARP flag Message-ID: <692150.91493.qm@web63906.mail.re1.yahoo.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339EC3813D2@IRVEXCHCCR01.corp.ad.broadcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- On Wed, 8/5/09, David Christensen <davidch@broadcom.com> wrote: > From: David Christensen <davidch@broadcom.com> > Subject: RE: em(4): sending ARP regardless of NOARP flag > To: "Jack Vogel" <jfvogel@gmail.com>, "Julian Elischer" <julian@elischer.org> > Cc: "Jack F Vogel" <jfv@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?692150.91493.qm>