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. omshell lease ends field invalid characters (Rick Dicaire) 2. Re: omshell lease ends field invalid characters (Rick Dicaire) 3. OMAPI key generation without BIND (Michael De Roover) 4. reload revisited (rlhamil) ---------------------------------------------------------------------- Message: 1 Date: Tue, 29 Sep 2020 08:09:32 -0400 From: Rick Dicaire <kri...@gmail.com> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: omshell lease ends field invalid characters Message-ID: <CA+Cc--csmZM8tH64pp27hXQp1_pdG2wA561LZ=g_cxvv2gh...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi folks, I wrote a script that invokes omshell and noticed a couple leases having non hex values in the 'ends' field. Checking those leases in /var/state/dhcp/dhcpd.leases shows valid dates. Running dhcpd 4.4.2 with a customized ddns configuration. >From dhcpd.leases: lease 192.168.17.158 { starts 2 2020/09/29 06:17:17; ends 2 2020/09/29 18:17:17; cltt 2 2020/09/29 06:43:07; binding state active; next binding state free; rewind binding state free; hardware ethernet f4:f5:d8:42:52:10; set ddns-rev-name = "158.17.168.192.in-addr.arpa."; set ddns-txt = "004a9b9d459dc48a4aae47026174068ad9"; set ddns-fwd-name = "Chromecast.dhcp.labdev."; set clientddns = "Chromecast"; set clienthost = "Chromecast"; set clientmac = "f4:f5:d8:42:52:10"; set clientip = "192.168.17.158"; set clientdomain = "dhcp.labdev."; set vendor-class-identifier = "dhcpcd-6.8.2:Linux-3.8.13+:armv7l:Marvell"; client-hostname "Chromecast"; on expiry { execute ("/usr/local/sbin/hook_dhcpd.sh", "expiry", clientip, concat (concat (clientddns, "."), clientdomain), clienthost, clientmac); } on release { execute ("/usr/local/sbin/hook_dhcpd.sh", "release", clientip, concat (concat (clientddns, "."), clientdomain), clienthost, clientmac); } } >From omshell output: echo "server dns1 key daw3-ddns keyval connect new lease set ip-address = 192.168.17.158 open"|omshell > > > obj: <null> > obj: lease > obj: lease ip-address = c0:a8:11:9e > obj: lease ip-address = c0:a8:11:9e state = 00:00:00:02 client-hostname = "Chromecast" subnet = 00:00:00:03 pool = 00:00:00:04 hardware-address = f4:f5:d8:42:52:10 hardware-type = 00:00:00:01 ends = "_sz-" starts = 5f:72:d1:6d tstp = 00:00:00:00 tsfp = 00:00:00:00 atsfp = 00:00:00:00 cltt = 5f:72:d7:7b flags = 00 ddns-rev-name = "158.17.168.192.in-addr.arpa." ddns-txt = "004a9b9d459dc48a4aae47026174068ad9" ddns-fwd-name = "Chromecast.dhcp.labdev." clientddns = "Chromecast" clienthost = "Chromecast" clientmac = "f4:f5:d8:42:52:10" clientip = "192.168.17.158" clientdomain = "dhcp.labdev." vendor-class-identifier = "dhcpcd-6.8.2:Linux-3.8.13+:armv7l:Marvell" As shown above, 'ends' field does not have a hex value. Any thoughts as to what's causing this? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20200929/fdb3684b/attachment-0001.htm> ------------------------------ Message: 2 Date: Tue, 29 Sep 2020 12:10:19 -0400 From: Rick Dicaire <kri...@gmail.com> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: omshell lease ends field invalid characters Message-ID: <CA+Cc--cAs3E0u0D=Tk=jkuywynqz6yqo-evvpwor22vbxnr...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Wow great catch...the date value of your hex conversion corresponds with what I see in dhcpd.leases. I can try and script for this, but should a bug be filed, or could this be a terminal issue (I get same result from console terminal and xterm/ssh session)? On Tue, Sep 29, 2020 at 12:09 PM Rick Dicaire <kri...@gmail.com> wrote: > Wow great catch...the date value of your hex conversion corresponds with > what I see in dhcpd.leases. > I can try and script for this, but should a bug be filed, or could this be > a terminal issue (I get same result from console terminal and xterm/ssh > session)? > > On Tue, Sep 29, 2020 at 8:32 AM Bruce Hudson <bruce.hud...@dal.ca> wrote: > >> > ends = "_sz-" >> > starts = 5f:72:d1:6d >> >> > As shown above, 'ends' field does not have a hex value. >> > Any thoughts as to what's causing this? >> >> I suspect this is just an anomaly cause by omshell's more >> generic output algorithm. Because all four bytes of the ends >> value correspond to printable characters, it displays it as >> a string instead of the raw octects. A (failed in this case) >> effort to be more user friendly. >> >> Looking at the ord's of the four characters in hex: >> >> "_sz-" ==> 5f:73:7a:2d >> -- >> Bruce A. Hudson | bruce.hud...@dal.ca >> ITS, Networks and Systems | >> Dalhousie University | >> Halifax, Nova Scotia, Canada | (902) 494-3405 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20200929/be56b451/attachment-0001.htm> ------------------------------ Message: 3 Date: Wed, 30 Sep 2020 10:48:50 +0200 From: Michael De Roover <i...@nixmagic.com> To: dhcp-users@lists.isc.org Subject: OMAPI key generation without BIND Message-ID: <90edf56eb2f757014b0e639c487d31fc6d092b47.ca...@nixmagic.com> Content-Type: text/plain; charset="UTF-8" Hello, Earlier I've deployed 2 DHCP servers running ISC DHCP. These were configured to communicate with each other via OMAPI. Online I found https://kb.isc.org/docs/aa-00502 with which I configured the OMAPI control channel. I also found https://kb.isc.org/docs/en/isc-dhcp-44-manual-pages-omapi, however this appears to be tailored at developers who wish to integrate their applications with OMAPI. The former article worked well to configure it, but it suggests that we use BIND to generate the OMAPI key. I use BIND on my name servers, and was able to generate a key on one of those name servers. This does mean however that not only the DHCP servers, but also the name servers (and my laptop through the clipboard) know this OMAPI key. I'd rather keep strict boundaries between these environments and have the DHCP servers capable of generating this key on their own, preferably without having to install BIND there (as that runs somewhere else). The hashing algorithm used to generate these OMAPI keys appears to be HMAC-MD5. I could not find any standard system utilities that can generate this kind of key. Are there any such tools available for conventional Linux systems? Are there any other hashing algorithms that are supported for this OMAPI key? Alternatively, would it be possible to include the relevant code from dnssec-keygen in ISC DHCP? Perhaps this part would be better suited for kea-users, but how well is DHCP failover supported there? Is it easier to use standard system tools to generate them for this DHCP server? If so that might be a reason to upgrade. Thank you! -- Michael De Roover <i...@nixmagic.com> ------------------------------ Message: 4 Date: Wed, 30 Sep 2020 05:48:13 -0500 (CDT) From: rlhamil <rlha...@smart.net> To: dhcp-users@lists.isc.org Subject: reload revisited Message-ID: <1601462893598-0.p...@n4.nabble.com> Content-Type: text/plain; charset=us-ascii I see in the dhcpd man page: "This is not technically impossible, but it would require a great deal of work, our resources are extremely limited, and they can be better spent elsewhere. So please don't complain about this on the mailing list unless you're prepared to fund a project to implement this feature, or prepared to do it yourself." Granted that cleaning up everything and reloading might be substantially tedious to add (esp. without memory leaks, etc), there's something that's probably not: delete the PID file (if present) and re-execute yourself with the same argv. In principle that has the problem that there's not a really good standard and portable way for a running program to discover the full path of its executable. But wondering about that, I found a library (really just a .h and single .c) that purports to do that for quite a range of OS's, including but not limited to Linux, some BSDs, Solaris, macOS, etc. And with a dual license (MIT and a vulgar-named permissive license). https://github.com/gpakosz/whereami Seems to me that that approach would be rather easy to add, give or take any additional build requirements and testing, of course. Maybe it's a smidge slower than the hard way to reload, but the result would be very similar to a manual restart (fresh address space), with the further advantage that the PID would actually be unchanged; process starters/restarters like Solaris svc.startd or macOS launchd wouldn't even notice such a restart, since the original PID never went away. Aside from the build requirements and testing, the other thing I don't know off the top of my head is whether the range of platforms supported by whereami includes all the platforms currently supported by dhcpd. -- Sent from: http://isc-dhcp-users.2343191.n4.nabble.com/ ------------------------------ 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 143, Issue 7 ******************************************