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
******************************************
