SUMMARY: Re:Network Problem

From: Sukhmeet Singh (
Date: Wed Sep 13 1995 - 05:31:24 CDT

Sorry for the late reply. But as they say 'better late than never' so here
it is ;-)

>I have got three questions and would like you feedback :
>Q1. I intend to put a PC on our existing network which is a 10base2. My
> question is if anyone has this kind of setup and is able to send
> and receive mail from not only unix boxes but also from Mac and PCs.
> If yes what software you use? Is it a shareware like Eudora ? If you
> are using MS-Mail, is it capable of handing binhex ?

Thanks to (Jerry Weber) (David G. Roberts) (Steve Gray) (Andy McCammont)

I was suggest that I run pop2 or pop3 which we already are running. The
general concensus was to run Eudora. Other options like running PC/TCP with
its companion product Mail-It was also suggested.

I finally ended up installing Eudora and it seems to work file :-)

>Q2. On our BSD machine which is a SunOS foo 4.1.2 8 sun4c, if I do
> spray -c 50 foo, I get the following message :
> sending 50 packets of lnth 86 to foo ...SPRAYPROC_CLEAR RPC: Program
> not registered. I wonder what's wrong with this machine or spray ??

Thanks to (Jerry Weber) (Tim Pointing) (Steve Gray) (Andy McCammont)

The problem just went away as soon as I added the following in the
/etc/inetd.conf :-
sprayd/1 dgram rpc/udp wait root /usr/etc/rpc.sprayd rpc.sprayd

It was stupid of me to miss something as simple as that.

>Q3. The same machine which is mentioned in Q2 is our terminal server and
> most of the times it gives very slow turn around time on ping -s foo.
> ping -s foo
> PING 56 data bytes
>64 bytes from ( icmp_seq=0. time=1. ms
>64 bytes from (
>64 bytes from (
>64 bytes from (
> ^C
> PING Statistics----
> 9 packets transmitted, 4 packets received, 55% packet loss
> round-trip (ms) min/avg/max = 1/1515/3028
> Other times it seems to be OK. This terminal server is serving xterms,
> on two different subnets. One of the subnet on which the terminal
> server resides seems to be OK but the other subnet freezes
> every now and then. We also have a SunOS bar 5.4 Generic_101945-27
> sun4c sparc IPX on the problem subnet which is our print server running
> news. Following is how we have the setup :
> foo(Terminal Server) PCs xterms |----------|
> | | | | |
> o---------------------------------------------------------| |
> | CISCO |
> Problem subnet | |
> o---------------------------------------------------------| |
> | | | | |
> bar(Print Server) PCs xterms |----------|
> I would like to know why this subnet freezes. I have tried a different
> ping binary and it shows the same problem. I took foo of the network
> and tried pinging with only the transceiver on, the problem DIDN'T go
> away.
Thanks to (Tim Pointing) (Andy McCammont)
goff@CAST.MsState.Edu (Don Goff)
admin@maryanne.UCSD.EDU (System Administrator)

There were few suggestion on the above questions :

Tim suggested that I should look at the DNS IP-to-name lookup.

Andy suggested that I should ping from the same subnet as the T/S to see if
it's the subnet or the router.
If it's still slow, check the stats on the other machines on the subnet to see
if they're slow as well. If it's the router, check your default routes on the
kit, and the router config.

Don wrote :

I really don't have this particular problem but when I have network
problems here is what I do:

It would be helpful if you use transceivers at each workstation to have
the kind that show collision detection.

One thing to check is that all ethernet connections are made properly. If
they are notmade correctly, they can cause all kinds of havoc.

Another thing to try is to disconnect each computer system one at a time
and see if the problem goes away.

This is all kind of archaic but without network monitoring equipment or
a network expert, this is what I do and it usually works.

admin@maryanne.UCSD.EDU (System Administrator) wrote :
We had a host on our network that could reach most others just fine,
but couldn't see two at all, and a third about 50% of the time. By
switching this host with another, we found that the problem was
position-dependent on the LAN, not host-dependent!

The cause turned out to be reflections caused by a segment of RG-59
coax that was in a completely different room. The norm for our net
is 50ohm RG-58 coax, while this RG-59 coax was 75 ohms. Hence, some
requests were being partly reflected!

The moral to our story is: When you begin to see strange network
errors like "NFS server not responding", etc., but later it works,
check the network itself - the cables and terminators. Maybe this
will work for you?

Thanks to all who responded. It tried every bit of suggestion on Q3 but
it didn't help me get rid of the problem. I guess I will have to get a TDR
at some stage and find out exactly what's happening.

Cheers !

_/ Sukhmeet (Joey) Singh _/
_/ Systems Administrator _/
_/ MDS, CITRI, 723 Swanston St, Carlton, 3053 _/
_/ email: _/
_/ +61-3-282-2484 _/
_/ +61-3-282-2490 _/

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:33 CDT