Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: lease-times in omapi are cryptic (Philippe Maechler)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Oct 2021 10:17:43 +0200
From: Philippe Maechler <plcmaech...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: lease-times in omapi are cryptic
Message-ID:
<caphukgbxh6fgmkgvxmo9yap6bwbobeejleg46ydxur3v3kc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Glenn
Haha :) It never occurred to me that this could be something "that simple"
:)
Well in this case I have to do a litte bit more string processing with tr,
od, cut and all that ugly built in shell commands
Thank you very much
/BR
Philippe
On Tue, 12 Oct 2021 at 02:28, Glenn Satchell <glenn.satch...@uniq.com.au>
wrote:
> 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@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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> 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@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/73279ba6/attachment-0001.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 156, Issue 4
******************************************
