using option 82 to assign a static ip-address -- solved

Mon Dec 17 14:48:39 UTC 2012

Found the problem.

We were using 'host' statements for all clients before and had 'deny 
unknown-clients' globally set.  However when I converted the host 
statement to class+pool the deny unknown-clients prevented the client 
from getting an ip as there was no matching host statement anymore for 
this client.

After removing 'deny unknown-clients' everything magically worked.

I threw out the binary-to-ascii in the mean time too. I was confused by 
the extra '1' that gets added at the front for some of the fields.

By the way on my cisco Remote-id looks like '00:06:84:78:ac:84:e5:80'

Nico

On 12/17/2012 05:07 AM, Sten Carlsen wrote:
> From original mail:
>
> binary-to-ascii(16, 8, ":", substring(option agent.remote-id, 2, 7)) = 
> "84:78:ac:84:e5:80"
>
> Reformat to:
>
> binary-to-ascii(
> 16,                                          ---------> result is in hex
>  8,                                           ---------> it works in 
> 8bit wide increments
>  ":",                                          ---------> separator is 
> a ":"
>  substring(
> option agent.remote-id,          ---------> assumed to be a MAC 
> address -> string of 6 bytes: 0x112233445566
>  2,
>  7
> )                                              ---------> 0x1122 
> ->33445566<- This is the result of the substring operation.
> )
>                                                ---------> result of 
> binary-to-ascii should then be: "33:44:55:66" as a text string, 11 
> chars long.
>
>  = "84:78:ac:84:e5:80"
>
> Something here is mysterious, not quite sure what. Can't see why this 
> has ever been a match?
>
>
> On 17/12/12 1:03, Glenn Satchell wrote:
>> Hi Nico
>>
>> Please see comments below.
>>
>> On Mon, December 17, 2012 12:17 am, Nico De Ranter wrote:
>>> Hi,
>>>
>>>
>>>
>>> I'm trying to use DHCP option 82 to assign a different address to a host
>>> depending on which network port it is connected to.
>>> I'vve created the following section in my config:
>>>
>>> ############
>>> stash-agent-options true;
>>> ...
>>> subnet 10.103.0.0 netmask 255.255.255.0
>>> {
>>>          option routers 10.103.0.1;
>>>          class "OK1Endo" {
>>>                  match if  binary-to-ascii(16, 8, ":", substring(option
>>> agent.remote-id, 2, 7)) = "84:78:ac:84:e5:80"
>> This string "8 4 : 7 8 : ... : 8 0" is 17 characters long. So a 7 char
>> substring will never be equal to it. I can't see how it ever matches.
> Precedence: first substring, then binary-to-ascii, I still don't see 
> the match.
>>>                          and     binary-to-ascii (16, 8, ":", hardware) =
>>> "1:0:14:2d:40:f:15"
>>>                          and     binary-to-ascii (16, 8, ":",
>>> substring(option agent.circuit-id, 5, 5)) = "e";
>> This may or may not match. If the agent.circuit-id is exactly 5 characters
>> long it will return that last char only and if that is an 'e' then it will
>> match.
>>
>> These can all be re-written without the binary-to-ascii and be much clearer:
>>
>> match if substring(option agent.remote-id, 2, 7)) = 84:78:ac:84:e5:80
>>       and hardware = 1:0:14:2d:40:f:15
>>       and substring(option agent.circuit-id, 5, 1)) = e;
>>
>> Finally, putting the class definition inside the subnet can cause some
>> unexpected inheritance. Probably ok if you only have a single subnet in
>> your definition, but better to put the class outside the subnet
>> definition.
>>
>>>          }
>>>          pool {
>>>                  filename "pxelinux.0";
>>>                  next-server 10.103.0.202;
>>>                  option mobile-ip-home-agent 10.103.0.202;
>>>                  option log-servers 10.103.0.202;
>>>                  option tz "Europe/Brussels";
>>>                  use-host-decl-names on;
>>>                  allow members of "OK1Endo";
>>>                  range 10.103.0.220 10.103.0.220;
>>>          }
>>>    }
>>> ###########
>>>
>>> I'm sure the class definition is correct and the pool matches as I also
>>> added a log statement which only seems to trigger if the client matches
>>> the
>>> pool (if I change the class definition or remove the 'allow members' I
>>> don't see the logs appearing in the log files anymore).
>>>
>>> However the dhcpd server doesn't seem to send any reply to the host: in
>>> tcpdump I see a bootp/dhcp request from the clients MAC but no replies
>>> from
>>> the server.  If I replace the 'pool' section with a simple 'host'
>>> definition the server responds immediately.
>>>
>>> Any ideas what I'm doing wrong?
>>>
>>> Note: I'm using a very old version of dhcpd (3.1.1) which unfortunately I
>>> cannot upgrade at the moment.
>

-- 
Nico De Ranter
Operations Engineer
T. +32 16 38 72 10
M. +32 497 915 378

eSATURNUS
Romeinse straat 12
3001 Leuven -- Belgium 	
T. +32 16 40 12 82
F. +32 16 40 84 77
www.esaturnus.com <http://www.esaturnus.com>

<http://www.esaturnus.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20121217/00c0233f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 210125 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20121217/00c0233f/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15157 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20121217/00c0233f/attachment-0003.jpe>