more NetGear mising ARPs

[Neale Banks]

On Sun, 13 Jun 1999, Keith Owens wrote:

> Let me see if I have this right.  Three machines on a LAN without a
> switch in the way.
> 
> A - Another box.
> B - Bad tulip box.
> C - Cisco.
> 
> ping -s 1400 from A to C stops B completing an ARP from B to C.
> Correct?

Yes, that's an accurate summary.  More generally, it appears to be any
traffic between A and C that stops that ARP from B to C completing (the
problem is more or less permanent when there is A-B activity on the
subnet).

And then putting the card into promiscuous mode consistently makes the
problem go away.

> That is seriously wierd.

That's what I thought.  But I take some small consolation from being able
to make the problem perform or not depending on definite things.

> First thing to test is what A and B can see.
> Try this sequence.  Use IP addresses, not host names so we don't have
> DNS traffic getting in the way.

Ah, one exta piece of data: the tulip card is (today at least) my only
access to this machine - so stopping the network etc is not an option.

Also, the card is not completely hosed when it can't ARP the Cisco as I'm
connecting to it via A (but there the initial connection is _to_ the
tulip-host).

Things I could do:

- run tcpdump on either host (A should be able to see if the ARPs are
getting out of B, B should be able to tell us if the card is seeing the
replies?).  Looking in the archives on tux William Earl did an experiment
like this last month which shows that his tulip-host was puting the ARP
requests on the wire but not seeing the replies (via tcpdump) even though
teh ARP-replies were definitely on the wire, see:
<URL:http://www.tux.org/hypermail/linux-tulip-bug/1999-May/0011.html>.  
That mail also refers to a "terrible bug" in the PNIC chip and the BSD
workaround for it.  Any lead here?

- run tulip-diag/whatever to try to gleam the internal state of the card
both in failed and non-failed mode.  Can we get at the mac-layer setup
information you eluded to earlier?

Thanks,
Neale.