sean@fiamass.ie (Sean Mc grath) (12/12/90)
Hello there,
We are having a small problem with our TCPIP for the PC from FTP Ltd.
We have a two machine network, each machine is a PC.
From a reboot of both machines the sequence of events is as follows :-
Machine A Machine B Result
========= ========= ======
ping B fails with "HOST NOT RESPONDING"
ping A succeeds
ping B succeeds !
In effect, this means we must perform this little dance before we
can startup our socket software.
Does anyone know what is going on?
Sean Mc Grath (sean@fiamass.ie)
12 Clarinda Park North
Dun Loaghaire
Co. Dublin.
Ireland.sean@fiamass.ie (Sean Mc grath) (12/14/90)
Apologies for being a bit short in information with my last posting. here
is a more complete description of my problem.
Hardware :-
Two Nec 386 PC machines.
1 with wd8003 ethernet board.
1 with 3c503 ethernet board.
Software :-
PC/TCP from FTP software version 2.05
The machines are connected over thin ethernet forming a bare two machine
network.
Configuration is as follows :-
Machine A Machine B
========== ==========
IP address : 192.9.200.2 IP address : 192.9.200.7
Ethernet : 2:60:8c:d:a1:a3 Ethernet : 0:0:c0:d3:55:18
3c503 ethernet board. WD8003 ethernet board.
local file used on either end as hosttable. (Files are identical)
time ordering of events is as follows :-
Machine A Machine B Result
========== ========== =======
reboot. Reboot.
inet arp cache empty
inet arp cache empty
ping A ARP fails. Host unreachable.
inet arp cache empty
inet arp cache empty
ping B Succeeds.
inet arp Entry for B in cache.
inet arp Entry for A in cache.
It seems to me that machine A must be caching the ethernet address of B
after B does "ping A" otherwise its own ping would fail. If so, why do
the caches look empty? Any help would be gratefully received.
Sean Mc Grath (sean@fiamass.ie)
Fiamass Ltd.
12 Clarinda Park North
Dun Loaghaire
Co. Dublin
Ireland.zweig@cs.uiuc.edu (Johnny Zweig) (12/14/90)
At a wild guess I would say it's an ARP problem. If neither machine is answering ARP requests, but both see the requests from the other host and update their ARP caches you cou ld have a stat in which each machine had to attempt to ping (or telnet/rlogin/ftp/anything else) the other for them to be able to talk. A way to test this would be to have A and B both ping C (which needn't actually exist) and see if they notice each other. -Johnny Guessing
jbvb@FTP.COM (James B. Van Bokkelen) (12/19/90)
Machine A Machine B Result
========== ========== =======
ping A ARP fails. Host unreach..
Tell me what INET DEBUG says on each machine at this point. In particular,
how many packets were received, and any non-zero error counts.
It seems to me that machine A must be caching the ethernet address of B
after B does "ping A" otherwise its own ping would fail. If so, why do
the caches look empty? Any help would be gratefully received.
B broadcasts an ARP request. A receives it, sends an ARP reply, and cleverly
(courtesy of PCIP) caches B's address, assuming that it will need it soon.
I seem to recall that this optimization is suggested in RFC 826...
My first guess is that the Ethernet card in B is defective, and can't
see broadcast packets. Compare the number of "unknown types" in INET
DEBUG and the number of "UDP no port listening" errors on A and B.
Most LAN OS file servers and Unix boxes produce some sort of periodic
broadcast, which you'll see in these counts (A & B would be roughly
equal if both boards were working).
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901