Re: [Etherboot-users] REQUIRE_VCI_ETHERBOOT Question

[Jim M. <ja...@Mc...>]

lo...@ou... wrote:
> Hi Jim,
>
> I see what you are saying and this all looks like a very limiting 
> factor of DHCP.
>
> Let me ask you this, ok.
>
> When a boot client does a broadcast for a DHCP request, then there 
> could be more than 1 DHCP server responding and the client would 
> receive requests from all responding DHCP servers looking for the one 
> that accepted that particular client and gave it a lease, right?
>
> Would this also mean that, in general, for all of the DHCP servers, 
> then if only one of the had the client MAC address in their list then 
> that would be the request that would have the valid information (IP, 
> gateway, etc....) for that client?

Well, sort of.

Many people configure their dhcp servers to automatically hand out an IP 
address from a pool of addresses.

So, you could have a 2nd dhcp server that responds to the dhcp request 
BEFORE your ltsp server gets a chance to.

Then, the Etherboot or PXE bootrom would receive the offer, and possibly 
accept it.  I think recent versions of Etherboot will ignore any 
responses that don't have a 'filename' parameter, so as far as etherboot 
is concerned, you'd only accept a reply from a dhcp server properly 
configured for diskless booted.

BUT, after the kernel gets loaded in memory, and the 2nd DHCP request is 
sent out by the dhclient program inside the initrd, it doesn't make the 
distinction about the 'filename' parameter, and will accept an address 
from the first dhcp server that replies.  This could cause a problem, 
because the reply that it gets might not have a 'root-path' parameter, 
and without that, the workstation will just die with an error.

So, my advice is anytime you are thinking of putting a dhcp server on an 
existing network, you should make sure you know what other dhcp servers 
already exist, and if there are any, make sure they are configured to 
ignore requests from unknown clients, or they are configured to hand out 
the information that you need.

I realize it's not always easy to know that information, but if I was 
one of the guys responsible for one of the existing DHCP servers, i'd be 
very angry if somebody dropped another dhcp server on my network without 
informing me.

Many people just setup a separate lan segment for their LTSP thin 
clients that is completely separate from the existing network.  Also, a 
smart switch with VLAN capabilities can help to separate the network for 
you.

Jim McQuillan
ja...@Lt...



>
> I guess what I am getting at is that it is probably ok for there to be 
> multiple DHCP servers on the net and subnets as long a only one of 
> them had the client address as an acceptable MAC address.
>
> The problem with changing ports for the DHCP server and Etherboot is 
> that there might already be other DHCP servers on those ports without 
> us bing aware of it by some chance and then we would still have 
> multiple requests beign fielded by multiple DHCP servers and in which 
> the problem is really not solved.
>
> Thanks and have a good day,
>
> Lonnie T. Cumberland
> OutStep Technologies Incorporated
>
> Email: Lo...@ou...
>       Lon...@ya...
>
> Recommended sites:
>
>        http://www.peoplesquest.com
>
>
>
> Quoting Jim McQuillan <ja...@Mc...>:
>
>> Lonnie,
>>
>> While it's true that you can configure Etherboot to set the 
>> 'REQUIRE_VCI_ETHERBOOT' option, it won't do everything you think it 
>> will.
>>
>> The problem is, booting an LTSP workstation involves 2 DHCP requests. 
>>  The first one is from the bootrom (Etherboot OR PXE).  The 2nd DHCP 
>> request comes from dhclient inside the initrd that is downloaded 
>> along with the kernel.  That 2nd DHCP request won't do the 
>> 'REQUIRE_VCI_ETHERBOOT' option, it will simply make a DHCP request 
>> and accept the first response, no matter which dhcp server offers 
>> that response.  Then, it'll fail, if the wrong server offers it, 
>> because the wrong server probably isn't sending a 'root-path' value.
>>
>> You might instead try to set your LTSP dhcp to use ports 1067/1068, 
>> instead of the standard 67/68.  That way, the workstation will make a 
>> request, and the only DHCP server that will ever see the request is 
>> the LTSP dhcp server.
>>
>> To use ports 1067/1068, there are 3 places you'll have to make a change:
>>
>>  1)  The etherboot bootrom configuration
>>  2)  In the dhcpd.conf file, you'll have to set 'DPORT=1067' in an 
>> 'option-129' field.
>>  3)  You'll have to tell your dhcpd to ONLY listen on port 1067
>>
>> Take a look at:  
>> http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP#Multiple_DHCP_servers_on_the_sam 
>>
>> for more information.
>>
>> ALSO, keep in mind, that using Ports 1067/1068 is ONLY an option for 
>> Etherboot.  You can't do this with PXE.
>>
>> Hope that helps,
>>
>> Jim McQuillan
>> ja...@Lt...
>>
>>
>>
>> Lonnie Cumberland wrote:
>>> Greetings All,
>>>
>>> I am trying to figure out how to set up a floppy boot image so that 
>>> I can boot a LTSP client but take advantage of possibly 
>>> "*REQUIRE_VCI_ETHERBOOT*" and not loose the MAC address as well.
>>>
>>> The problem is that we have multiple DHCP servers and need to the 
>>> client to ignore all requests except from a specific one that is 
>>> located on another subnet.
>>>
>>> I have been told that there is supposed to be a way for me to add in 
>>> an additional string of information into the floppy boot rom and 
>>> also on my DHCP server so that when the client nic receives a 
>>> response from the correct server then it will check for this string 
>>> as well.
>>>
>>> If this is possible, then I would like to be able to specify my own 
>>> string and not some default one like "Etherboot" which what I have 
>>> read seems to be in the documentation.
>>>
>>> Can anyone please tell me more about this?
>>>
>>> Thanks and have a good day,
>>>
>>> Lonnie T. Cumberland
>>> OutStep Technologies Incorporated
>>>
>>> Email: Lo...@ou...
>>>       Lon...@ya...
>>> Recommended sites:
>>>     http://www.peoplesquest.com
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>>> language
>>> that extends applications into web and mobile media. Attend the live 
>>> webcast
>>> and join the prime developer group breaking into this new coding 
>>> territory!
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 
>>>
>>> _______________________________________________
>>> Etherboot-users mailing list
>>> Eth...@li...
>>> https://lists.sourceforge.net/lists/listinfo/etherboot-users
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Etherboot-users mailing list
>> Eth...@li...
>> https://lists.sourceforge.net/lists/listinfo/etherboot-users
>>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Etherboot-users mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-users