Re: [K12OSN] Lost MACs in routing ....

["Christopher K. Johnson" <ckjohnson gwi net>]

norbert wrote:

> The IP setup is as follows;
>
> Cable Modem -> (DHCP)Router (192.168.2.1)-> (a) (Static eth1 
> 192.168.2.105)K12ltsp server & Gateway(static eth0 192.168.0.254) 
> ->(DHCP) hub ->(192.168.0.100 - 253) thin clients & MACs (teaching)
>                                  -> (b) (DHCP 192.168.2.100 - 200)hub 
> -> Office MACs
>
> The thin clients & the server & the Office MACs all work well but the 
> Teaching MACs cannot get "out" ??? They do get an IP address & can 
> ping the server & the workstations but not the router!


What subnet mask is the dhcp server on LTSP box giving out?  If the MACs 
were getting 192.168.0.x/255.255.0.0 then they would try to reach the 
router on the local segment instead of routing through the LTSP box.  
Depending on how you tested ping for thin clients, it may actually have 
been a ping from the server.  If you used a text mode console on the 
thin client and it worked, then the subnet mask is not the issue.

What default gateway is the dhcp server on LTSP box giving out?  If the 
MACs were getting anything other than 192.168.0.254 or were configured 
to not get gateway via dhcp then they would not know how to reach 
addresses not on the local subnet.  If pinging was tested using thin 
clients through the desktop login then an incorrect gateway (or no 
default gateway) could be the problem.  If tested using a text mode 
console on the thin client then the gateway offered must be correct, but 
perhaps the MACs are not getting that setting from dhcp?

Is ip forwarding turned on and a nat rule added by starting the nat 
"service" on the LTSP server?  Again if client pinging was tested from 
desktop login then no forwarding or nat hiding was necessary, and one of 
these could be the problem.  If tested from a text mode console then ip 
forwarding and nat cannot be the problem.

I would start by verifying that ip forwarding and a nat rule are set at 
the LTSP server.  If those are correct then look at the ip settings of 
one of the teaching MACs and the /etc/dhcpd.conf file to figure out what 
is wrong.

--
-----------------------------------------------------------
  "Spend less!  Do more!  Go Open Source..." -- Dirigo.net
  Chris Johnson, RHCE #807000448202021