(2014-01-09 16:26)oblivionv Wrote:  Is there a way to generate random numbers on the ipxe shell, like how we would using a bash/korn shell? Does it require re-compiling the source?
Something like the following is what am looking for:

echo "192.168.0.$((RANDOM%253+001))"

(2014-01-10 23:34)mcb30 Wrote:  

(2014-01-09 16:26)oblivionv Wrote:  Is there a way to generate random numbers on the ipxe shell, like how we would using a bash/korn shell? Does it require re-compiling the source?
Something like the following is what am looking for:

echo "192.168.0.$((RANDOM%253+001))"

No, there's no support for doing that. Also, I would very strongly suggest that you use DHCP instead of randomly assigning IP addresses!

Michael

(2014-01-11 05:03)oblivionv Wrote:  We have a situation where we have multiple DHCP's running at the same time every now and then. Hence, ipxe sometimes listens to the wrong DHCP server and hence fails to boot from the right source. Support of this in the future will be good.

(2014-01-13 16:52)mcb30 Wrote:  

(2014-01-11 05:03)oblivionv Wrote:  We have a situation where we have multiple DHCP's running at the same time every now and then. Hence, ipxe sometimes listens to the wrong DHCP server and hence fails to boot from the right source. Support of this in the future will be good.

In that case, your network is fundamentally broken. There is no such thing as the "wrong" DHCP server: if you have multiple DHCP servers on a network segment then they must all be offering the same configuration (unless they are constrained to respond only to specific known clients).

Fix your network, and the problem will go away.

Michael

(2014-01-13 18:58)oblivionv Wrote:  Well, thanks for your advice. But, there is no need to fix the network. There are reasons why we have multiple DHCP servers running. Changing the entire network infrastructure for a service isnt a clever option.

Quote:Adding the option of generating random numbers would solve the issue.

(2014-01-15 17:53)mcb30 Wrote:  

(2014-01-13 18:58)oblivionv Wrote:  Well, thanks for your advice. But, there is no need to fix the network. There are reasons why we have multiple DHCP servers running. Changing the entire network infrastructure for a service isnt a clever option.

Having multiple DHCP servers isn't a problem. Having multiple DHCP servers offering conflicting configurations to the same clients is a problem.

Quote:Adding the option of generating random numbers would solve the issue.

No, it wouldn't. What if two clients randomly selected the same IP address?

Michael

(2014-01-16 07:40)oblivionv Wrote:  It is very unlikely that 2 clients assume the same address with randomization if we were to use a class B address for example.

Quote:I agree that conflicting configurations from the DHCP server is not a sane option. But our environment is being used for testing with people setting up DHCP servers on cisco routers etc for academic purpose (by design). We faced a similar kind of issue with winpe wpeinit. But i was able to counter this with a batch script.

(2014-01-16 14:28)mcb30 Wrote:  

(2014-01-16 07:40)oblivionv Wrote:  It is very unlikely that 2 clients assume the same address with randomization if we were to use a class B address for example.

Not as unlikely as you may think: http://en.wikipedia.org/wiki/Birthday_problem.

Quote:I agree that conflicting configurations from the DHCP server is not a sane option. But our environment is being used for testing with people setting up DHCP servers on cisco routers etc for academic purpose (by design). We faced a similar kind of issue with winpe wpeinit. But i was able to counter this with a batch script. And thank you for

If you really need to hack around this problem rather than solve it, then you could try any of the following:

- use the "dhcp" command only to obtain an IP address, ignore any boot configuration, and "chain" from a hardcoded URI

- retry "dhcp" in a scripted loop until you get a configuration you are prepared to accept (e.g. using "isset" to check that you have a boot filename, or "iseq" to check that your default gateway is set to a specific IP address, etc.)

- use the undocumented (and not guaranteed to remain stable) "ipxe.priority" DHCP option to cause iPXE to prefer a specific DHCP server.

Michael

(2014-01-16 18:04)oblivionv Wrote:  It is very unlikely that 2 hosts (we have close to 60 machines in the VLAN)
were to assume the same IP from among the 65024(minus a few) possible IP's for the duration of ipxe chain-loading the file (hardly 1 to 2 minutes). And if it were to happen, then well, so be it. Point #2,3 sounds good for me. A DHCP retry script might do the job. I will try to get it to work and post the script here for reference. I'll also try to discover more about ipxe.priority.
Thanks a lot.

oblivionv

(2014-01-16 14:28)mcb30 Wrote:  

(2014-01-16 07:40)oblivionv Wrote:  It is very unlikely that 2 clients assume the same address with randomization if we were to use a class B address for example.

Not as unlikely as you may think: http://en.wikipedia.org/wiki/Birthday_problem.

Quote:I agree that conflicting configurations from the DHCP server is not a sane option. But our environment is being used for testing with people setting up DHCP servers on cisco routers etc for academic purpose (by design). We faced a similar kind of issue with winpe wpeinit. But i was able to counter this with a batch script. And thank you for

If you really need to hack around this problem rather than solve it, then you could try any of the following:

- use the "dhcp" command only to obtain an IP address, ignore any boot configuration, and "chain" from a hardcoded URI

- retry "dhcp" in a scripted loop until you get a configuration you are prepared to accept (e.g. using "isset" to check that you have a boot filename, or "iseq" to check that your default gateway is set to a specific IP address, etc.)

- use the undocumented (and not guaranteed to remain stable) "ipxe.priority" DHCP option to cause iPXE to prefer a specific DHCP server.

Michael