Messages in this thread |  | | Date | Tue, 3 Oct 2000 13:37:38 +0100 (BST) | From | Tigran Aivazian <> | Subject | 8139too and curious arp corruption on multi-homed hosts |
| |
Hi guys,
Imagine two machines, a laptop with 4 network cards (only 2 relevant here) and a desktop with 3 network cards (only 2 relevant here). All NICs are on different subnets and different physical networks (a switch and a hub) -- nothing clever like sharing the same physical network whatsoever...
Now, the problem is -- the interface on the laptop driven by 8139too NIC doesn't work. It generates interrupts but no packets get through. tcpdump-ing the situation from the desktop revealed that the 8139too interface did not reply to arp requests most of the time. But when the arp reply did come through it was registered onto the wrong interface on the desktop! Like this (from the desktop):
# arp -a penguin.homenet (192.168.2.7) at 00:50:DA:D9:98:E9 [ether] on eth0 penguin37.homenet (192.168.3.7) at <incomplete> on eth1 cisco.homenet (192.168.2.6) at 00:40:F9:17:F6:B2 [ether] on eth0 penguin37.homenet (192.168.3.7) at 00:A0:D2:11:B6:5D [ether] on eth2 penguin48.homenet (192.168.4.8) at 00:D0:B7:23:B4:B8 [ether] on eth2
penguin37 is the 3.7 interface on the laptop (8139too) and it should talk to eth1 (3.1) of the desktop but the arp entry says eth2 (4.8) interface which has nothing to do with it. Manually deleting it (arp -d penguin37) didn't help -- the eth1 entry still remained <incomplete> and so I can't ping penguin37 from desktop and can't ping desktop's "saturn31" (3.1 interface) from the laptop.
Any ideas?
I tried downing/rmmod-ing all other NICs so that no interrupt sharing occurs on the 8139too side -- didn't help. All other interfaces (the on the laptop function absolutely fine.
Both machines run 2.4.0-test9-pre9, of course.
Thanks, Tigran
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |