two questions

[sharkey@superk.physics.sunysb.edu]

> These are supposed to go into a remote machine (over 500 miles away); that's
> enough reason for me to dump these buggers. However, I'll continue pursuing
> a fix for the problem for posterity's sake.

Lucky you.  My machines are split between the New York area and the Tokyo
area.  When something goes wrong, "easy access" is not a likely phrase to
pop into mind.  Luckily most of the people I work with are fairly competent.

> Machine 'A' has the Realtek. Pinging B->A yields the following with tcpdump
> on A:
> 
> 09:47:55.568312 P [|llc]
> 0:0:0:0:0:0:0:0:0:0:0:1 0004 0:
> 
> One of those per ping. Pinging A->B yields the following with tcpdump on A:
> 
> 09:48:00.789675 M 6e:3a:20:52:4f:4f 1:0:0:0:0:0 5420 14:
> 
> although I think that was coincidental. Subsequent pings show nothing.

That's really weird.  I may be interpreting that incorrectly, but doesn't
that mean that the card is advertising itself as having hardware address
1? 

What does the hardware address for the realtek appear to be when you
type "ifconfig"?

> Yeah. `arp -an` shows:
> 
> ? (<B's IP ADDRESS>) at <incomplete> on eth0
> 
> Likewise, the arp stuff is in B's arp cache, also showing <incomplete>.

So the arp is failing.  If the arp is failing, ping is meaningless.

You can bypass arp by setting the entry in the arp cache manually, but I'm
not sure what that would tell you if you tried to do that...

Eric
 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.