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
=0A=0A--- On Wed, 8/5/09, David Christensen <davidch@broadcom.com> wrote:= =0A=0A> From: David Christensen <davidch@broadcom.com>=0A> Subject: RE: em(= 4): sending ARP regardless of NOARP flag=0A> To: "Jack Vogel" <jfvogel@gmai= l.com>, "Julian Elischer" <julian@elischer.org>=0A> Cc: "Jack F Vogel" <jfv= @freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "d@delp= hij.net" <d@delphij.net>=0A> Date: Wednesday, August 5, 2009, 3:54 PM=0A> >= >> I don't see how arping=0A> or not can be a driver problem, the driver = =0A> > >> just sends packets queued by the stack, there=0A> exists NO =0A> = > mechanism to =0A> > >> communicate that kind of thing down into the=0A> d= river, -arp is =0A> > >> something that must be negotiated in the=0A> stack= somewhere, =0A> > as for it =0A> > >> working with broadcom...=0A> > >> <s= hrugs>=0A> > >>=0A> > >>=0A> > > except for the system management stuff.=0A= > =0A> On the bce(9) driver does it display the "MFW" flag during=0A> drive= r load?=A0 That would indicate whether NC-SI style=0A> management=0A> firmw= are is running which would be unexpected on a NIC=0A> card.=0A> If the Inte= l LOM is connected to a baseboard management=0A> controller=0A> or service = processor then the BMC or SP are likely=0A> generating=0A> the ARP.=A0 What= 's the source MAC address of the=0A> ARP?=A0 Does it=0A> match the LOM's MA= C address or the MAC address of any BMC=0A> or SP?=0A> The latter would gen= erally be printed on a tag on the=0A> system or=0A> perhaps in a BMC setup = screen visible during POST.=0A=0AThe em driver calls arp_ifinit() when an a= ddress is set which causes=0Aan ARP to go out when a new address is set. It= seems that=0Athe ARP logic should know not to send it out, but you could c= ertainly=0Aadd a check in if_em to avoid calling that. It seems that Bill P= aul =0Acloned drivers don't use such logic so the broadcoms don't have it.= =0A=0ABarney=0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?692150.91493.qm>