On Nov 2, 10:13, Arno Kletzander wrote:
> OK Pete (and everybody else, of course), I admit that was a *long* break
> since I brought that up last time - but now I think I have collected
enough
> information for a new chapter...So, where did we get stuck?
> OK, as the IP Adress of the SUN 1+ is 111.0.0.14 and the Subnet Mask
> ff:00:00:00 (says so at boot):
Which is correct for a Class A network...
> ping -s 111.255.255.255
> (if everything on the network is powered up and the PC is configured for
> TCP/IP transfer) gets answers from:
> hombre (111.0.0.14);the sending machine itself
> papa (111.0.0.23);the SUN SPARCstation 2 on the next desk
> ? (111.0.0.83);a PC I've finally set up for sniffing
>
> Nothing however from the printer. :-(
> No idea whether that helps, but if both the SUN 1+ and the printer are
> powered up, an arp -a shows:
> pa3 111.1.0.1 at (incomplete)
Is "pa3" the printer name? What that means is that the Sun's Ethernet
software "knows" that "pa3" means IP address 111.1.0.1, but nothing has
responded to any attempt to communicate with that IP address, so it doesn't
know its hardware address. On an Ethernet, as you probably know, the data
packet is wrapped in several layers of what you might think of as
envelopes.
The outermost one contains the MAC addresses of sender and intended
recipient, and is what is always used for the delivery of the packet to the
next (which may be the final) destination en route.
So for "hombre" to know how to send a packet to "pa3", it first looks up
pa3's IP address (in etc/hosts, or using DNS), and then broadcasts an ARP
(Address Resolution Protocol) packet (sender: hombre's MAC address;
destination: Ethernet broadcast address, FF:FF:FF:FF:FF:FF) containing that
IP address as data. Whoever owns that IP address is supposed to respond
with an ARP reply (same packet type, different flags inside, with sender:
pa3's MAC address; destination: hombre's MAC address). Thus hombre learns
pa3's MAC address, which it stores in it's ARP table, and uses to send a
packet (the one it originally wanted to send) to pa3's MAC address.
> and out of 25 packets I sniffed (Man, am I high now ;-)), 20 were ETHER
type
> 0806 (ARP), the remaining 5 were type 0800.
Without knowing what was in the packet headers, I can't say what they were.
But probably the ARP packets were hombre repeatedly broadcasting an ARP
request to get pa3's MAC address.
> OK, as I didn't finde snoop on the Suns (and didn't want to fiddle with
> compiling programs by myself at this stage...),
snoop is only available as a binary, from Sun themselves (or from SGI, for
the IRIX version). tcpdump and other similar programs are available as
freeware with source. tcpdump needs a library called libpcap, whicxh is
also used by other decoders/analysers, such as Ethereal.
> I set up a PC with a network
> card, packet drivers and EtherLoad 2.00. Connected this to the idle
transceiver,
> started with -r (record traffic), powered up one SUN and recorded the
first
> 10 packets from it, then powered up the printer and recorded until I had
25
> (the printer had then finished its warmup cycle and was displaying
"READY").
> Got only packets sent by the SUN (MAC: 08.00.20.09.BC.D7) destined for
> FF.FF.FF.FF.FF.FF (everybody?).
Probably ARP requests. FF.FF.FF.FF.FF.FF is the broadcast address
(destination, in this case). The next layer in the packet would tell you
what IP address it was ARPing for. BTW, Ethernet addresses are normally
represented with colons (':') separating the octets, not spaces or periods.
> The sniffer's HEX output file decodes to a lot of unreadable characters
if
> interpreted as ASCII; only in the second packet that appears after
switching
> the SUN on, the host name 'hombre' is readable.
> Decoding the whole data to decimal numbers show up the SUN's IP adress in
> all packets, the address the printer should have in the eighth and every
> following packet.
Yes, they won't mean much in that form. The format of an ARP packet is:
hardware type code (2 octets), protocol type code (2 octets), hex 06 (the
hardware address length, assuming Ethernet), hex 04 (the IP address length,
assuming Ethernet), opcode flags (16 bits giving the type of request/reply)
source MAC (6 octets), source IP (4 octets, all zeros if this is a
reverse-ARP), destination MAC (6 octets), destination IP (4 octets, may be
FFFFFFFF for a broadcast).
hombre's IP address appears because it's the sender address of the packets;
the name appearing in the second packet suggests it might be a NIS packet
of some sort.
> Is there a DOS based sniffer out there which will produce output as
> understandable as snoop?
There's an old version of LANdecoder that runs under DOS, I think. It's
not free, though, and I've no idea where to get a copy.
> >On most of the Ethernet-enabled printers I've come across (mostly HPs,
> Lexmarks, and Xeroxes) you >can do the setup from the front panel --
sometimes
> tedious, but usually not too hard to understand.
Some of the HP deskjets with JetDirect cards can only be setup/accessed by
telnet or RARP/BOOTP/DHCP.
> However, with us there is no sys admin - so how can we 'accomplish these
> tasks'?
You are your own sysadmin :-)
> CalComp Internal Ethernet Adapter
> Revision 4.11, Datecode 12/20 1994 10:20
> Burnin Value = 0 SRAM = 256K bytes, Novram = 128 bytes
> Ethernet address 00 C0 E2 00 0C 8E
That's the address you need for /etc/ethers on a RARP server (or
/etc/bootp.conf on a BOOTP or DHCP server for clients that talk something
more sophisticated than just RARP).
> Netware options:
> !!! Netware DISABLED (use 'N' menu to re-enable) !!!
Leave it this way unless you need Novell -- it's very broadcasty and
wasteful of bandwidth (a few machines won't be a bother, but a hundred on a
segment could)
> Auto sense ethernet type between Ethernet II and 802.3
> Apple EtherTalk options:
> EtherTalk DISABLED !!! (use 'N' menu to re-enable )
> Printer name: CalComp CCL600ES
> Internally stored zone name: *
> Ethertalk Phase 2
Leave this off too unless you need it.
> LPD ( remote printer queues ) options:
> LPD enabled
LPD refers to the use of the Berkeley 'lpr' line printer protocol, commonly
used by UNIX systems. This is the one your Suns want.
> But no idea on how to get this printed again to verify the settings
haven't
> changed (e.g. due to bitrot in the Novram)...
Some more experimentation is needed to be sure what all the symptoms really
mean. However, obviously the printer isn't responding to an ARP request
for what should be its own IP address. Therefore either it is using some
other IP address, or it has lost it's configuration and needs to be
supplied an IP address (by RARP or otherwise), or the interface is
broken/dormant.
I expect that this printer, which is quite old, can only use RARP (which is
an old and simple protocol, but still in use), not BOOTP or DHCP, to get an
IP address. If it were actually trying to do so, you ought to see some ARP
packets emanating from the printer, with the printer's MAC address as the
source, and the Ethernet broadcast address as the destination. Since
you're not seeing that, I assume the card is either completely faulty (no
link light etc?) or is so badly misconfigured (possibly the setup has been
corrupted by age, or suffers from flat battery if there is one) that it
needs reset to factory defaults before it will operate.
--
Pete Peter Turnbull
Network Manager
University of York
Received on Fri Nov 02 2001 - 16:07:56 GMT