How does DHCPD determine what IP address to assign and...

Ryan McCain Ryan.McCain at dss.state.la.us
Thu Jan 3 18:29:22 UTC 2008


>>> On Thu, Jan 3, 2008 at  6:24 AM, in message
<200801031224.m03COxkP021770 at mail.uniq.com.au>, Glenn Satchell
<Glenn.Satchell at uniq.com.au> wrote: 

>>Date: Wed, 02 Jan 2008 14:01:03 -0600
>>From: "Ryan McCain" <Ryan.McCain at dss.state.la.us>
>>To: <dhcp-users at isc.org>
>>Subject: Re: RE: How does DHCPD determine what IP address to assign and...
>>
>>
>>class "DialUp" {
>>    match if (substring(suffix(dhcp-client-identifier,7),0,5)="Async")
>>
>>                   or
>>                 
>>(substring(suffix(dhcp-client-identifier,6),0,5)="Async") ; 
>>            log (info, " Matched Dialup Rule");
>>                        }
>>}
> 
> ok Ryan, let's break it down. I assume you have looked at the dhcp-eval
> man page to get the descriptions for substring() and suffix().
> 
> Let's look at the first evaluation and start with the assumption that
> option dhcp-client-identifier is the string
> ABCDFEGHIJKLMNOPQRSTUVWXYZ.
> 
> suffix(option dhcp-client-identifier, 7) is the last 7 chars from out
> string, in this case TUVWXYZ.
> 
> substring("TUVWXYZ", 0, 5) is the string starting at position 0 and is
> 5 chars long, in this case TUVWX.
> 
> Now we are determining membership of the class if this final substring
> is equal to "Async".
> 
> The second line uses a suffix of length 6. So it would evaluate the
> suffix bit to be the last 6 chars, UVWXYZ. Doing a substring of that
> gives UVWXY.
> 
> Now in your case to match the option dhcp-client-ientifier must be
> something like
> 
> XXXXXXAsyncXX or XXXXXXXXXXAsyncX
> 
> to log this, in the global section, ie outside the class and subnet put
> something like
> 
> log(concat("dhcp-client-identifier is ", option
> dhcp-client-identifier));
> 
> Looking at packet captures, global log entries, etc, does the string
> look like that pattern? Often using a tool like wireshark will give
> better results because there may be unprintable binary chars in the
> string, especially sometimes a trailing null byte which you can't see
> but gets counted in the suffix...
> 
> regards,
> -glenn

I haven't had a chance to look at the network today.  Hopefully tomorrow I'll have time to get wireshark up.  



More information about the dhcp-users mailing list