Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Hacking CMU sources to TurboC
Message-ID: <8805281547.AA02487@vax.ftp.com>
Date: 28 May 88 15:47:55 GMT
References: <8805271627.aa21337@Louie.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22

I see several possible areas where the problem could be:

1. The transmit ISR might not be re-enabling the board fast enough to see the
ARP reply.  Presumably Turbo's fault, but I can't guess why.

2. The ARP module might be broken in a way which prevents it from handling
incoming replies in general.  Presumably also Turbo's fault.

3. You may be misunderstanding the architecture of PCIP: Does host A send a
second Echo Request packet?  If so, it might work, where the first failed.
This is because the EtDemux task is the context that gets blocked waiting for
the ARP reply (when it upcalls ICMP, and ICMP down-calls in_write()).  Since
EtDemux is blocked, nobody processes the ARP reply (look carefully at the
counts bumped by the ISR, not by EtDemux or indemux while on that quiet
network, you may see the packet you want actually arrived).  in_write()
times out waiting for the ARP that never gets processed, the Echo Reply
never gets sent.  The ARP and ICMP structure of PCIP still has some
weaknesses for use as a server, even after the work Drew added to the
MIT version.

James VanBokkelen
FTP Software Inc.