dhcprelay troubleshooting, where next?

Hi folks,
after 4 days on this stupidly simple problem, I finally admit defeat.

1. (ted)192.168.2.102 is my dhcpd server.
It quite happily supplies addresses to everything on that subnet. It
also has a 192.168.1.0 subnet clause in the dhcpd.conf .

2. (mrsdoyle)The gateway 192.168.2.254(eth0): 192.168.1.254 (eth1) has
dhcrelay running.

3. The box(jack) I'm trying to assign, successfully collects an address
when put on the 192.168.2.0 subnet, on the 192.168.1.0 subnet.


My troubleshooting results so far:
A. /var/log/dhcpcd.log on jack, says that it times out waiting for a
valid server response.

B. On mrsdoyle, tcpdump -i eth1 shows
0.0.0.0.bootpc > 255.255.255.255.bootps etc.
arp who-has 192.168.2.102 tell 192.168.1.254
This tells me that the broadcast has made it to the gateway.
(but why is arp asking across subnets?)

C. On mrsdoyle, output from dhcrelay -d 192.128.2.102 is
Listening on Socket/eth1
Sending on Socket/eth1
Listening on Socket/eth0
Sending on Socket/eth0
forwarded BOOTREQUEST for (jack mac address) to 192.168.2.102
This tells me that the gateways has received the broadcast from jack
and is sending it to ted(the dhcp server)
cat /proc/sys/net/ipv4/ip_forward shows returns "1"

D. tcpdump -i eth0 on mrsdoyle shows
arp who-has 192.168.2.102 tell 192.168.2.254
arp reply 192.168.2.102 is-at (ted's MAC address)
arp who-has 192.168.2.254 tell 192.168.2.102
arp reply 192.168.2.102 is-at (mrsdoyle eth0's MAC address)
plus lots of inaddr arp domain unreachable and PTR? stuff (I haven't
played with DNS yet - that's next)
NOTE: no mention of bootps or c.
This tells me that there is either ip_forwarding or a route table problem.

If I give jack a static address I can ping across the gateway so
ip_forwarding is working.
The route table does include
route add 255.255.255.255 dev eth1
(in the same way that I need to do that to get the dhcpd server working.)


I give up , I need help. Where next?
There is very little info on dhcrelay.
It is mostly mentioned as an afterthought in lots of howtos and
generally gives the impression that you just start it up and "Bob's your
aunties live-in lover", it all works.

I'm sure it is embarrassingly simple so I'm typing quietly, but I just
hope someone can help.
Thanks


--
Andy Richardson

We need Linux, like dolphins need a hole in the head.

Andy Richardson wrote:
> Hi folks,
> after 4 days on this stupidly simple problem, I finally admit defeat.
>
> 1. (ted)192.168.2.102 is my dhcpd server.
> It quite happily supplies addresses to everything on that subnet. It
> also has a 192.168.1.0 subnet clause in the dhcpd.conf .
>
> 2. (mrsdoyle)The gateway 192.168.2.254(eth0): 192.168.1.254 (eth1)
> has dhcrelay running.
>
> 3. The box(jack) I'm trying to assign, successfully collects an
> address when put on the 192.168.2.0 subnet, on the 192.168.1.0 subnet.

Should say
3. The box(jack) I'm trying to assign, successfully collects an
address when put on the 192.168.2.0 subnet, but not on the 192.168.1.0
subnet.



--
Andy Richardson

We need Linux, like dolphins need a hole in the head.

Andy Richardson wrote:
> Hi folks,
> after 4 days on this stupidly simple problem, I finally admit defeat.
>
> 1. (ted)192.168.2.102 is my dhcpd server.
> It quite happily supplies addresses to everything on that subnet. It
> also has a 192.168.1.0 subnet clause in the dhcpd.conf .
>
> 2. (mrsdoyle)The gateway 192.168.2.254(eth0): 192.168.1.254 (eth1) has
> dhcrelay running.
>
> 3. The box(jack) I'm trying to assign, successfully collects an address
> when put on the 192.168.2.0 subnet, on the 192.168.1.0 subnet.

Thanks for the correction
So, you've successfully associated jack's MAC with a 192.168.2.z IP
address. The server has noted this in its dhcpd.leases file. Ted will
not be a happy camper seeing this MAC trying to get an address on
another subnet (most likely).

> My troubleshooting results so far:
> A. /var/log/dhcpcd.log on jack, says that it times out waiting for a
> valid server response.

But what response(s), if any, does it get. Sniffed the wire on jack?

> B. On mrsdoyle, tcpdump -i eth1 shows
> 0.0.0.0.bootpc > 255.255.255.255.bootps etc.

etc.s may be useful -- or maybe not. DHCP can be tricky to diagnose
and I almost always inspect the entire packet sequence/exhange _with_
payload. Ethereal very hand if available.

Assume you have Windows boxes on the network.

> arp who-has 192.168.2.102 tell 192.168.1.254
> This tells me that the broadcast has made it to the gateway.
> (but why is arp asking across subnets?)

(several reasons these might show up, not least that 192.168.1.254 is
the IP of the relay agent.)

> C. On mrsdoyle, output from dhcrelay -d 192.128.2.102 is
> Listening on Socket/eth1
> Sending on Socket/eth1
> Listening on Socket/eth0
> Sending on Socket/eth0
> forwarded BOOTREQUEST for (jack mac address) to 192.168.2.102
> This tells me that the gateways has received the broadcast from jack
> and is sending it to ted(the dhcp server)
> cat /proc/sys/net/ipv4/ip_forward shows returns "1"

Hunky, dorey.

> D. tcpdump -i eth0 on mrsdoyle shows
> arp who-has 192.168.2.102 tell 192.168.2.254
> arp reply 192.168.2.102 is-at (ted's MAC address)
> arp who-has 192.168.2.254 tell 192.168.2.102
> arp reply 192.168.2.102 is-at (mrsdoyle eth0's MAC address)
> plus lots of inaddr arp domain unreachable and PTR? stuff (I haven't
> played with DNS yet - that's next)
> NOTE: no mention of bootps or c.
> This tells me that there is either ip_forwarding or a route table problem.

mrsdoyle is not relaying on eth0. Any traffic at all from the relay
agent to the server? Which options are you using with dhcrelay?
Especially which -m option. forward?

> If I give jack a static address I can ping across the gateway so
> ip_forwarding is working.
> The route table does include
> route add 255.255.255.255 dev eth1
> (in the same way that I need to do that to get the dhcpd server working.)

I don't think ip_forward or route table is your problem. What about a
firewall and UDP port 67?

> I give up , I need help. Where next?
> There is very little info on dhcrelay.
> It is mostly mentioned as an afterthought in lots of howtos and
> generally gives the impression that you just start it up and "Bob's your
> aunties live-in lover", it all works.
>
> I'm sure it is embarrassingly simple so I'm typing quietly, but I just
> hope someone can help.

Viewing the _entire_ packet exchange and payload can often reveal the
problem.

When moving a box from one subnet to another, it's best to erase the
client's leases file and the entry for that client from the server's
dhcpd.leases file. There are ways to allow/correct for this, but
usually only _after_ confirming correct simple behavior.

Then there is the problem of arp caches that have jack's MAC/old IP
entries that do/will conflict with jack's MAC/new IP assignment.
Windows makes cleaning this up a pain sometimes. Try removing the
faulty arp entries from ted and mrsdoyle at least.

You may have to actually look at the RFC to get good info from the
captured packet exchanges:

http://www.faqs.org/rfcs/rfc951.html
http://www.faqs.org/rfcs/rfc2131.html
http://www.faqs.org/rfcs/rfc2132.html

Since pinging and other goodies seem to work OK, I would look for a
firewall/port problem and sniff the wire at _every_ nic along the
pathway.

hth,
prg
email aobe disabled

Hi prg
> Thanks for the correction
Thanks for replying

> So, you've successfully associated jack's MAC with a 192.168.2.z IP
> address. The server has noted this in its dhcpd.leases file. Ted will
> not be a happy camper seeing this MAC trying to get an address on
> another subnet (most likely).
Ok I've removed all evidence of any previous history from client and server.

> But what response(s), if any, does it get. Sniffed the wire on jack?
Nothing except "Timed out waiting for a valid DHCP server response"

Although you have focussed me in on the word "valid".
Does tcpdump not show _everything_ appearing on the cable?
Is packet sniffing more than tcpdump -vvv ?

> etc.s may be useful -- or maybe not. DHCP can be tricky to diagnose
> and I almost always inspect the entire packet sequence/exhange _with_
> payload. Ethereal very hand if available.
I'll start having a play with ethereal (not used it before)

> Assume you have Windows boxes on the network.
No Windows anywhere in sight.

>> (but why is arp asking across subnets?)
>
> (several reasons these might show up, not least that 192.168.1.254 is
> the IP of the relay agent.)
Ah, I've always assumed that arp _only_ deals with same subnet and ip
routing get to that subnet. OK so I won't worry about that then.

> mrsdoyle is not relaying on eth0. Any traffic at all from the relay
> agent to the server?

The only traffic (from tcpdump) is a who-has/is-at back and forth
between dhcp server and gateway/relay. I don't know if this has been
triggered by any dhcp relaying or if it is general curiosity from the
two boxes on the network. (I've unplugged everything else just while I
get to the bottom of this problem)

> Which options are you using with dhcrelay?
> Especially which -m option. forward?
dhcrelay -d -m forward 192.168.2.102
(but I have tried every option just to see if there is any difference)

I'm a little shakey as to which port to run it on since using the -i
eth0 option says it is listening and sending on eth0. I need it to
listen and send on both, so I leave it blank.

Also route add -host 255.255.255.255 dev eth0 or eth1?
Since I had to use this all-ones host at the dhcp server to get it to
work, I've assumed that on the gateway, this should be on eth1 (the one
pointing at the client) though I have tried both.

> I don't think ip_forward or route table is your problem. What about a
> firewall and UDP port 67?
Now you've got me thinking. The thing I'm treating as a dumb hub on the
server side, is actually a Belkin ADSL firewall/modem/router with dhcp
and firwall turned off. I'm just of to get myself a crossover cable to
take that out of the equation too. So I will end up with 3 boxes,
gateway in the middle, all connected with null-modem/crossover cables.

> Then there is the problem of arp caches that have jack's MAC/old IP
> entries that do/will conflict with jack's MAC/new IP assignment.
> Windows makes cleaning this up a pain sometimes. Try removing the
> faulty arp entries from ted and mrsdoyle at least.
I don't seem to get much info from arp cache.
arp -a usually only shows a one or two line (correct) entry of the
other box(es) it has to deal with.

> http://www.faqs.org/rfcs/rfc951.html
> http://www.faqs.org/rfcs/rfc2131.html
> http://www.faqs.org/rfcs/rfc2132.html
0ne down , two to go :-)

> Since pinging and other goodies seem to work OK, I would look for a
> firewall/port problem and sniff the wire at _every_ nic along the
> pathway.
OK so I'm off to
1)get a crossover cable,
2)make my first venture into iptables/chains
3)find out about packet sniffing

I'm going through the LPIC 202 syllabus to see if it's worth my
attempting. I'm learning lots but it get rather disheartening when I
struggle over such a tiny part of the exam.

Thank you so much for your help.

--
Andy Richardson

We need Linux, like dolphins need a hole in the head.

Andy Richardson wrote:
> Hi prg
> > Thanks for the correction
> Thanks for replying
>
> > So, you've successfully associated jack's MAC with a 192.168.2.z IP
> > address. The server has noted this in its dhcpd.leases file. Ted will
> > not be a happy camper seeing this MAC trying to get an address on
> > another subnet (most likely).
> Ok I've removed all evidence of any previous history from client and server.
>
> > But what response(s), if any, does it get. Sniffed the wire on jack?
> Nothing except "Timed out waiting for a valid DHCP server response"
>
> Although you have focussed me in on the word "valid".
> Does tcpdump not show _everything_ appearing on the cable?
> Is packet sniffing more than tcpdump -vvv ?

tcpdump is capable of just about anything though the output is not
always (often?) easy to eyeball. It can be very terse while something
like ethereal decoding is more obvious/understandable. They both use
the same library, libpcap.

> > etc.s may be useful -- or maybe not. DHCP can be tricky to diagnose
> > and I almost always inspect the entire packet sequence/exhange _with_
> > payload. Ethereal very hand if available.
> I'll start having a play with ethereal (not used it before)
>
> > Assume you have Windows boxes on the network.
> No Windows anywhere in sight.
>
> >> (but why is arp asking across subnets?)
> >
> > (several reasons these might show up, not least that 192.168.1.254 is
> > the IP of the relay agent.)
> Ah, I've always assumed that arp _only_ deals with same subnet and ip
> routing get to that subnet. OK so I won't worry about that then.
>
> > mrsdoyle is not relaying on eth0. Any traffic at all from the relay
> > agent to the server?
>
> The only traffic (from tcpdump) is a who-has/is-at back and forth
> between dhcp server and gateway/relay. I don't know if this has been
> triggered by any dhcp relaying or if it is general curiosity from the
> two boxes on the network. (I've unplugged everything else just while I
> get to the bottom of this problem)
>
> > Which options are you using with dhcrelay?
> > Especially which -m option. forward?
> dhcrelay -d -m forward 192.168.2.102
> (but I have tried every option just to see if there is any difference)
>
> I'm a little shakey as to which port to run it on since using the -i
> eth0 option says it is listening and sending on eth0. I need it to
> listen and send on both, so I leave it blank.

The default port is UDP 67 so _any_ firewall(s) along the path must
have UDP 67 open.

> Also route add -host 255.255.255.255 dev eth0 or eth1?
> Since I had to use this all-ones host at the dhcp server to get it to
> work, I've assumed that on the gateway, this should be on eth1 (the one
> pointing at the client) though I have tried both.

Generally, this is only needed for Windows clients (which are
uncommonly picky about this part of the dhcp protocol), but it should
not be a problem (and may be necessary for your dhcpd) including it.

> > I don't think ip_forward or route table is your problem. What about a
> > firewall and UDP port 67?
> Now you've got me thinking. The thing I'm treating as a dumb hub on the
> server side, is actually a Belkin ADSL firewall/modem/router with dhcp
> and firwall turned off. I'm just of to get myself a crossover cable to
> take that out of the equation too. So I will end up with 3 boxes,
> gateway in the middle, all connected with null-modem/crossover cables.

If the Belkin is indeed a router (and not a switch) then it could be a
problem.

> > Then there is the problem of arp caches that have jack's MAC/old IP
> > entries that do/will conflict with jack's MAC/new IP assignment.
> > Windows makes cleaning this up a pain sometimes. Try removing the
> > faulty arp entries from ted and mrsdoyle at least.
> I don't seem to get much info from arp cache.
> arp -a usually only shows a one or two line (correct) entry of the
> other box(es) it has to deal with.

"Regular" hosts will only show neighbors on the same subnet and the
gateway. The gateways/routers, depending on setup/layout of the
network may show _all_ neighbors from all nics (and maybe more with
proxy arp enabled).

> > http://www.faqs.org/rfcs/rfc951.html
> > http://www.faqs.org/rfcs/rfc2131.html
> > http://www.faqs.org/rfcs/rfc2132.html
> 0ne down , two to go :-)
>
> > Since pinging and other goodies seem to work OK, I would look for a
> > firewall/port problem and sniff the wire at _every_ nic along the
> > pathway.
> OK so I'm off to
> 1)get a crossover cable,
> 2)make my first venture into iptables/chains
> 3)find out about packet sniffing
>
> I'm going through the LPIC 202 syllabus to see if it's worth my
> attempting. I'm learning lots but it get rather disheartening when I
> struggle over such a tiny part of the exam.
>
> Thank you so much for your help.

Be patient with the networking details, especially learning to use the
RFCs for all the common protocols. I can't keep all that stuff in my
head either.

The more common protocol aspects will sink in after you see them
enough, then you'll have to look up "head scratching" packets

DHCP, DNS, and some aspects of SMTP will be the usually maddening
packets, since they are all so "flexible" and are just about always
running on a network somewhere.

BTW, "normal" practice with a router with a hard disk, is just to run
the dhcpd on the router and let it serve all attached subnets.
dhcrelay is more designed for diskless routers. Of course, in larger
networks, just about all the rules-of-thumb are ignored in some way or
another

If you're studying networking at all, I highly recommend that you get a
copy of Stevens' "TCP/IP Illustrated, Vol I" (perhaps a decent used
copy from a local college/tech school?).
http://www.amazon.com/exec/obidos/tg...68103?v=glance

good luck,
prg
email above disabled

Hi again,
well, I've whittled the network down to 3 boxes with crossover cables
between them (made 'em myself, but they work nevertheless). So no
route/modem/external firewalls to worry about.

It would seem that your initial hunch that "etc.s may be useful" could
be borne out here.

1. Jack issues a DHCP_DISCOVER (then times out a minute later)

2. in the meantime, Mrsdoyle says she'll forward this bootp request to
192.168.2.102(ted)

3. Then there is a who-has on both mrsdoyle's NICS(eth0:192.168.2.254
and eth1:192.168.1.254) asking about 192.168.2.102(ted)

4. On ted's side(eth0) the arp-reply is-at appears

5. Then I see

192.168.2.254.1036 > 192.168.2.102.domain 16566+ PTR?
102.2.168.192.in-addr.arpa. (44) (DF)

192.168.2.102 > 192.168.2.254: icmp: 192.168.2.102 udp port domain
unreachable [tos 0xc0]

and so on with the 1036 port incrementing by one each time. (I remember
a few days back I saw 'blackjack' which according to /etc/services is
port 1025.)

1025 is the lowest port I have seen in this position.

Still on gateway/mrsdoyle:
netstat -l --numeric-ports show that port 67 is active

iptables -vL shows that the policy is ACCEPT on all three chains, though
I do notice that the FORWARD chain appears not to have dealt with any
packets.

One last question.
Should I worry if tcpdump says "promiscuous mode not supported on the
any device" ? - Does this mean that I'm only capturing packet involving
that particular NIC?

Thanks again

--
Andy Richardson

Hayfever: Nature's way of closing your eyes while plants have sex.

Andy Richardson wrote:
> Hi again,
> well, I've whittled the network down to 3 boxes with crossover cables
> between them (made 'em myself, but they work nevertheless). So no
> route/modem/external firewalls to worry about.
>
> It would seem that your initial hunch that "etc.s may be useful" could
> be borne out here.
>
> 1. Jack issues a DHCP_DISCOVER (then times out a minute later)
>
> 2. in the meantime, Mrsdoyle says she'll forward this bootp request to
> 192.168.2.102(ted)
>
> 3. Then there is a who-has on both mrsdoyle's NICS(eth0:192.168.2.254
> and eth1:192.168.1.254) asking about 192.168.2.102(ted)
>
> 4. On ted's side(eth0) the arp-reply is-at appears
>
> 5. Then I see
>
> 192.168.2.254.1036 > 192.168.2.102.domain 16566+ PTR?
> 102.2.168.192.in-addr.arpa. (44) (DF)
>
> 192.168.2.102 > 192.168.2.254: icmp: 192.168.2.102 udp port domain
> unreachable [tos 0xc0]

msrdoyle is attempting to reach the configured name server at
ted for reverse resolution of 192.168.2.102. ted responds by
telling that there's no name service available.

> and so on with the 1036 port incrementing by one each time. (I remember
> a few days back I saw 'blackjack' which according to /etc/services is
> port 1025.)
>
> 1025 is the lowest port I have seen in this position.

The lowermost of these wild ports is 1024. They are called
ephemeral ports - it's OK that the system uses the next
free number at each try.

You seem to have ted configured as the name server for the
the gateway/server (mrsdoyle). Check from /etc/resolv.conf.

You could solve the problem by setting the IP addresses
of the local network hosts to /etc/hosts of mrsdoyle.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

Andy Richardson wrote:
> Hi again,
> well, I've whittled the network down to 3 boxes with crossover cables
> between them (made 'em myself, but they work nevertheless). So no
> route/modem/external firewalls to worry about.
>
> It would seem that your initial hunch that "etc.s may be useful" could
> be borne out here.
>
> 1. Jack issues a DHCP_DISCOVER (then times out a minute later)

Means jack never receives a DHCP_OFFER

> 2. in the meantime, Mrsdoyle says she'll forward this bootp request to
> 192.168.2.102(ted)

OK, she's doing this initial part

> 3. Then there is a who-has on both mrsdoyle's NICS(eth0:192.168.2.254
> and eth1:192.168.1.254) asking about 192.168.2.102(ted)

She's looking for ted's MAC -- just basic arp stuff.

> 4. On ted's side(eth0) the arp-reply is-at appears
>
> 5. Then I see
>
> 192.168.2.254.1036 > 192.168.2.102.domain 16566+ PTR?
> 102.2.168.192.in-addr.arpa. (44) (DF)
>
> 192.168.2.102 > 192.168.2.254: icmp: 192.168.2.102 udp port domain
> unreachable [tos 0xc0]

Knowing where these are appearing would be nice mrsdoyle, I
presume.

Not sure if this is enough to make mrsdoyle "quit" in midstream or not.
No time to look up anything

> and so on with the 1036 port incrementing by one each time. (I remember
> a few days back I saw 'blackjack' which according to /etc/services is
> port 1025.)
>
> 1025 is the lowest port I have seen in this position.
>
> Still on gateway/mrsdoyle:
> netstat -l --numeric-ports show that port 67 is active

Which will carry just the DHCP packets, nothing else (hopefully).

> iptables -vL shows that the policy is ACCEPT on all three chains, though
> I do notice that the FORWARD chain appears not to have dealt with any
> packets.

When dealing with network troubles, it is best if at _all_ possible, to
shut off firewalls completely just to be sure they aren't interferring.
Also double check for _any_ kind of firewall (host or router) along
the path.

> One last question.
> Should I worry if tcpdump says "promiscuous mode not supported on the
> any device" ? - Does this mean that I'm only capturing packet involving
> that particular NIC?

Nothing you can do about it probably. It's usually a driver or chipset
limitation. Means you only see traffic directed to that nic, not any
of the other traffic passing by.

Tauno gave a heads up about DNS and there may be other things being
requested by jack that ted can't/won't provide.

It's been several years since I've set up a dhcrelay, so I'm pretty
useless (don't remember) any routine gotchas. Worse(?) I'm leaving
behind the computer for some time starting this evening and don't know
when I'll get back to one.

Maybe Tauno or one of the other regulars can help you out. Without
knowing the particulars of your network setup and not being on the
scene can make spotting the break difficult. It can be good(?)
incentive for learning how to track down a network problem -- ie.,
sniffing the wire and carefully watching the sequence of packets
exchanged and comparing this to the protocols.

Right now it seems like ted and mrsdoyle aren't talking to each other
properly. Set them up to communicate as "statically" as possible, eg.,
static host route entries and maybe even static arp entries if you know
how. Idea is to eliminate as many "dynamic" variables as possible and
zero in on the DHCP exchange.

Have jack request as little as possible, eg., just an IP/netmask to
start with. First thing is to get mrsdoyle to return _something_ to
jack and go from there.

sorry not more help,
prg
email above disabled

Tauno Voipio wrote:
> You seem to have ted configured as the name server for the
> the gateway/server (mrsdoyle). Check from /etc/resolv.conf.
>
> You could solve the problem by setting the IP addresses
> of the local network hosts to /etc/hosts of mrsdoyle.

Woahh!! thanks.
That's certainly reduced the gateway<->server traffic... down to zero.

So why, when 'dhcrelay -d -m forward 192.168.2.102' says
"forwarded BOOTREQUEST for 00:60:97:4c:19:4b to 192.168.2.102"
does it actually do nothing???


tcpdump on eth0 was 0bytes long.
I can ping ted from mrsdoyle.
00:60:97:4c:19:4b is of course jacks correct MAC address.


I gotta look on the bright side. I was getting upset that I have spent
nearly a week on a one liner in the LPIC 202 syllabus. Now I notice that
arp, tcpdump, netstat etc. are all in the troubleshooting section so
I've not been wasting my time entirely... and I've met RFC's too :-)




--
Andy Richardson

We need Linux, like dolphins need a hole in the head.

prg wrote:
> Have jack request as little as possible, eg., just an IP/netmask to
> start with. First thing is to get mrsdoyle to return _something_ to
> jack and go from there.

Hello again,
it would seem (with /etc/hosts populated) that mrsdoyle the
gateway/dhcrelay agent isn't passing anything on.

She promises that she will on stdout when kept in the foreground
"forwarded BOOTREQUEST for 00:60:97:4c:19:4b to 192.168.2.102"
Which is good,

but when I look at the traffic from mrsdoyle to server.. well, there is
none.

The setup is down to 3 boxes connected with crossover cables.
Would rmmod iptables remove _any_ kind of remaining firewall?
PortSentry isn't running and the rest is a very basic bare bones system
(Vectorlinux4.0) running on Pentium90-166 with 32-64M ram and <1Gb HD.

As you will guess, nothing mission-critical going on in this network ;-)

I needed a simple distro which matched the linux books without any
distro specific 'quirks'.

Enjoy your time away from the PC.
Thanks again

--
Andy Richardson

We need Linux, like dolphins need a hole in the head.