Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!rochester!bbn!uwmcsd1!ig!agate!ucbvax!bgsu.EDU!gruber
From: gruber@bgsu.EDU.UUCP
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re:  Hacking CMU sources to TurboC
Message-ID: <8806031044.aa21819@Louie.UDEL.EDU>
Date: 31 May 88 12:02:19 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33
Posted: Tue May 31 08:02:19 1988


bkc@omnigate.clarkson.edu mentioned a problem with getting his turbo c port
of CMU's pcip ping to work in server mode unless the host's arp cache entry
was purged.

We are having a similar problem with the IBM pcip code. The problem goes
away, whether the pc is set in server mode or client mode ping, when we
delete the arp entry from the host, a 4.3 BSD machine.

We thought that it might be a timing problem, but when we examined the traffic
it didn't appear that the host was sending a ARP response if there was an
entry in its arp cache for the requester. We also deleted one 4.3 bsd machine
entry from the other's cache, leaving the other 4.3 machine's entry in the
other. The 4.3 machines wouldn't talk to each other until the other cache
entry was purged too. We looked at the 4.3 source and it looks to us like
this would be the expected behaviour.

How sure are you that the host really is sending a ARP response?

It looks to me like the 4.3 ARP code trailer negotiation stuff might be the
reason that the 4.3 stuff is funny. The new TCP/IP source recently posted
to Usenet by Berkeley doesn't look like it would have the same awkward
behaviour, but maybe I'm wrong.

We don't have these problems when talking to an Ultrix computer.

I hope this helps.

Can anyone shed any light on this? Is there any good reason that a host
shouldn't send an ARP response if it has any entry for the requestor in its
cache?

John Gruber gruber%andy.bgsu.edu@relay.cs.net     tut!bgsuvax!gruber