How can I configure a DHCP server to assign addresses based on the OS that is running Solved maybe!

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Jun 3 07:35:11 UTC 2010


Marc Chamberlin wrote:

>My main point in saying that perhaps a new design should be 
>considered, is derived from two things to consider.

I'm not so sure a new design would be the right way forward. Once you 
redefine the interface, then you introduce all the same problems 
you've had - but this time for everyone who's got a working setup 
they need to convert. A complex and rich feature set is never going 
to be easy and simple to drive :(

Ultimately, without just giving people a set of hooks to use an 
external binary to do some of the work (try debugging that !), 
whatever language used is going to impose constraints - it's all 
about balance and I don't think anyone has been completely unable to 
do anything ... yet.

And some new features have been added, or are planned, to deal with 
the commonest "difficult" setups - for example, there is a proposed 
addition awaiting a sponsor that would pretty well solve the common 
issue of wanting to assigned addresses via Option 82 (relay physical 
interface, eg port on a remote network switch).

>>I'm not with you here. What is hard about "hardware ethernet 
>>aa:bb:c:d:ee:ff ;" ? You don't need all those binary-to-ascii and 
>>substring constructs you are using (I think). While you may think 
>>it's complicated to have a hardware type element, it is required as 
>>different hardware types have different identification constructs - 
>>and there was no way of knowing what new types may come along in 
>>the future.
>It is not hard to use a complex object once you discover and 
>understand it. What makes it hard is that this particular hardware 
>object is a different model from what (I believe) most people will 
>think of as a hardware address. Most programs that use hardware 
>addresses are referring to what is called a MAC address which has (I 
>believe, could be wrong...) a common form of 6 hex digits separated 
>by colons. From the dhcp servers own display of what are hardware 
>addresses, in log files, in dhcp.leases and in the configure 
>language,  it is in fact inconsistent, sometimes using a 7th hex 
>digit and sometimes using the interface type name. This first form 
>of a hardware address is easily confused with MAC addresses, and it 
>fooled me! It would have been more convenient to have a simple MAC 
>address object to work with, that matches the common form of MAC 
>addresses.

Let me stop you right there ! What you say looks like a MAC address 
is in fact ... the MAC address **on an ethernet network**. Though to 
be pedantic, the "aa:bb:c:d:ee:ff" in "hardware ethernet 
aa:bb:c:d:ee:ff;" is actually just a string of hex digits to the DHCP 
programs - but that is all the MAC address is, a set of 6 bytes which 
you can express in any way you want (it's just convention to use hex).

The DHCP packages are NOT tied to only working with ethernet, they 
can work with other interface types which use different forms of 
media address, and they call it different things.

Incidentally, in most cases I believe, the two forms are 
interchangeable - ie you can write "hardware ethernet 
aa:bb:c:d:ee:ff" or "hardware 1:aa:bb:c:d:ee:ff". As it's one of 
those areas I don't delve into, I can't say for sure.

>  The "hardware" object requires one to discover the extension that 
>is employed, to define the type of interface as well. I used 
>examples from the documentation and I easily overlooked this detail 
>about the interface type, as it went against my assumptions based on 
>past experiences. So I reported it because it made it hard to 
>discover what had gone wrong when I  accidentally misused it.  I 
>won't argue this issue very strongly, but simply say that good 
>language designs take into account the sort of assumptions that 
>users are likely to make.

It's a long time since I looked at the man pages in any detail, so I 
can't comment if there is anything missing. As someone who's been 
caught out by this, but is still new enough to be able to tell - 
would you say there is anything missing from the man pages ?

As you can probably imagine, writing good documentation is very 
difficult, because those writing it usually understand what they are 
writing about and (as you point out) may assume knowledge that a 
newbie may not have. The same applies to road signage - the people 
putting up the signs generally know the area, and so are unaware when 
they leave an important gap :-/

>>That is an area that could do with improvement, and it comes up 
>>fairly frequently. Mixing allow and deny is generally advised 
>>against as it does NOT give the results most people expect - 
>>specifically the allow and deny statements are NOT processed 
>>linearly.
>
>Hence my suggestion that a redesign effort might be in order.... ;-)

Again, it's met most people's requirements for most of the time. 
Again, if you could suggest where the man pages could be improved 
then that would be appreciated. I'll have a look back and see if I 
can find one of David's statements on how allow and deny work when 
used together - it is actually logical.

>Finally, one question - Is the fact that log statements are not 
>produced when the dhcp server fails to assign an address to a 
>client, in fact a bug and should it be reported? That was a pretty 
>serious handicap for me....

You should report it. It's debatable whether it's a bug (as in 
deviation from intended operation), or a 'feature' that wasn't the 
intended way it would work.

>Anywise, as you hinted in an earlier response... who is going to 
>fund a redesign effort, or even another upgrade?  Sigh...

Indeed.
-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.



More information about the dhcp-users mailing list