dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-01-28T11:59:15Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/219dhcp-lease-list incorrect instruction for downloading the OUI.TXT file from IEEE2022-01-28T11:59:15ZKeith Siemandhcp-lease-list incorrect instruction for downloading the OUI.TXT file from IEEE---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org. If you really need to report it here, please set the confidential
field to true.
**Describe the bug**
Cosmetic bug. When running the dhcp-lease-list command, the wrong URL is referenced for downloading the OUI file. It is currently set to read http://standards.ieee.org/regauth/oui/oui.txt when it should be http://standards-oui.ieee.org/oui/oui.txt.
**To Reproduce**
Steps to reproduce the behavior:
1. Run the command dhcp-lease-list on a new install of DHCPD with no OUI.TXT file loaded/available.
**Expected behavior**
A clear and concise description of what you expected to happen:
The instruction instead reads:
To get manufacturer names please download http://standards-oui.ieee.org/oui/oui.txt to /usr/local/etc/oui.txt
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Raspbian 11 (bullseye)
- Which features were compiled in: Installed from apt
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
|- No, on 4.4.1 and latest version is 4.4.2-PL1, however this is not obtainable via apt on Raspbian just yet.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
|- Unknown, but not sure if relevant.
- Are you sure what you would like to do is not possible using some other mechanisms?
|- Irrelevant.
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
|- No.
**Is your feature request related to a problem? Please describe.**
N/A
**Describe the solution you'd like**
The correct URL displays
**Describe alternatives you've considered**
The user can Google it
**Additional context**
N/A
**Funding its development**
N/A
**Participating in development**
N/A
**Contacting you**
E-mail attached to this account is fine4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/280format string report2023-04-20T08:11:52ZPeter Daviesformat string reportformat string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse...format string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse.c#L5611
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/keama/keama.c#L209
To reproduce these bugs on Ubuntu 22.04, you may follow these steps:
```
raptor@fnord:~$ cp /sbin/dhclient . # copy to local directory to bypass apparmor policy
raptor@fnord:~$ echo "include foo" > %n%n%n%n
raptor@fnord:~$ echo "include foo" > %x%x%x%x
raptor@fnord:~$ ./dhclient -cf %n%n%n%n # write to memory, caught by exploit mitigations
*** %n in writable segment detected ***
raptor@fnord:~$ ./dhclient -cf %x%x%x%x # read from memory, notice the leak in the syslog file
RTNETLINK answers: Operation not permitted
RTNETLINK answers: Operation not permitted
raptor@fnord:~$ grep "filename string expected" /var/log/syslog
Apr 7 19:28:01 fnord dhclient[5389]: 7cb92e0d7200 line 1: filename string expected.
```
I've just noticed ISC DHCP has recently reached EOL and I can't think of any scenario in which these bugs could be exploited in order to cross a security boundary. However, as format string bugs are a very powerful exploitation primitive, in my opinion they should be fixed in any case just to be careful.
Please let me know if you intend to issue a fix and/or request a CVE ID.
Regards,
--
Marco Ivaldihttps://gitlab.isc.org/isc-projects/dhcp/-/issues/278isc dhcp missing check the length of server identifier2023-04-05T14:50:12ZPeter Daviesisc dhcp missing check the length of server identifier
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = l...
Date: 21/03/2023, 08.50
Hello, I have find a bug in isc-dhcp 4.4.3. The length of server identifier option is 4 bytes. While, I find in dhcprequest() it dose not check the length of it before memecpy the data.
```
oc = lookup_option (&dhcp_universe, packet -> options, DHO_DHCP_SERVER_IDENTIFIER);
memset (&data, 0, sizeof data);
if (oc &&
evaluate_option_cache (&data, packet, (struct lease *)0,
(struct client_state *)0,
packet -> options, (struct option_state *)0,
&global_scope, oc, MDL)) {
sip.len = 4;
memcpy (sip.iabuf, data.data, 4);
```
Thus, I construct a packet with server identifier option 2 bytes("\x02AA"). And I find that it will overread and show the buffer info in the log, as show in the figure: (see email)
Also, I have found that there also has missing length check of the following options. But I can not tirgger them by poc, so I think these may be a bug.
- options 50 dhcprequest() dhcp.c line 472
- option 59 ack_lease() dhcp.c line3368
- option 58 ack_lease() dhcp.c line3385
- option 118 ack_lease() dhcp.c line3302https://gitlab.isc.org/isc-projects/dhcp/-/issues/208isc-dhcp-client adopts server settings despite them not "request"ed2022-03-09T19:02:00ZCarlos Henrique Lima Melaraisc-dhcp-client adopts server settings despite them not "request"ed**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs....**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553023)), but it
still affects the dhclient/dhclient-scripts. The problem is that the dhclient "accepts"
options provided by the dhcp server even when they're not declared in `dhclient.conf`.
For example, I've removed the `ntp-servers` servers from my `dhclient.conf`, but the
dhclient still set `new_ntp_servers` variable and the dhclient-script that deals with
ntp configuration sets it as the ntp server.
**To Reproduce**
Steps to reproduce the behavior:
1. A DHCP server that sends options even if they're not requested
2. A dhclient version isc-dhclient-4.4.1 that doesn't request `ntp-servers` in `dhclient.conf`
3. Allowing the `debug` script show the following variables set by dhclient:
```
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
```
4. After that, Debian scripts take care of changing the ntp server to the one provided
by the dhcp server.
**Expected behavior**
I believe that the dhclient shouldn't set variables that weren't requested in `dhclient.conf`
**Environment:**
- Raspiberry Pi 3B
- Debian GNU/Linux 10 (buster) AArch64
- isc-dhclient-4.4.1
**Additional Information**
I've seen that there has been a lot of discussion on the bugs I've pointed out above,
there is a comment about using `supersede`, but I think this shouldn't be the preferred
solution since many people don't even touch in configuration files.
Also, the BTS indicates the bug has been forwarded upstream already, but I didn't find it.
And since I'm facing this annoying problem every time my rpi3 reboots, I've decided to
fill this bug.
I'll also add my `dhclient.conf` and the scripts I've talked about bellow.
<details>
<summary>dhclient.conf</summary>
```
# Configuration file for /sbin/dhclient.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
# man page for more information about the syntax of this file
# and a more comprehensive list of the parameters understood by
# dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
# not leave anything out (like the domain name, for example), then
# few changes must be made to this file, if any.
#
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes;
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
#require subnet-mask, domain-name-servers;
#timeout 60;
#retry 60;
#reboot 10;
#select-timeout 5;
#initial-interval 2;
#script "/sbin/dhclient-script";
#media "-link0 -link1 -link2", "link0 link1";
#reject 192.33.137.209;
#alias {
# interface "eth0";
# fixed-address 192.5.5.213;
# option subnet-mask 255.255.255.255;
#}
#lease {
# interface "eth0";
# fixed-address 192.33.137.200;
# medium "link0 link1";
# option host-name "andare.swiftmedia.com";
# option subnet-mask 255.255.255.0;
# option broadcast-address 192.33.137.255;
# option routers 192.33.137.250;
# option domain-name-servers 127.0.0.1;
# renew 2 2000/1/12 00:00:01;
# rebind 2 2000/1/12 00:00:01;
# expire 2 2000/1/12 00:00:01;
#}
```
</details>
<details>
<summary>debug</summary>
```
#
# The purpose of this script is just to show the variables that are
# available to all the scripts in this directory. All these scripts are
# called from dhclient-script, which exports all the variables shown
# before. If you want to debug a problem with your DHCP setup you can
# enable this script and take a look at /tmp/dhclient-script.debug.
# To enable this script set the following variable to "yes"
RUN="yes"
if [ "$RUN" = "yes" ]; then
echo "$(date): entering ${1%/*}, dumping variables." \
>> /tmp/dhclient-script.debug
# loop over the 4 possible prefixes: (empty), cur_, new_, old_
for prefix in '' 'cur_' 'new_' 'old_'; do
# loop over the DHCP variables passed to dhclient-script
for basevar in reason interface medium alias_ip_address \
ip_address host_name network_number subnet_mask \
broadcast_address routers static_routes \
rfc3442_classless_static_routes \
domain_name domain_search domain_name_servers \
netbios_name_servers netbios_scope \
ntp_servers \
ip6_address ip6_prefix ip6_prefixlen \
dhcp6_domain_search dhcp6_name_servers ; do
var="${prefix}${basevar}"
eval "content=\$$var"
# show only variables with values set
if [ -n "${content}" ]; then
echo "$var='${content}'" >> /tmp/dhclient-script.debug
fi
done
done
echo '--------------------------' >> /tmp/dhclient-script.debug
fi
```
</details>
<details>
<summary>dhclient-exit-hooks.d/ntp</summary>
```
NTP_CONF=/etc/ntp.conf
NTP_DHCP_CONF=/run/ntp.conf.dhcp
ntp_server_restart() {
invoke-rc.d ntp try-restart
}
ntp_servers_setup_remove() {
if [ ! -e $NTP_DHCP_CONF ]; then
return
fi
rm -f $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup_add() {
if [ -e $NTP_DHCP_CONF ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; then
return
fi
if [ -z "$new_ntp_servers" ]; then
ntp_servers_setup_remove
return
fi
tmp=$(mktemp "$NTP_DHCP_CONF.XXXXXX") || return
chmod --reference=$NTP_CONF $tmp
chown --reference=$NTP_CONF $tmp
(
echo "# This file was copied from $NTP_CONF with the server options changed"
echo "# to reflect the information sent by the DHCP server. Any changes made"
echo "# here will be lost at the next DHCP event. Edit $NTP_CONF instead."
echo
echo "# NTP server entries received from DHCP server"
for server in $new_ntp_servers; do
echo "server $server iburst"
done
echo
sed '/^[[:space:]]*\(server\|peer\|pool\)[[:space:]]/d' $NTP_CONF
) >>$tmp
mv $tmp $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup() {
case $reason in
BOUND|RENEW|REBIND|REBOOT)
ntp_servers_setup_add
;;
EXPIRE|FAIL|RELEASE|STOP)
ntp_servers_setup_remove
;;
esac
}
ntp_servers_setup
```
</details>Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/167omshell returns inconsistent results or segfaults2022-05-10T08:29:46ZBill MacAllisteromshell returns inconsistent results or segfaults---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I have just built a Ubuntu 20.04 server and installed isc-dhcp-server
4.4.1 on it and I am seeing inconsistent returns from omshell.
Initially omsh...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
I have just built a Ubuntu 20.04 server and installed isc-dhcp-server
4.4.1 on it and I am seeing inconsistent returns from omshell.
Initially omshell returns data as expected, but when I exit and re-enter
omshell connections fail.
**To Reproduce**
1. Two DHCP servers need to be configured as failover peers.
2. Issue the following commands using omshell
```
# omshell
> server localhost
> port 7911
> key omapi_key <the key>
> connect
Segmentation fault (core dumped)
```
Note, the connect works occasionally after a cold server restart, but
once the failure starts there is no recovery. The connect does not
always result is a segfault. Frequently the connect just hangs.
**Expected behavior**
This is a successful interaction from a version 4.3.5. server.
```
# omshell
> server localhost
> port 7911
> key omapi_key <the key>
> connect
obj: <null>
> new failover-state
obj: failover-state
> set name = "dhcp-failover"
obj: failover-state
name = "dhcp-failover"
> open
obj: failover-state
name = "dhcp-failover"
partner-address = c0:9d:e9:76:e9:55:00:00
partner-port = 00:00:02:07
local-address = 10:9d:e9:76:e9:55:00:00
local-port = 00:00:02:07
max-outstanding-updates = 00:00:00:0a
mclt = 00:00:01:2c
load-balance-max-secs = 00:00:00:03
load-balance-hba =
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
partner-state = 00:00:00:02
local-state = 00:00:00:02
partner-stos = 60:36:d0:68
local-stos = 60:36:8b:3b
hierarchy = 00:00:00:01
last-packet-sent = 00:00:00:00
last-timestamp-received = 00:00:00:00
skew = 00:00:00:00
max-response-delay = 00:00:00:3c
cur-unacked-updates = 00:00:00:00
```
**Environment:**
- ISC DHCP version: This failure happens with both the 4.4.1 build from Ubuntu and 4.4.2 built using ubuntu/debian packaging tools.
- OS: Ubuntu 20.04 (focal)
**Additional Information**
Our current test environment is failover peers, one running Ubuntu 18.04 with isc-dhcp 4.3.5 and one running Ubuntu 20.04 with isc-dhcp 4.4.2. From the 18.04 system the OMAPI failover connects are all successful and the DHCP servers on both systems appear to be working as expected.
**Some initial questions**
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
We have brought up the issued on the user lists and not gotten any response. I have also submitted a bug to Ubuntu without response. https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1916931
**Describe the solution you'd like**
I need to be able to determine the failover state of a DHCP server and to be able to set a server into failover when needed.
**Describe alternatives you've considered**
We have considered moving to the Kea server, but we have an infrastructure built around ISC DHCP LDAP backend functionality. Since that is a big enough change if we cannot get this working we will take a look at what DHCP servers are available in addition to the Kea server.
**Funding its development**
ISC DHCP is run by ISC, which is a small non-profit organization without any government funding or
any permanent sponsorship organizations. Are you able and willing to participate financially in the
development costs?
We would consider it, but it appears that ISC is not interested in developing ISC DHCP any further.
**Participating in development**
Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code?
Certainly
**Contacting you**
bill@ca-zephyr.org
#isc-dhcp IRC channel on freenode, my id is "iiibill"https://gitlab.isc.org/isc-projects/dhcp/-/issues/156isc-dhcp server crashing when applying dynamic dns updates to bind2020-12-28T20:12:13ZPhilip Prindevilleisc-dhcp server crashing when applying dynamic dns updates to bind**Describe the bug**
Attempting to configure a DHCP server to update the local BIND server via the rndc channel, but it's crashing on the first update in a catalog-related function.
**To Reproduce**
Steps to reproduce the behavior:
1. R...**Describe the bug**
Attempting to configure a DHCP server to update the local BIND server via the rndc channel, but it's crashing on the first update in a catalog-related function.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with the config below.
2. A client requests a lease, and dhcpd sends an update to bind.
3. Bind responds to dhcpd, which promptly segfaults.
4. See error
```
Dec 10 16:47:56 OpenWrt dhcpd: DHCPREQUEST for 192.168.2.7 from 14:7d:da:30:e6:2d via eth0.2
Dec 10 16:47:56 OpenWrt dhcpd: DHCPACK on 192.168.2.7 to 14:7d:da:30:e6:2d via eth0.2
Dec 10 16:47:56 OpenWrt named[12134]: client @0x6242a00 127.0.0.1#40875/key rndc-key: update 'redfish-solutions.com/IN' denied
Dec 10 16:47:56 OpenWrt kernel: [276717.908462] dhcpd[14927]: segfault at 3 ip 00007f62152aba4b sp 00007ffe57143ce0 error 4 in libc.so[7f621529d000+49000]
```
and the backtrace:
```
(gdb) info stack
#0 0x00007f66d350aa4b in catgets (catd=0xffffffffffffffff, set_id=2,
msg_id=1, s=0x5bd0cc "success") at src/locale/catgets.c:19
#1 0x0000000000593aa9 in isc_result_tomany_helper.isra ()
#2 0x000000000056a6b5 in req_response ()
#3 0x0000000000599c64 in isc.taskmgr_dispatch ()
#4 0x000000000059c78e in evloop ()
#5 0x000000000059cb1c in isc.app_ctxrun ()
#6 0x00000000004451eb in dispatch ()
#7 0x000000000040529a in main ()
(gdb)
```
and the dependencies of `dhcpd` when built for x86_64 on OpenWRT master:
```
root@OpenWrt:~# ldd /usr/sbin/dhcpd
/lib/ld-musl-x86_64.so.1 (0x7f502f253000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7f502f23f000)
libc.so => /lib/ld-musl-x86_64.so.1 (0x7f502f253000)
root@OpenWrt:~#
```
**Expected behavior**
Misconfiguration should result it errors, not crashes.
**Environment:**
- 4.4.1
- OpenWRT x86_64 w/ MUSL
- Configured (through the packaging system) as:
```
AR="x86_64-openwrt-linux-musl-gcc-ar" AS="x86_64-openwrt-linux-musl-gcc -c -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.1=dhcp-4.4.1 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fcommon" LD=x86_64-openwrt-linux-musl-ld NM="x86_64-openwrt-linux-musl-gcc-nm" CC="x86_64-openwrt-linux-musl-gcc" GCC="x86_64-openwrt-linux-musl-gcc" CXX="x86_64-openwrt-linux-musl-g++" RANLIB="x86_64-openwrt-linux-musl-gcc-ranlib" STRIP=x86_64-openwrt-linux-musl-strip OBJCOPY=x86_64-openwrt-linux-musl-objcopy OBJDUMP=x86_64-openwrt-linux-musl-objdump SIZE=x86_64-openwrt-linux-musl-size CFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.1=dhcp-4.4.1 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fcommon " CXXFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -fmacro-prefix-map=/home/philipp/lede/build_dir/target-x86_64_musl/isc-dhcp-ipv6/dhcp-4.4.1=dhcp-4.4.1 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fcommon " CPPFLAGS="-I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/include -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include/fortify -I/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include " LDFLAGS="-L/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/lib -L/home/philipp/lede/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/lib -znow -zrelro " ./configure --target=x86_64-openwrt-linux --host=x86_64-openwrt-linux --build=x86_64-pc-linux-gnu --program-prefix="" --program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --enable-paranoia --disable-dependency-tracking --with-randomdev=/dev/urandom ac_cv_file__dev_random=yes --enable-dhcpv6
```
**Additional Information**
My config:
```
authoritative;
ddns-domainname "redfish-solutions.com.";
ddns-rev-domainname "in-addr.arpa.";
ddns-update-style interim;
ignore client-updates;
update-static-leases on;
use-host-decl-names on;
option domain-name "redfish-solutions.com.";
include "/tmp/run/dhcpd-rndc.key";
update-optimization off;
update-conflict-detection off;
# include "/etc/bind/rndc.conf";
zone redfish-solutions.com. {
primary 127.0.0.1;
key rndc-key;
}
zone 168.192.in-addr.arpa. {
primary 127.0.0.1;
key rndc-key;
}
log-facility daemon;
default-lease-time 3600;
max-lease-time 86400;
option domain-name "redfish-solutions.com";
# additional codes
option classless-ipv4-route code 121 = array of { unsigned integer 8 };
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.128 192.168.1.160;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
default-lease-time 43200;
max-lease-time 43200;
option routers 192.168.1.252;
option domain-name-servers 192.168.1.252;
option domain-search "redfish-solutions.com", "redfish-consulting.com";
option ntp-servers 192.168.1.40, 192.168.1.252;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.16 192.168.2.254;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;
default-lease-time 3600;
max-lease-time 3600;
option routers 192.168.2.1;
option domain-name-servers 192.168.2.1;
option domain-search "redfish-solutions.com", "redfish-consulting.com";
option ntp-servers 192.168.1.40, 192.168.2.1;
}
host pbx {
fixed-address 192.168.1.1;
option host-name "pbx";
}
...
```
**Some initial questions**
N/A
**Is your feature request related to a problem? Please describe.**
N/A
**Describe the solution you'd like**
It would be nice if (1) it didn't crash, obviously, and (2) there was a top-level build option to disable message catalogs, like `--disable-nls`.
**Describe alternatives you've considered**
If I patch dhcp-4.4.1/bind/Makefile.in as:
```
...
(cd ${bindsrcdir} && \
+ ac_cv_func_catgets=no \
./configure ${bindconfig} > ${binddir}/configure.log); \
...
```
then I don't see this problem.
**Additional context**
N/A
**Funding its development**
N/A
**Participating in development**
I'm willing to spend time developing and/or testing a fix.
**Contacting you**
philipp@redfish-solutions.comhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/141dhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is s...2020-12-03T15:38:00ZGregMoreldhcp-lease-list fails to parse /var/lib/dhcpd.leases when db-time-format is set to locale---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set ...---
name: Bug Report
about: dhcp-lease-list script fails to parse leases file if db-time-format is set to locale
---
**Describe the bug**
`dhcp-lease-list` script fails to parse `/var/lib/dhcpd.leases` file if `db-time-format` is set to `locale`
**To Reproduce**
1. In `dhcpd.conf`, set `db-time-format locale`
2. Restart dhcp service
3. On a dhcp client, run `dhclient -r`
4. On the server, run `dhcp-lease-list`: the lease does not appear
**Expected behavior**
Leases should appear in `dhcp-lease-list` command's output, even if `db-time-format` is set to `locale`
**Environment**
- ISC DHCP version: 4.4.1
- OS: Ubuntu Server 20.04 x64
**Additional Information**
After investigation, the problem occurs because of the following part in `dhcp-lease-list` Perl script:
```Perl
# skip invalid lines
next if not ($lease =~ /^\s+([\.\d]+)\s+{.*starts \d+ ([\/\d\ \:]+);.*ends \d+ ([\/\d\ \:]+);.*ethernet ([a-f0-9:]+);(.*client-hostname \"(\S+)\";)*/s);
```
Indeed, this regex does not match leases written with date format that respect the `db-time-format locale` flag, that is (according to `man dhcpd.leases`):
> If the db-time-format was configured to local, then the date fields appear as follows:\
`epoch <seconds-since-epoch>; # <day-name> <month-name> <day-number> <hours>:<minutes>:<seconds> <year>`Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/1152038 problem2020-07-30T07:29:58Zgaoxingwang2038 problemThe 2038 problem does not bother 64Bit architecture, maybe we should add a judgment,like this :
```
if (year >= 138 && sizeof(TIME) < 8)
return(MAX_TIME);
```The 2038 problem does not bother 64Bit architecture, maybe we should add a judgment,like this :
```
if (year >= 138 && sizeof(TIME) < 8)
return(MAX_TIME);
```Outstanding