SUN networking problems

From: Pete Turnbull <>
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, the broadcast address is For the
class B network, the broadcast address is, and
for the class A network, it's 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 with subnet mask, so
the last 9 bits are the host part):

# ping -c 2
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=1 ms
64 bytes from icmp_seq=0 DUP! ttl=255 time=1 ms
64 bytes from icmp_seq=0 DUP! ttl=255 time=3 ms
64 bytes from icmp_seq=0 DUP! ttl=60 time=3 ms
64 bytes from icmp_seq=0 DUP! ttl=255 time=4 ms
64 bytes from icmp_seq=0 DUP! ttl=255 time=39 ms
64 bytes from icmp_seq=1 ttl=255 time=1 ms

---- 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
> 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, pissaro ?
           ? -> (multicast) ETHER Type=D709 (Unknown), size = 60 bytes
           ? -> (multicast) ETHER Type=D709 (Unknown), size = 60 bytes
    lanmodem -> ETHER Type=0800 (IP), size = 146 bytes
    lanmodem -> IP D= S= LEN=132,
    lanmodem -> UDP D=2071 S=1025 LEN=112
        indy -> lanmodem ETHER Type=0800 (IP), size = 86 bytes
        indy -> lanmodem IP D= S= LEN=72,
        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, 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,
> 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