On Nov 5, 7:40, Arno Kletzander wrote:
> We're positive that the IP address is still the one it was set to all the
> time (111.1.0.1) because we finally got the Ethernet Adapter Status Page
> printed out.
OK, so we assume the printer knows its own address.
> I'd already found and read this page. Amazingly, they mention only two of
> the three LEDs my Ethernet Adapter has (IP, DATA and LINK). During the
warmup
> phase, IP (green) and DATA (amber) are illuminated. After that, the IP
LED
> goes on with a blink (rather 2 than 5 Hz, I'd say...), while the DATA LED
> flickers whenever something is transmitted on the Ethernet. The LINK LED
> stays off all the time. All of this seems to belong to the "NORMAL"
column.
If the LINK LED stays off, I'd be inclned to believe the interface isn't
working; on all the devices I've seen it, the LINK LED is on if the network
is live. Seems odd if the DATA LED blinks when there's traffic, though. I
wonder what that LINK LED really is for?
> 3. Pete Turnbull wrote:
> >> 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...
>
> But isn't it outside the address section which is allowed for equipment
> which might possibly be connected to Internet? - But the PC we want to
connect
> has got a modem!!! (OK, skip that until they work with their current
addresses)
Er, no, 111.0.0.0 is a real Internet address. Perhaps you're thinking of
the "private" Class A network address, 10.0.0.0? The private addresses are
NOT allowed to be connected to the Internet.
> >For Arno, this means:
> >create /etc/ethers if it doesn't exist
> >append a line with printer name and MAC (Ethernet) address
> >/etc/hosts must already exist for the Sun to work, so append a line for
the
> printer
> >start up rarpd if it's not already running
> >(the order in which you do these shouldn't matter)
> >If we call the printer "calcomp", the line in /etc/ethers is:
> >
> >00:C0:E2:00:0C:8E calcomp
> > hombre_tcsh (2) arp -s calcomp 00:0c:e2:00:0c:8e
> > arp: calcomp: unknown host
Well, to use rarpd the name in /etc/ethers has to match the line in /etc/
hosts. Also the name in the "arp -s" must match the name in /etc/hosts.
Whn I wrote the descriptin, I didn't know the printer name so I just
picked one.
> /etc/ethers does not exist, but...I must stress once again that the
system
> worked once and I don't suppose it existed back then (because nobody who
had
> access to the system since then would have deleted anything).
Then they didn't use RARP, or if they did, not from that Sun.
> >Ethan Dicks wrote:
> >> I think it's useful when you have an ancient network where the
broadcast
> address uses 0-bits, rather >>than 1-bits - i.e., ip 192.168.1.1 with a
> netmask of 192.168.1.0 and a broadcast address of >>192.168.1.0 *not*
> 192.168.1.255. It's archaic, but allowed.
> >
> >So it is -- I forgot about that! The rest of what I wrote may well be
> drivel :-)
>
> That might be contributing to our problem.
What, my drivel? Yes, quite likely :-)
> At boot, the complete network section reads:
>
> network interfache configuration:
> le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
> inet 111.0.0.14 netmask ff000000 broadcast 111.0.0.0
> ether 8:0:20:9:bc:d7 ^^^^^^^^^
Using the old-style "wrong" broadcast address might affect ARP (which as I
explained is used to get a MAC address of a destination before sending IP
packets), but otherwise won't break anything. Besides, you said it worked
before.
> ;logging in as SU:
> hombre# arp -s pa3 00:0c:e2:00:0c:8e
>
> hombre#
>
> ;Seems to have succeeded, checking:
>
> hombre# arp -a
> pa3 (111.1.0.1) at 0:c0:e2:0:c:8e permanent
>
> hombre# telnet pa3 2002
> Trying 111.1.0.1 ...
> telnet: connect: Connection timed out
>
> ;Same as it was before...pinging also still times out (no answer from
pa3).
Assuming 0:c0:e2:0:c:8e is the printer's MAC address, and it does know its
address is 111.1.0.1, that should work -- unless the printer interface is
broken or it doesn't respond to port 2002. You could try ports 9099, 9100
(used by HP JetDirect printers), 515 (lpd port), 161 (SNMP), 7 (echo).
Some of those normally use UDP rather than TCP, so you might need to get
something like netcat instead of telnet, though.
> Oh, and "permanent": After a reboot, the old (incomplete) is there again
> instead of the MAC address. Very permanent indeed...
It means it doesn't age out of the arp table the way normal entries do.
Normal entries age out in case IP addresses change, or in case routers are
doing proxy ARP for hosts on a different subnet (in which case if the route
changes, so does the ARP entry). All entries still get lost on reboot;
they're stored in kernel memory but nowhere else.
--
Pete Peter Turnbull
Network Manager
University of York
Received on Mon Nov 05 2001 - 02:33:30 GMT