lease-times in omapi are cryptic
Glenn Satchell
glenn.satchell at uniq.com.au
Tue Oct 12 00:27:57 UTC 2021
Hi Philipp
Nothing fishy going on, more a "feature" of the routine that prints out
byte strings in omshell.
For example the ip address is printed as 1f:19:7b:b7 - if you convert
each of these hexadecimal values to a decimal integer you get 31 25 123
183. The print routine tries to be clever and if a byte value is in the
range of an ascii character it prints the ascii character rather than
the hexadecimal value.
So taking the ends value "adTf", each of these characters has an ascii
value a=0x61, d=0x64, T=0x54, f=0x66. These represent the 4 bytes making
up an integer. If the string was printed as hexadecimal values it would
be 61:64:54:66. Converting 0x61645466 to a 32 bit integer using my
trusty hex calculator we get 1633965158 which is the number of seconds
since the epoch. Finally we convert this to a date in the UTC time zone
$ date -d @1633965158 -u
Mon 11 Oct 2021 15:12:38 UTC
which matches the value in the lease file.
Why does it work this way? Well, my guess is the function that prints
out the values of the various lease parameters is not that smart and
doesn't always know that a particular value represents a string of text,
binary data, or a time, so it uses a fairly generic routine that (sort
of) works some of the time. You can see another variation of this in the
leases file where the uid is printed as a series of octal digits with
the \ooo syntax for each byte.
regards,
Glenn
On 2021-10-12 01:54, Philippe Maechler wrote:
> Hello bind-users
>
> Since a while I'm having troubles getting the right lease-time by omapi
> for some? maybe all leases...
>
> pmaechler at stageing:/ % /usr/local/bin/omshell
>
>> server 10.20.0.251
>
>> port XXXX
>
>> key omapi_key XXXXXXXXXXXXXXXXXXXXXX
>
>> connect
>
> obj: <null>
>
>> new lease
>
> obj: lease
>
>> set ip-address = 31.25.123.183
>
> obj: lease
>
> ip-address = 1f:19:7b:b7
>
>> open
>
> obj: lease
>
> ip-address = 1f:19:7b:b7
>
> state = 00:00:00:02
>
> dhcp-client-identifier = 01:e0:91:f5:dc:a1:e1
>
> subnet = 00:00:00:2e
>
> pool = 00:00:00:2f
>
> billing-class = 00:00:00:30
>
> hardware-address = e0:91:f5:dc:a1:e1
>
> hardware-type = 00:00:00:01
>
> ends = "adTf"
>
> starts = "adFV"
>
> tstp = 00:00:00:00
>
> tsfp = 00:00:00:00
>
> atsfp = 00:00:00:00
>
> cltt = "adFV"
>
> flags = 00
>
> circuit = "some stupid string from our access devices"
>
> clhw = "e0:91:f5:dc:a1:e1"
>
> clip = "31.25.123.183"
>
> vendor-class-identifier = "udhcp 0.9.8"
>
>>
>
> What kinda bothers me is the lease-times ends, starts and cltt
>
> Checking it directly in the leasefile results in
>
> lease 31.25.123.183 {
>
> starts 1 2021/10/11 14:12:38;
>
> ends 1 2021/10/11 15:12:38;
>
> cltt 1 2021/10/11 14:12:38;
>
> binding state active;
>
> next binding state free;
>
> rewind binding state free;
>
> billing subclass "XXXXX_XXXXXX_XXXXXX_CPE_DHCP" "another stupid
> string";
>
> hardware ethernet e0:91:f5:dc:a1:e1;
>
> uid "\001\340\221\365\334\241\341";
>
> set remote = "";
>
> set circuit = "you can guess, again that thing";
>
> set clhw = "e0:91:f5:dc:a1:e1";
>
> set clip = "31.25.123.183";
>
> set vendor-class-identifier = "udhcp 0.9.8";
>
> option agent.circuit-id "again that stupid string";
>
> }
>
> we have 4 active servers all with their own pools, no failover and no
> overlapping pools.
>
> The dhcpd servers in use are running either ISC DHCP Server 4.4.1 or
> 4.4.2
>
> The client has 4.4.2-P1 installed, only for the omapi binaries
>
> Without further debugging into the version mismatch, it feels like only
> "some" lease-times are strange, but not all.
>
> Could this be due to the different versions or is something else
> "fishy"?
>
> Best regards
>
> Philipp
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20211012/3259407e/attachment-0001.htm>
More information about the dhcp-users
mailing list