Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!CHUMLEY.TN.CORNELL.EDU!swb From: swb@CHUMLEY.TN.CORNELL.EDU Newsgroups: comp.sys.proteon Subject: FAL 1.2/BTI/Proteon problem Message-ID: <8812151224.AA09302@dainichi.tn.cornell.edu> Date: 15 Dec 88 12:24:42 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 63 >From IBMTCP-L@cunyvm Thu Dec 15 01:34:06 1988 Date: Wed, 14 Dec 88 12:59:24 CST Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List >From: "David L. Merrifield" Subject: FAL 1.2/BTI/Proteon problem To: Scott Brim Before we go crazy here, I thought I'd broadcast this cry for help on the net to see if anyone else has experienced similar behavior or had an opinion on the solution to our problem. Apology: Please forgive the length of this inquiry. Environment: FAL 1.2 with David Lippke's driver, IBM 4381-14 with BTI ELC, Proteon p4200 router at Release 8.0, thin-ethernet connecting the two. What works: We can ping/telnet/ftp from the IBM host to any other host on the ethernet, including PCs, Unix minis, etc. All of these other hosts can ping/telnet/ftp the Proteon p4200 router. What doesn't work: We are unable to ping/telnet/ftp from the IBM host to the Proteon p4200 router. All we get are timeouts, even after repeated attempts. Details: Our traces through the FAL code shows that (on a ping, for e.g.) FAL attempts to resolve the hardware (ethernet) address of the Proteon by sending an ARP Request, broadcast on the ethernet. FAL never receives the ARP Reply coming from the Proteon. With our limited debugging tools, we have determined that the Proteon is sending an ARP Reply, but there may be something screwy with the packet because the BTI never sends it down the channel to the FAL code. We contacted BTI and they indicated that they packet may not be passing the hardware diagnostic check for validity in the BTI box. We just happen to have two IBM 4381s and two BTI boxes (both exhibiting the same symptoms), so we used one to monitor the activity between the other 4381 and the Proteon. We ran the IPLable diagnostic program that BTI supplied with the box, putting the BTI in promiscuous mode and dumping all of the packets on the ethernet. We were unable to see any ARP Reply packets from the Proteon. BTI then gave us a zap to the diagnostic program that places the box in both promiscuous and diagnostic mode, which lets us see all packets on the ethernet, even those that fail the hardware error checking. When we ran the program, we could *finally* see the ARP Reply packets, *but* we noticed that the packet lengths reported by the program were not 60 bytes (as expected), but were varying lengths, usually in the range of 22-28 bytes. This would seem to indicate that the Proteon is sending out invalid ARP Reply packets, which the BTI is rejecting. We contacted Proteon and they weren't of much help. They seem to think that if the other hosts on the ethernet can trade ARP requests and replies with the p4200, then there can't be anything wrong with their box. Similar environments: We have contacted at another site who has the identical same configuration as us, and they aren't having the problem. And in conclusion: (Thanks for staying with me and reading this far :-) Is there anyone who might have any suggestions? ------------------------------------------------------------------------ David L. Merrifield Bitnet: DM06900@UAFSYSB University of Arkansas Phone: (501) 575-2901