em(4): sending ARP regardless of NOARP flag

[Jack Vogel]

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>

Jack


On Mon, Aug 3, 2009 at 12:39 PM, Xin LI <delphij at delphij.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Jack,
>
> I have observed that, even if -arp is specified when adding an IP
> address to the em(4) interface, an ARP request is still being sent.
> Here is a tcpdump from my network environment:
>
> 11:15:01.370256 00:13:72:66:b5:d7 > ff:ff:ff:ff:ff:ff, ethertype ARP
> (0x0806), length 60: Request who-has *.*.152.120 tell *.*.152.120, length
> 46
> 11:15:01.370270 00:15:17:92:39:0e > 00:13:72:66:b5:d7, ethertype ARP
> (0x0806), length 42: Reply *.*.152.120 is-at 00:00:5e:00:01:07, length 28
>
> (The first ARP request was sent from a Dell branded Intel 82541EI based
> NIC, the latter is from a cheaper server that is part of CARP
> configuration which is unrelated to the problem in response to the ARP
> request)
>
> I was originally under the impression that there is some bug in our ARP
> code but with a bce(4) card, the problem does not exist.  After a glance
> at e1000 driver code, it looks like that the e1000 NIC has a feature of
> hardware interception of ARP, can this be somehow connected?  The
> hardware in question is 82541EI based:
>
> em1 at pci0:7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05
> hdr=0x00
>    vendor     = 'Intel Corporation'
>    device     = '82541EI Gigabit Ethernet Controller'
>    class      = network
>    subclass   = ethernet
>
> Thanks in advance!
>
> Cheers,
> - --
> Xin LI <delphij at delphij.net>    http://www.delphij.net/
> FreeBSD - The Power to Serve!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (FreeBSD)
>
> iEYEARECAAYFAkp3PQkACgkQi+vbBBjt66A2CQCgt+8prSPRDKdOb61gdfj1zpcF
> q28An1/UXuo0bcEi4nwlUpYuqD8hR5Lo
> =56SA
> -----END PGP SIGNATURE-----
>