SUN networking problems

From: Pete Turnbull <pete_at_dunnington.u-net.com>
Date: Tue Mar 27 15:34:07 2001

On Mar 27, 9:35, Arno Kletzander wrote:
> New details on the SUN networking issue became available yesterday
> [...] However, both SUNs' transceivers and the cable work as each
> SUN can detect the other's presence. The
> printer cannot be pinged or sent data to

> Peter Turnbull wrote:
> >Have you tried pinging the printer by it's IP address instead of
> >it's name? Try a broadcast ping?
>
> As we're not too familiar with the commands, how is a broadcast
> ping done?

Instead of giving the IP address of a particular machine, give the
broadcast address of the local subnet. The broadcast address is the subnet
address but with the host part set to all 1's. For example, for the class
C network 192.168.5.0, the broadcast address is 192.168.5.255. For the
class B network 176.18.0.0, the broadcast address is 176.18.255.255, and
for the class A network 10.0.0.0, it's 10.255.255.255. You should get a
response from every device on that segment (every device in that broadcast
domain, actually) which has an IP address within the subnet range. For
example (my test subnet is 144.32.80.0 with subnet mask 255.255.254.0, so
the last 9 bits are the host part):

# ping -c 2 144.32.81.255
PING 144.32.81.255 (144.32.81.255): 56 data bytes
64 bytes from 144.32.80.11: icmp_seq=0 ttl=255 time=1 ms
64 bytes from 144.32.80.14: icmp_seq=0 DUP! ttl=255 time=1 ms
64 bytes from 144.32.80.99: icmp_seq=0 DUP! ttl=255 time=3 ms
64 bytes from 144.32.80.80: icmp_seq=0 DUP! ttl=60 time=3 ms
64 bytes from 144.32.80.22: icmp_seq=0 DUP! ttl=255 time=4 ms
64 bytes from 144.32.81.96: icmp_seq=0 DUP! ttl=255 time=39 ms
64 bytes from 144.32.80.11: icmp_seq=1 ttl=255 time=1 ms

----144.32.81.255 PING Statistics----
2 packets transmitted, 2 packets received, +5 duplicates, 0% packet loss
round-trip min/avg/max = 1/7/39 ms
#

You can see it stopped when it got a response to the second 'ping' it sent
(because I told it to use -c 2, ie send only two pings).

The reason I suggested a broadcast ping is that anything that hears that
should respond. The trouble is, no sensible implementation will do that
for anything other than a local subnet, and if the printer doesn't have a
proper IP address in the same range as the Suns (which it may not if it's
trying to RARP or BOOTP) it won't even respond to a broadcast. So, after
thinking about it, I'm not sure it will tell you much at the moment.

> >Have you checked the printer settings to make sure it's using the
> >correct IP address? Is that set from its panel, or by RARP/BOOTP/
> >DHCP? If the latter, it needs a server to boot.
>
> Tony Duell wrote:
> >That printer isn't attempting to get information (IP address,
> >software, whatever) from a server, is it?
>
>
> We're trying hard at the moment to find the printer manual. We know we
have
> it somewhere, but it's buried...

Another way to see what's happening, is to use 'snoop' if you have it on
one of the Suns (tcpdump for Linux/BSD/etc is similar). You need to be
logged in as root, and type "snoop -v" or "snoop -V". That will show you
(in some detail; -V gives less detail) all the traffic visisble to the le0
interface. For example:

# snoop -V
Using device ec0 (promiscuous mode)
________________________________
        indy -> (broadcast) ETHER Type=0806 (ARP), size = 42 bytes
        indy -> (broadcast) ARP C Who is 144.32.80.34, pissaro ?
________________________________
           ? -> (multicast) ETHER Type=D709 (Unknown), size = 60 bytes
________________________________
           ? -> (multicast) ETHER Type=D709 (Unknown), size = 60 bytes
________________________________
    lanmodem -> 144.32.81.255 ETHER Type=0800 (IP), size = 146 bytes
    lanmodem -> 144.32.81.255 IP D=144.32.81.255 S=144.32.80.99 LEN=132,
ID=53598
    lanmodem -> 144.32.81.255 UDP D=2071 S=1025 LEN=112
________________________________
        indy -> lanmodem ETHER Type=0800 (IP), size = 86 bytes
        indy -> lanmodem IP D=144.32.80.99 S=144.32.80.11 LEN=72,
ID=56653
        indy -> lanmodem UDP D=53 S=2158 LEN=52
        indy -> lanmodem DNS C port=2158
________________________________
        indy -> (broadcast) ETHER Type=0806 (ARP), size = 42 bytes
        indy -> (broadcast) ARP C Who is 144.32.80.34, pissaro ?
________________________________
           ? -> (multicast) ETHER Type=D709 (Unknown), size = 60 bytes
________________________________

The first packet is one machine asking who knows the MAC address for a
particular IP address; the next two are IPX discovery packets from a smart
hub; fourth is a router advertising its connectivity to anyone who cares to
listen; fifth is a machine making a DNS lookup request.

> >Hmm... What are the LEDs on the transceivers labelled?
>
> The LEDs on the transceivers are only PWR (Power), SQE (as
> on yours) and COL (which must be Collision). Nothing for TX or RX,
although
> that would be much more helpful for troubleshooting.

If both the SQE and Collision LEDs flicker when you try to send something,
that's not anything to worry about. If SQE is enabled on a transceiver, it
sends a sort of artificial collision burst after each packet (which lights
up SQE) and that is detected by every transceiver's collision detect
circuit as a normal afterlude to the packet. You only worry when you see
collisions without SQE :-)

-- 
Pete						Peter Turnbull
						Network Manager
						Dept. of Computer Science
						University of York
Received on Tue Mar 27 2001 - 15:34:07 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:05 BST