Menu
▾
▴
RE: [E1000-devel] Erroneous ARP packets!!!
|
From: Hoy, M. <mh...@se...> - 2004-05-28 18:33:23
|
Here you go:
# ethtool -e eth1 offset 0x13h length 2
Offset Values
------ ------
0x0013 08 0a
# ethtool -e eth1 offset 0x23h length 2
Offset Values
------ ------
0x0023 ff ff
==-=
Mark
-----Original Message-----
From: Venkatesan, Ganesh [mailto:gan...@in...]
Sent: Friday, May 28, 2004 11:17 AM
To: Hoy, Mark; e10...@li...
Subject: RE: [E1000-devel] Erroneous ARP packets!!!
Mark:
What you are seeing is the result ASF/WoL. Could you send me the output
of the following?
ethtool -e eth1 offset 0x13h length 2
ethtool -e eth1 offset 0x23h length 2
Thanks,
ganesh
-------------------------------------------------
Ganesh Venkatesan
Network/Storage Division, Hillsboro, OR
-----Original Message-----
From: Hoy, Mark [mailto:mh...@se...]
Sent: Friday, May 28, 2004 10:48 AM
To: Venkatesan, Ganesh; e10...@li...
Subject: RE: [E1000-devel] Erroneous ARP packets!!!
It's even more interesting than I thought. Beleive it or not, the ARP
packets continue even when the system is powered off!! (I guess the lan
chips are powered up to some degree though).
If I pull the power plug to the system, the ARPs stop. If I then
re-apply
power and start up the system the ARPs start.
From Linux I can not affect the ARPs from occuring, even taking the
interface down doesn't stop this thing.
# ifconfig eth1 down
The interface in question is hooked up to another Linux box (via a
straight
through cable) to another E1000
card.
I have also run this from the 'other Linux box' and I see the packets
from
there also. (It's what I watched when I powered down the 'problembox').
Here is a sample from the other box.
blaster# tcpdump -i mbblast -x -s 1518 -p
18:02:10.613739 arp who-has 0.0.0.0 (Broadcast) tell 0.0.0.0
0001 0800 0604 0001 0000 0000 0000 0000
0000 ffff ffff ffff 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000
From the box itself, I can see the packets by doing the following.
I shut off promisc mode and run the tcpdump command on that interface.
problembox# ifconfig eth1 -promisc
problembox# tcpdump -i eth1 -x -s 1518 -p
=-=-
Mark Hoy
-----Original Message-----
From: Venkatesan, Ganesh [mailto:gan...@in...]
Sent: Friday, May 28, 2004 9:43 AM
To: Hoy, Mark; e10...@li...
Subject: RE: [E1000-devel] Erroneous ARP packets!!!
Mark:
Could you describe your setup (test system connected back to back to
another system that runs the tcpdump)?
Thanks,
ganesh
-------------------------------------------------
Ganesh Venkatesan
Network/Storage Division, Hillsboro, OR
-----Original Message-----
From: e10...@li...
[mailto:e10...@li...] On Behalf Of Hoy, Mark
Sent: Thursday, May 27, 2004 10:58 PM
To: e10...@li...
Subject: [E1000-devel] Erroneous ARP packets!!!
I have erroneous ARP packets being sent from a NIC!! From my setup, I
don't
believe I should be seeing ANY packets transmitted from the device. I
have
one system with the same NIC chipset on a PCI card and that system works
perfectly. There are NO packets being transmitted from that NIC. On the
other system, every couple of seconds the NIC sends an ARP, (see below
for
details).
Where the heck are they coming from?
Why do I have different behavior from a system with a built-in E1000 NIC
vs.
one with the NIC in a PCI card? Is the BIOS to blame? Shouldn't the
E1000
driver fully take over the card once the driver has loaded? The systems
are
running the same software configured the same way.
I've tried the latest 5.2.39 E1000 driver (with a 2.4.20 kernel) and
also
the stock
5.2.30.1-k1 driver with a 2.4.26 kernel . Both version show the same
problem
and both kernels are from kernel.org.
With both kernel+driver combinations I get the following:
# tcpdump -i eth1 -x -s 1518 -p
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: listening on eth1
05:30:49.702331 arp who-has 0.0.0.0 (Broadcast) tell 0.0.0.0
0001 0800 0604 0001 0000 0000 0000 0000
0000 ffff ffff ffff 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000
Details on the setup:
The /etc/modules.conf contains:
options e1000 RxIntDelay=500 RxDescriptors=4096 TxDescriptors=256
# lspci | grep Gig
02:05.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet
Controller
(rev 02)
NOTE the TX packet counter
# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:10:DC:FE:CD:24
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4215533 errors:2 dropped:0 overruns:0 frame:2
TX packets:616 errors:2 dropped:0 overruns:0 carrier:2
collisions:953 txqueuelen:1000
RX bytes:1919728906 (1830.7 Mb) TX bytes:39424 (38.5 Kb)
Base address:0xc000 Memory:e2000000-e2020000
# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=static
IPADDR=""
NETMASK=""
ONBOOT=yes
PROMISC=yes
# uname -r
2.4.20-2
From /var/log/messages:
May 28 00:38:22 SM kernel: Intel(R) PRO/1000 Network Driver - version
5.2.39
May 28 00:38:22 SM kernel: Copyright (c) 1999-2004 Intel Corporation.
May 28 00:38:22 SM kernel: eth1: Intel(R) PRO/1000 Network Connection
And now with a earlier version of the driver (but a later version of the
kernel)
# uname -r
2.4.26-1
From /var/log/messages
...
May 27 23:57:12 SM kernel: Intel(R) PRO/1000 Network Driver - version
5.2.30.1-k1
May 27 23:57:12 SM kernel: Copyright (c) 1999-2004 Intel Corporation.
May 27 23:57:12 SM kernel: eth1: Intel(R) PRO/1000 Network Connection
May 27 23:57:12 SM kernel: Transmit Descriptors set to 256
May 27 23:57:12 SM kernel: Receive Descriptors set to 4096
...
=-=-=-=-
Mark Hoy
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
E1000-devel mailing list
E10...@li...
https://lists.sourceforge.net/lists/listinfo/e1000-devel
|