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/211Preload oui.txt in dhcp-lease-list-pl for significantly improved runtimes2022-01-28T19:32:27ZbretgiddingsPreload oui.txt in dhcp-lease-list-pl for significantly improved runtimesThe current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve pe...The current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve performance. Simple tests show that doing this with 50 valid leases will be 5 times faster. For 1000 leases, the speedup is of the order of 100 time faster - indeed, with the hashed file, 1000 leases is still significantly faster than 50 leases without the hashed data.4.5.0-betahttps://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/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/126Subnet mask improperly validated2022-03-09T18:57:18ZDiego Garcia del RioSubnet mask improperly validated---
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**
Subnet masks are not completely validated for proper formatting. Thus the system accepts an IP address such as 10.254.130.65 as a subnet mask in certain cases. This causes several issues as hosts from the "wrong" subnet will be percieved to belong to this subnet and overall wreak havoc in the network
**To Reproduce**
Steps to reproduce the behavior:
create the following subnet:
```
subnet 10.254.130.64 netmask 10.254.130.65 {
option subnet-mask 10.254.130.65;
option domain-name-servers 135.227.24.250, 152.148.152.45, 152.148.152.38;
option interface-mtu 1600;
}
```
and then this host:
```
host CLIENT1 { hardware ethernet AA:00:CC:11:EE:22; fixed-address 10.254.170.192; }
```
Starting dhcpd will not complain at all. Accepting the configuration.
When client1 sends a DHCP discover, it will be offered the 10.254.170.192 address but the subnet mask of 10.254.130.65
![dhcp_wron_mask](/uploads/5a9aae012a6c019e5769048840b3758c/dhcp_wron_mask.png)
shows the subnet mask being sent to the client
My config is quite scaled (but I can provide the complete config file if needed).
So there are two issues:
- Invalid subnet masks are accepted
- These invalid subnet masks create issues where hosts are mapped to the wrong subnet and get options from those subnets
**Expected behavior**
- Subnet masks should be validated to be "contiguous ones" when seen in binary
- host-to-subnet validation seems to have to be revisited
**Environment:**
- ISC DHCP version: which release? if it's compiled from git, which revision. Use `dhcpd --version`
to find out.
```
[root@wfnupxe1 ~]# dhcpd --version
isc-dhcpd-4.2.5
```
```
[root@wfnupxe1 ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
```
Installed from RPM
**Additional Information**
I can provide the config files separately but due to the size, its difficult to anonymise.. Also, they are quite large but I think this small sample should be enough to reproduce.
I have not checked the code for the DHCP client to see if it accepts the non-standard mask, but at least both the intel PXE dhcp agent as well as the ATEN IPMI DHCP seem to have accepted the subnet mask and thus result in broken connectivity.
**Additional context**
Add any other context about the feature request here.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as
e-mail, jabber id or a telephone, we may send you a message on github with questions when we have
them.
contact me at garci66@gmail.com or diego.garcia_del_rio@nokia.comOutstanding