lease-times in omapi are cryptic

[Glenn Satchell]

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>