[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] x86 thin client apparently ignoring DHCPOFFER from LTSPsvr



Update:

We use Cisco routers as our DHCP servers for our WAN, so, as a test, I configured a Cisco 3620 router (a fairly common model) to be the DHCP server for this test network and stopped dhcpd on the K12LTSP server. Using the Cisco router's DHCP server got my clients to boot, except for the one with the Intel PRO/100+ card (all of my PRO/100+ cards rejected valid DHCP offers for some unknown reason when netbooting). Anyway, now all my 3Com 3c905 and 3c905b cards netboot fine. Here's the config I used on the router:

ip dhcp excluded-address 192.168.0.1
ip dhcp excluded-address 192.168.0.254

ip dhcp pool ltsp
 default-router 192.168.0.1
 network 192.168.0.0 255.255.255.0
 bootfile lts/vmlinuz-2.4.18-ltsp
 next-server 192.168.0.254
 dns-server 192.168.0.254
 domain-name ltsp
 option 17 ascii 192.168.0.254:/opt/ltsp/i386


Explanation of the above:


ip dhcp excluded-address x.x.x.x keeps this IP address in your pool (defined next) from getting assigned to a DHCP client; you can specify a range here, too

ip dhcp pool ltsp // creates and initializes a DHCP pool called "ltsp"
default-router 192.168.0.1 // specifies your default router/gateway
network 192.168.0.0 255.255.255.0 // defines the IP address range you want to serve up--this includes the whole 192.168.0.1-254 Class C range
bootfile lts/vmlinuz-2.4.18-ltsp // this is the K12LTSP kernel that we want the NIC to get from the TFTP server
next-server 192.168.0.254 // this is the IP adrs of the TFTP server where that kernel lives, in this case, our K12LTSP server--if this isn't specified, your thin client will try to download the kernel from 0.0.0.0! Not good....
dns-server 192.168.0.254 // self-explanatory
domain-name ltsp // remember, I'm using a stock K12LTSP installation, so I didn't tweak the domain name. This works as well as any.
option 17 ascii 192.168.0.254:/opt/ltsp/i386 // this is the "root-path" that we normally see in /etc/dhcpd.conf. After we Etherboot the kernel, we need to get the actual K12LTSP root to pivot-root to. This one must be specified as a raw option, since ciscos don't have a predefined "root-path" option like ISC dhcpd.


What this does is configure and initialize the DHCP server in the Cisco IOS. No, the IOS is not Free Software (I wish!), but it did what I needed. I'm still surprised that this worked and ISC dhcpd didn't...anyone have any ideas on why this is happening with dhcpd?

--TP


Terrell Prude', Jr. wrote:


Hello folks,

I have set up three thin client machines, one a Pentium/133, one a K6-2/400, and the third a K6-3+/450, and neither of them boot without I see the following in the K12LTSP server's /var/log/messages during a tail:

/ Jan 18 12:07:32 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:07:32 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:08:53 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:08:53 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:01 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:01 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:18 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:18 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:35 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:35 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:48 myltspserver dhcpd: DHCPDISCOVER from 00:04:76:c9:8e:f9 via eth0
// Jan 18 12:09:48 myltspserver dhcpd: DHCPOFFER on 192.168.0.2 to 00:04:76:c9:8e:f9 via eth0/


I have seen this with the following NICs:

3Com 3C905
3Com 3C905b
Intel EtherExpress PRO/100+

I have done this with the following versions of K12LTSP: 2.0.2, 2.1.2 (well, actually stock RHL 7.3 with the K12LTSP RPMs for 2.1.2, since I already had RHL 7.3), and the new 3.0.0. The K12LTSP server is a K6-III+/500 with 384MB RAM and 36GB of disk. Its NIC is a 3c905.

For the two 3Com NICs, I used the Rom-O-Matic boot floppy for 3c905 and 3c905b, as well as the various 3Com boot floppy images for 3c905 and 3c905b cards that come with the K12LTSP distros. The Intel EtherExpress PRO/100+ has a built-in boot ROM and therefore doesn't need a floppy-based boot image. The PRO/100+ will eventually time out; the boot floppies for the 3c905's just appear to keep trying forever. I've never seen DHCP clients ignore a DHCPOFFER before. It was really funky.

Since I have more than one of the above-named NIC models, I tried several of each. Same reaction.

*** BEGIN ANOMALY ***

However, in one instance, with one of the 3c905 cards (not the "b" model) plugged into the K6-2/400, the box would indeed netboot all the way to runlevel 3, and even 5 (another problem then surfaced at runlevels 4 and 5, which I'll post in a different thread). It was neat to actually watch the boot process and see what happens, and that told me that the TFTP server must be configured properly. So, of course I tried another 3c905 NIC in that same box (the K6-2/400), and we went back to ignoring the DHCPOFFER. So I put back in the NIC with which things actually did netboot, and no luck, we were back to ignoring the DHCPOFFER once again. Yep, a card that worked once would not work again in even the same machine, let alone in another machine.

*** END ANOMALY ***

I said, OK, maybe dhcpd itself is having challenges in some subtle way (BTW, I'm using the stock /etc/dhcpd.conf--no need for IP adrs changes on an isolated test bed). Fortunately, all of these thin clients actually do have hard disks in them with operating systems on them (I had unplugged the hard disks to force netbooting). So, I reconnected the hard disks, configured the OS's to use DHCP, and watched what happened. All three computers (one Windows XP, the other two Slackware Linux 8.1) got a valid DHCP address and were able to ssh into the K12LTSP server. During this whole deal, I made sure to double-check that the NICs were indeed fully inserted into the PCI slots. I also tried multiple PCI slots on each machine, remembering the bad old days when the slot you put a given PCI card into really did matter.

This is being done on an isolated test network with a 10BaseT hub, so there are no other DHCP servers available to the thin clients. I find it really odd that three models of NIC are having trouble netbooting like this. Can anyone help me out with this? I would like to try out K12LTSP at work, and we have a lot of older (Pentium and PII) boxes with built-in 3c905b and Intel Pro/100 cards.

Thanks in advance,

--TP



_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://listman.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]