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