Followup: Netgear missing ARPs

[William J. Earl]

Neale Banks writes:
...
 > If your theory is correct, then this observation would imply that somehow
 > amongst the inbound arp query (ethernet broadcast) and outbound arp reply
 > (ethernet unicast?) the card figures out it's MAC address.

       I don't think this can be the issue.  The outgoing packets have
the correct MAC address, and the card sees some, but not all, ARP replies.
That is, some ARP attempts work and some do not, for various hosts on
the same hub.  That is, system A has a PNIC.  It may well be able to ARP system
B, but not C or D, and can talk to C if C does an ARP to A first, but will
still be unable to ARP D unless D does an ARP to A.

...
 > *generally: I haven't tested this one, but have seen situations pointing
 > to a hypothesis that the card/system behaviour is different when it is in
 > the state of having sent an arp query and the arp is "incomplete".  I
 > figure the test should go something like:
 > (1) PNIC arps OTHER
 > (2) confirm arp "incomplete"
 > (3) clear arp cache on OTHER
 > (4) OTHER arps PNIC
 > (5) check arp cache on both sides.

      On my systems, the above case results in a good ARP cache on both
sides and PNIC can now connect to OTHER just fine.  This is true even
if step (3) is omitted.

     I suspect there is something wrong with how the PNIC decides to
accept certain packets, perhaps related to the timing between packets
(which might account for the effect of other traffic to OTHER).  I wonder
if the PNIC sometimes fails to look at a packet if it closely follows a 
different packet, not addressed to PNIC, on the wire and is small.