ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-12-03T15:25:55Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/145DHCPD 4.4.2 5 bad IP checksums seen in 5 packets2020-12-03T15:25:55ZAndrea PostiglioneDHCPD 4.4.2 5 bad IP checksums seen in 5 packetsthis is the syslog dhcpd
```
Nov 4 20:05:32 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:33 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.149 to 08:00:27:8a:48:da via br0
Nov 4 20:05:46 thunderd...this is the syslog dhcpd
```
Nov 4 20:05:32 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:33 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.149 to 08:00:27:8a:48:da via br0
Nov 4 20:05:46 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:05:47 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.150 to 08:00:27:8a:48:da via br0
Nov 4 20:07:19 thunderdome dhcpd[11327]: DHCPDISCOVER from 08:00:27:8a:48:da via br0
Nov 4 20:07:20 thunderdome dhcpd[11327]: DHCPOFFER on 192.168.178.151 to 08:00:27:8a:48:da via br0
```
```
customsrescuecd ~ # dhclient -v eth0
Internet Systems Consortium DHCP Client 4.4.2 Gentoo-r2
Copyright 2004-2020 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/08:00:27:8a:48:da
Sending on LPF/eth0/08:00:27:8a:48:da
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
5 bad IP checksums seen in 5 packets
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
```
it seems that the udp packets generated by the server despite being a physical machine have the wrong checksum!
can someone help me?https://gitlab.isc.org/isc-projects/dhcp/-/issues/144Cisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to sa...2020-12-03T15:37:35ZGunnar HaslingerCisco ASA / AnyConnect VPN using ISC DHCPD - reassign IP-Address-leases to same VPN-Clients**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the sam...**Scenario:**
- Cisco AnyConnect VPN-Clients
- Cisco ASA Appliance as DHCP-Client for the VPN-Clients
- ISC DHCPD as DHCP-Server for the Cisco ASA
We like to have a lease-time of e.g. 8 days. A client connecting today should get the same IP as it got yesterday. Our idea is to provide an IP-lease-Pool big enough to have pseudo-static Client-IP-Addresses. The address the client gets on it's first connect should be the same it gets the following days/months.
**Currently VPN-Clients are not assigned the same IP-Address, because:**
- Cisco ASA is acting as DHCP-Client for the VPN-Clients
- The Client-MAC of all VPN-Clients is the same (the ASA MAC)
The Client-UID (Client identifier) sent by the ASA is a combined-string of `"cisco-$MAC-$Hostname$Counter-inside"`.
- For example: `cisco-0050.5680.4b04-ClientA4567-inside`
- The Prefix "cisco" + MAC-Address of the Cisco-ASA is always the same: `cisco-0050.5680.4b04`
- The Hostname (e.g. "ClientA") is the real (unique) Hostname of our Client-Machines
- The counter counts up on every connection.
- Suffix "-inside" is always the same
- If "ClientA" disconnects and connects again it will be like `cisco-0050.5680.4b04-ClientA4568-inside` (the last digits count up)
- There seem to be no way to configure the Cisco ASA to not count up the Client-UIDs last digits on each connection
- We tried to use Option "`ignore-client-uids true;`" to reassign the same IP-Address - but this does not work, because without UID only the MAC-Address is used to re-assign the IP-Address, but all Clients have the same (Cisco ASA) MAC-Address.
**Are there any suggestions?**
- If there is no solution for this scenario, we are interested to implement an new ISC DHCPd Option "`hostname-as-uid true;`" to create the possibility to address this scenario.
- This option "`hostname-as-uid true;`" could be used like the existing "`ignore-client-uids true;`" Option, but instead of not saving the Client-UID we would override the received Client-UID with the received hostname-option.
- All functionality like storing the uid to the lease-file, checking if there is a lease for the client with the given Client-UID etc... will be done with the "replaced uid" (= Hostname) instead of the real received Client-UID.
- Are there any other suggestions or comments on this?
- Is there interest to accept a merge request if we implement such a feature?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/bind9/-/issues/2336Implement TSIG-GSS on Windows2020-12-04T08:37:04ZMark AndrewsImplement TSIG-GSS on WindowsWindows should have the necessary components to do this using Windows APIs.Windows should have the necessary components to do this using Windows APIs.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1541Add backend call counters2020-12-21T13:08:48ZFrancis DupontAdd backend call countersThe idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far...The idea is to add simple counters (vs full stats) for backend API method calls. For instance in #1418 it would be very fine to confirm that a lease is not updated twice. I know that profiling can get the same information but this is far more immediate for a low cost (i.e. I am sure the cost will be more than recovered by optimizations it is expected to allow).
Note we do not need large counters: it does not matter if a counter wraps as soon as it takes a long time to happen...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1544user-class filtering per reservation (Microsoft DHCP)2020-12-21T13:11:08ZTomek Mrugalskiuser-class filtering per reservation (Microsoft DHCP)Some time ago there was [a discussion on kea-users](https://lists.isc.org/pipermail/kea-users/2019-April/002333.html) (note: the discussion continued in May). Here's what the user was trying to do:
> What mkangelo and I are trying to do...Some time ago there was [a discussion on kea-users](https://lists.isc.org/pipermail/kea-users/2019-April/002333.html) (note: the discussion continued in May). Here's what the user was trying to do:
> What mkangelo and I are trying to do is to replace Microsoft DHCP server which has a feature to create host reservations with
two option 67 values which are served to the client based on the class (type) of the client - for example return undionly.kpxe when client is pxe return https://api.example.com/customurl/ when client is gpxe
Here's an expression they're trying to achieve:
```
Client class is extracted from DHCP Discover packets:
IF Option [77] == gPXE
then second value is being returned
ELSEIF Option [60] == "PXEClient:Arch:00000:UNDI:002001"
then first value is returned
```
This seems like a useful feature that's provided by some other implementations.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1569link warnings on MacOs2020-12-21T13:53:04ZRazvan Becheriulink warnings on MacOsfound during #1565
```
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(lib...found during #1565
```
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_sun.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_linux.o) has no symbols
/Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libkea-dhcp++.a(libkea_dhcp___la-iface_mgr_sun.o) has no symbols
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1575warnings on raspian2020-12-21T14:05:18ZFrancis Dupontwarnings on raspianhttps://gitlab.isc.org/isc-projects/kea/-/issues/1568#note_178684https://gitlab.isc.org/isc-projects/kea/-/issues/1568#note_178684outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1607Investigate whether Boost.log could replace log4cplus2020-12-21T14:42:43ZTomek MrugalskiInvestigate whether Boost.log could replace log4cplusKea has few core dependencies - boost, log4cplus and one of either OpenSSL or Botan. The log4cplus has been in use since the very beginning and was inherited from BIND10 days a decade ago. We never seriously looked at alternatives.
Depe...Kea has few core dependencies - boost, log4cplus and one of either OpenSSL or Botan. The log4cplus has been in use since the very beginning and was inherited from BIND10 days a decade ago. We never seriously looked at alternatives.
Dependency on log4cplus is sometimes a problem, especially in newer systems. Here's an [example of problems on CentOS8](https://lists.isc.org/pipermail/kea-users/2020-December/002954.html).
The goal of this ticket is to:
- investigate if boost.log can possibly be used as a replacement
- provide an estimate of how much work would it take to do it
This ticket is not about doing the migration itself.outstandinghttps://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/149dhcpd is not escaping quotes (") in .leases2021-01-13T10:46:18ZJoost Bekkersdhcpd is not escaping quotes (") in .leases---
name: Bug report
about: dhcpd can't parse it's own .leases file when using events containing escaped " (&quot;)
---
**Describe the bug**
When a release and/or expire event is configured which contains an escaped quote (ie "this is...---
name: Bug report
about: dhcpd can't parse it's own .leases file when using events containing escaped " (")
---
**Describe the bug**
When a release and/or expire event is configured which contains an escaped quote (ie "this is a quote \"." )
the event definition is also written to the leases file when applicable. The backslash used to escape the quote is not written.
When the daemon is restarted it can't parse the leases file and complains it is corrupt.
**To Reproduce**
1. Run dhcpd containing the following config
~~~
on release {
set clip = binary-to-ascii(10, 8, ".", leased-address);
set clhw = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
set cid = pick-first-value( concat( "\"", substring(option agent.circuit-id,2,256), "\""), "NO-CID");
set rid = pick-first-value( concat( "\"", substring(option agent.remote-id,2,256), "\""), "NO-RID");
log(info, concat( "RELEASE ", clip, " on ", clhw, " at ", cid, "/", rid));
}
~~~
2. Wait for a client to obtain a lease and the .leases file to be updated.
3. Observe that the leases file now contains
~~~
on release {
set clip =
binary-to-ascii (10, 8, ".", leased-address) ;
set clhw =
binary-to-ascii (16, 8, ":",
substring (hardware, 1, 6)) ;
set cid =
pick-first-value (concat (concat (""",
substring (option agent.circuit-id, 2,
256)), """), "NO-CID") ;
set rid =
pick-first-value (concat (concat (""",
substring (option agent.remote-id, 2,
256)), """), "NO-RID") ;
log (info,
concat (concat (concat (concat (concat (concat (concat ("RELEASE ", clip), " on "),
clhw), " at "), cid), "/"), rid));
}
~~~
3. Restart dhpcd
4. See errors about "comma expected" and "possibly corrupt lease file"
**Expected behavior**
Leases file should be written including the escaping backslash.
**Environment:**
- ISC DHCP version: 4.4.2
- OS: FreeBSD 12
- Which features were compiled in
**Describe the solution you'd like**
I think the problem is in token_indent_data_string() in common/print.c. The purely ASCII path should insert a backslash where needed.
It might be easier to just handle the string as binary, but that impacts human readability.https://gitlab.isc.org/isc-projects/kea/-/issues/1345Ability to always-respond to all requests in HA active-active mode to support...2021-01-22T13:30:51ZEwald van GeffenAbility to always-respond to all requests in HA active-active mode to support anycast DHCPMy impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closes...My impression is that ISC KEA doesn't always respond to all requests. I think this is due to the 1/n split.
I run two KEA instances sharing a single BGP anycast /32 IP prefix. DHCP Requests get routed via a DHCP relay towards the closest ISC KEA instance according to BGP. Load balancing is externally handled. This means KEA should respond to all requests it receives and not impose any load-balancing logic.
I think this is where the magic happens [1]
From my understanding active_servers needs to reflect the current server instance id (pri,sec).
[1] https://github.com/isc-projects/kea/blob/457111f9db051723ff9f8e7fb621872d0aa10363/src/hooks/dhcp/high_availability/query_filter.cc#L316outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/86dhcpd does not do option 54 (Server Identifier) in certain situations2021-01-25T00:28:24ZGhost Userdhcpd does not do option 54 (Server Identifier) in certain situations**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with the following config 'interface devnet;' where devnet is a VLAN. Upon starting dhcpd no physical Ethernet interface is connected yet (e.g. un-docked notebook). Albeit th...**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with the following config 'interface devnet;' where devnet is a VLAN. Upon starting dhcpd no physical Ethernet interface is connected yet (e.g. un-docked notebook). Albeit this being logged as 'dhcpd[1345]: devnet missing an interface
address' dhcpd does successfully start.
2. Notebook gets connected to an Ethernet where Embedded Linux boards are connected via a switched VLAN.
3. A client (e.g. connman running on one of them Embedded Linux targets) does send a DHCP Discover packet
4. The server then responds with a DHCP Offer packet missing option 54 (Server Identifier). Unsure whether or not this may even be illegal according to spec.
4. Unfortunately, connman seems to crash (this is a separate issue to be reported at resp. upstream project).
**Expected behavior**
The dhcpd should never send DHCP Offer packets missing option 54 (Server Identifier).
**Environment:**
- ISC DHCP version: isc-dhcpd-4.4.1 (dhcp-server-4.4.1-19.fc31.x86_64).
- OS: Fedora 31 x64
- Which features were compiled in
http://rpmfind.net/linux/RPM/fedora/updates/31/x86_64/Packages/d/dhcp-server-4.4.1-19.fc31.x86_64.html
**Additional Information**
A colleague of mine once already enquired about this (see below original message) but never got any response.
-------- Original Message --------
Subject: dhcpd does not option 54 (Server Identifier) in certain
situations
Date: 2018-05-09 17:42
From: Stefan Agner <stefan@agner.ch>
To: dhcp-bugs@isc.org
Hello,
When I am using dhcpd 4.4.1 on Linux on a VLAN network interface I can
successfully start the server. When I then connect the Ethernet cable,
dhcpd sends DHCPOFFERs to DHCPDISCOVERs, however they miss option 54.
A quick debug session showed that get_server_source_address gets called
from ack_lease and does not get an address since
packet->interface->address_count is 0.
During startup the DHCP server actually reports the missing interface
address.
Mai 09 17:16:49 trochilidae systemd[1]: Starting IPv4 DHCP server...
Mai 09 17:16:49 trochilidae dhcpd[1345]: Not searching LDAP since
ldap-server, ldap-port and ldap-base-dn were not specified in the
config
Mai 09 17:16:49 trochilidae dhcpd[1345]: Internet Systems Consortium
DHCP Server 4.4.1
Mai 09 17:16:49 trochilidae dhcpd[1345]: Copyright 2004-2018 Internet
Systems Consortium.
Mai 09 17:16:49 trochilidae dhcpd[1345]: All rights reserved.
Mai 09 17:16:49 trochilidae dhcpd[1345]: For info, please visit
https://www.isc.org/software/dhcp/
Mai 09 17:16:49 trochilidae dhcpd[1345]: Source compiled to use
binary-leases
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 0 deleted host decls to
leases file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 0 new dynamic host decls
to leases file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: Wrote 155 leases to leases
file.
Mai 09 17:16:49 trochilidae dhcpd[1345]: vlaneth0 missing an interface
address
Mai 09 17:16:49 trochilidae dhcpd[1345]: Server starting service.
Mai 09 17:16:49 trochilidae systemd[1]: Started IPv4 DHCP server.
Mai 09 17:17:03 trochilidae dhcpd[1345]: DHCPDISCOVER from
00:14:2d:2d:e4:c9 via vlaneth0
Mai 09 17:17:04 trochilidae dhcpd[1345]: DHCPOFFER on 192.168.10.168 to
00:14:2d:2d:e4:c9 (hostname) via vlaneth0
As far as I can tell DHCP mandates option 54. It seems to me that the
behavior currently is not ideal. The DHCP server should either deny
sending DHCPOFFERs or not start in first place...?
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? No, but at least I could not spot anything relevant in the history since.
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration? Good question. Kea is news to me but I will give it a try and update this ticket should our use case work there.
- Are you sure what you would like to do is not possible using some other mechanisms? Well, one could keep manually re-starting dhcpd over and over again...
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? Yes, I'm coming from their suggestion to log this as a bug.4.5.0-betahttps://gitlab.isc.org/isc-projects/kea/-/issues/1669formatting tools vs line length limits2021-02-04T16:55:45ZFrancis Dupontformatting tools vs line length limitsWe need hard and soft line limits in the formatting tools to match the code guide lines and keep the code readable... It seems the current tools do not provide soft/hard limits and tuning is a bit hard so #1455 was merged leaving this is...We need hard and soft line limits in the formatting tools to match the code guide lines and keep the code readable... It seems the current tools do not provide soft/hard limits and tuning is a bit hard so #1455 was merged leaving this issue not yet addressed.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1679Change reuseable_* to reusable_* .2021-02-11T16:40:18ZRazvan BecheriuChange reuseable_* to reusable_* .Currently only the Lease* structure has 2 parameters using the wrong spelling of reusable_:
uint32_t reuseable_valid_lft_;
uint32_t reuseable_preferred_lft_;
As the Lease is internal to Kea, this should be easy to do without im...Currently only the Lease* structure has 2 parameters using the wrong spelling of reusable_:
uint32_t reuseable_valid_lft_;
uint32_t reuseable_preferred_lft_;
As the Lease is internal to Kea, this should be easy to do without impacting clients.
The only affected 'external' functionality could be the user hook libraries.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/stork/-/issues/407automate combining ChangeLog into release notes2021-03-02T18:22:51ZMichal Nowikowskiautomate combining ChangeLog into release notesoutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2214forward zones aren't zones and shouldn't be configured as if they were2021-03-04T10:08:09ZBrian Conryforward zones aren't zones and shouldn't be configured as if they were"zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zone..."zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zones or `rndc addzone`.
The configuration block declaring them should be renamed to `forward` or something else unambiguous.
Alternatively, all of the things that operates on zones and can't handle a forward "zone" should be fixed so that they can.https://gitlab.isc.org/isc-projects/dhcp/-/issues/165Consider enabling binary leases by default2021-03-04T14:57:30ZHazael SanchezConsider enabling binary leases by default---
name: Consider enabling binary leases by default
about: Binary leases should be enabled out by default
---
ISC DHCP provides the compile-time option of `--enable-binary-leases`, quoting https://kb.isc.org/docs/aa-01283:
> In 4.3.3...---
name: Consider enabling binary leases by default
about: Binary leases should be enabled out by default
---
ISC DHCP provides the compile-time option of `--enable-binary-leases`, quoting https://kb.isc.org/docs/aa-01283:
> In 4.3.3 we have added a compile time option to process the lists in a binary fashion instead of needing to walk them in a linear fashion. As with all of our code, we have tested this feature out and found it useful. However, we have chosen to require you to select it via a compile time option, which allows our users to test it out in their environments and report back to us in case there are cases we did not consider in our testing while still having the fallback of the previous code.
We've found this performance improvement to be _substantial_ when dealing with large and high-churn ranges, particularly wrt CPU utilization. We've been using binary leases successfully for around 5 years.
Is it feasible to make this feature enabled by default? AFAICT there are no downsides to enabling this flag.https://gitlab.isc.org/isc-projects/kea/-/issues/1718backport #1711 to 1.8.x - crash when using forensic logging with MT2021-03-04T16:29:50ZRazvan Becheriubackport #1711 to 1.8.x - crash when using forensic logging with MTThere was a problem with DB_LOG macros, which were not thread safe, and could cause crashes when using forensic logging with database backend and MTThere was a problem with DB_LOG macros, which were not thread safe, and could cause crashes when using forensic logging with database backend and MTkea1.8.3