Great, thanks to everyone who responded (or even mentally sympathized).
The problem was that I extended a thinnet segment and added a new system at the
end. I then could not communicate with systems beyond a repeater at the far end
of the segment. In retrospect the explanation is obvious, though I was
deflected because systems beyond the repeater were receiving packets.
The problem was simply the segment being over length. A couply of people
(Hal Stern got there first of course) pointed out that my analysis was wrong
and that an overlong net would result in failure to communicate, and not errors
or collisions being logged. This should have been clear to me, but on Friday
evening and all that...
I confirmed this with two tests:
1) I took one lab off the segment, this cured the problem.
2) I tried a new transceiver, just in case. No change.
There were various intelligent alternative suggestions:
Tim Diebert (Tim_Diebert.PARC@com.xerox) suggested adding a few more metres of
cable to move any deadspot created by standing waves. Would that you had been
correct Tim.
Hal Stern (stern@com.sun.eng), In addition to sugesting fatal attenuation of
the signal, suggested possible IP or ethernet address problems. He also pointed
out that my expectation of seeing a complete arp transaction from traffic(1)
run on one of the parties was wrong as one does not see ones own transmissions.
Gordon (gorpong@sbcoc.com) suggested making an intermediate system publish
the relevant entries in its arp table. This would only have postponed my
problem, but might have indicated a different fault.
Marina Hensley (marinah@com.synoptics) suggested corrupt arp tables and that I
delete the entries and start again.
Joerg Hertzer (Joerg.Hertzer@rus.uni-stuttgart.de) like Hal pointed pointed out my false assumption and suggested excessive attenuation.
Daf Tregear (daf@uk.ac.man.cs) Reported that they have run into problems with
cheap mini transceivers. We do have lots of PCs on the segment, but all with
reputable boards. The Suns are all on Isolan full size devices that have given
us no problems in the past.
master@mil.navy.dt.oasys suggested that the (incomplete) entry in the arp
listing could indicate a failure to resolve the IP address in the hosts file.
Not the problem, but good try
Well, thanks again to everyone, including any not mentioned above. Looks like
I am going to have to get the step ladder and a roll of cable out and start a new segment.
Dave Plummer, University College Hospital, London UK
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT