ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-03-09T19:03:21Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/56relay: Segfault on replies not intended for us2022-03-09T19:03:21ZGhost Userrelay: Segfault on replies not intended for us**Describe the bug**
Segfault of `dhcrelay -a` upon receipt of answer packet not intended for us, but with a circuit ID that resolves to a local interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure this setup with a...**Describe the bug**
Segfault of `dhcrelay -a` upon receipt of answer packet not intended for us, but with a circuit ID that resolves to a local interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure this setup with all relevant routes (think of R1 and R2 as failover partners in a VRRP setup with dynamic routing):
* R1 has interfaces
* eth0 with address 10.0.0.1/24 (backbone)
* eth1 with address 10.0.1.1/24 (clients1)
* eth2 without address
* eth3 without address
* R2 has interfaces
* eth0 with address 10.0.0.2/24 (backbone)
* eth1 without address
* eth2 with address 10.0.2.2/24 (clients2)
* eth3 with address 10.0.3.2/24 (to DHCP-Server)
1. Run `dhcrelay -a -iu eth0 -iu eth3 -id eth1 -id eth2 10.0.3.100` on both R1 and R2
2. A client in 10.0.1.1/24 (clients1) sends a request via relay R1, that relays it to 10.0.3.100. The relayed packet is routed by R2 like a regular IP packet
3. The server 10.0.3.100 replies to R1 via unicast
4. dhcrelay on R2 sees the answer packet and inspects it. It doesn't find a matching interface via giaddr, but via Circuit ID, which contains "eth1". But eth1 doesn't have an address configured that it could use to send the reply, so dhcrelay segfaults.
**Expected behavior**
R2 should ignore the packet.
**Environment:**
- ISC DHCP version: Tested on 4.3.5-3+deb9u1, but relevant code is present in master
- OS: Debian Stretch x64
**Additional Information**
The segfault itself is caused [in dhcrelay.c](https://gitlab.isc.org/isc-projects/dhcp/blob/master/relay/dhcrelay.c#L912):
```c
if (send_packet(out, NULL, packet, length, out->addresses[0], &to, htop) < 0) {
```
Because `strip_relay_agent_options()` earlier set `out` to eth1, `out->addresses` is a NULL reference because eth1 doesn't have any addresses.
The segfault should be avoided by checking that `out` is not only non-NULL but also has addresses:
```diff
--- a/relay/dhcrelay.c
+++ b/relay/dhcrelay.c
@@ -902,7 +902,7 @@ do_relay4(struct interface_info *ip, struct dhcp_packet *packet,
strip_relay_agent_options(ip, &out, packet, length)))
return;
- if (!out) {
+ if (!out || out->address_count == 0) {
log_error("Packet to bogus giaddr %s.\n",
inet_ntoa(packet->giaddr));
++bogus_giaddr_drops;
```
(This whole bug report would have been much easier as a merge request, but I'm not allowed to clone the repository)https://gitlab.isc.org/isc-projects/dhcp/-/issues/204dhcrelay -6 does not work if there are interface aliases up in the system2022-03-09T19:02:55ZSantiagodhcrelay -6 does not work if there are interface aliases up in the systemHi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrel...Hi there,
I've been hit by this issue on Debian stretch through sid (the latest including 4.4.1, I've been unable to test on 4.4.2).
dchrelay -6 doesn't start if there are interface aliases up in the
system:
```
# /usr/sbin/dhcrelay -6 -pf /var/run/dhcrelay6.pid -l vlan.881 -u 2001:db8:cafe::2%vlan.880
Internet Systems Consortium DHCP Relay Agent 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Bound to *:547
Listening on Socket/vlan.881:0
Sending on Socket/vlan.881:0
Listening on Socket/vlan.880:0
Sending on Socket/vlan.880:0
Listening on Socket/vlan
Sending on Socket/vlan
setsockopt: IPV6_JOIN_GROUP: Address already in use
If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug. These pages explain the proper
process and the information we find helpful for debugging.
exiting.
```
The above error can be reproduced with inside a container with the following /etc/network/interfaces:
```
auto lo
iface lo inet loopback
auto vlan
iface vlan inet dhcp
auto vlan.880
auto vlan.880:0
iface vlan.880 inet static
address 192.168.133.1/24
iface vlan.880 inet6 static
address 2001:db8:cafe::1/64
iface vlan.880:0 inet static
address 10.0.133.1/16
auto vlan.881
auto vlan.881:0
iface vlan.881 inet static
address 192.168.131.1/24
iface vlan.881 inet6 static
address 2001:db8:cafe:1::1/64
iface vlan.881:0 inet static
address 10.1.131.1/16
```
Just removing (or commenting out) the interface aliases entries makes dchrelay -6 happy (again).
Please note the `-l` and `-u` filters do not work. But that's another bug.
This seems similar to #88. The patch attached there doesn't fix the problem.Outstandinghttps://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/202Enhance dhclient to parse multiple instances in Option 17/43/1252022-03-09T19:00:29Zdongyang wangEnhance dhclient to parse multiple instances in Option 17/43/125---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure...---
name: Feature request
about: Enhance dhclient to parse multiple instances in Option 17/43/125
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
This is for DHCP client, and KEA doesn't support client.
- Are you sure what you would like to do is not possible using some other mechanisms?
Not sure, maybe there also has other way.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
Sorry, I commit to here first. Upload the patch as an attachment.
[0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch](/uploads/0daaff86a3432d950fb316177a0666fb/0001-Enhance-dhclient-to-parse-multiple-instances-in-Opti.patch)
**Is your feature request related to a problem? Please describe.**
When DHCP server sends a single instance in Option 17/43/125 from the dhclient-exit-hooks,
dhclient can parse it well.
But if DHCP server sends multiple instances, dhclient only can parse the first one.
**Describe the solution you'd like**
Use a do-while to parse each "struct option_cache-->option" in the oclist.
**Describe alternatives you've considered**
**Additional context**
**Funding its development**
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
Yes! It's my pleasure, I'm very glad to do these.
**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.
Maybe here has a typo: >>we may send you a message on **github **with questions when we have them.
We are on GitLab now :)
Using GitLab can contact me, thanks.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/194resolvconf support is missing in dhclient2022-03-09T19:00:02Zonehalf3544resolvconf support is missing in dhclientBy default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/...By default dhclient overwrites the /etc/resolv.conf once the nameservers' ips are obtain from the DHCP server or the lease is renewed. This becomes problematic when there are other source of those from other interfaces (e.g. openconnect/openvpn, which set up DNS servers from the private network). The natural solution is the usage of resolvconf, which manages such updates from multiple sources and merges them into /etc/resolv.conf
Since this is more like a feature request, it was suggested that this should be fixed here (https://bbs.archlinux.org/viewtopic.php?pid=1969134).
Would such PR be accepted? The changes are quite trivial..
Thanks.
**Describe the bug**
dhclient overwrites the /etc/resolv.conf blindly, disregarding the fact that it could have been updated by other (dhcp) clients
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient with default config
2. Modify /etc/resolv.conf by any means
3. Wait for the lease renewal on the dhclient interface
4. Observe the contents of the /etc/resolv.conf
**Expected behavior**
/etc/resolv.conf contents should be preserved somehow. Proposed way is to use resolvconf for that.
**Environment:**
dhclient --version
isc-dhclient-4.4.2
- OS: ArchLinux
Linux laptop_name 5.12.7-arch1-1 #1 SMP PREEMPT Wed, 26 May 2021 22:03:57 +0000 x86_64 GNU/Linux
pacman -F dhclient
core/netctl 1.24-1
usr/lib/netctl/dhcp/dhclient
**Additional Information**
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It is not - https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/scripts/linux#L80
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
Did not check, but would prefer to keep original dhclient
- Are you sure what you would like to do is not possible using some other mechanisms?
Using hooks, yes, but feature implementation is better to be done as close to the source as possible
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
arch linux forum - https://bbs.archlinux.org/viewtopic.php?pid=1969134#p1969134
**Is your feature request related to a problem? Please describe.**
I'm frustrated when my VPN tunnel DNS server IP is overwritten with the ISP dhcp
**Describe the solution you'd like**
Check if /usr/bin/resolvconf exists and use it if it does
**Describe alternatives you've considered**
switch to a different dhcp client
**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?
I could provide the patch once I can fork the project here
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature
as generic as possible, so it can be used in wide variety of situations. That means the proposed
solution may be a bit different that you initially thought. Are you willing to take part in the
design discussions? Are you willing to test an unreleased engineering code?
yes
**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.
onehalf3544@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/178[dhclient] Client did not bind to the address even after receiving DHCPACK2022-03-09T18:59:26ZVivek Reddy[dhclient] Client did not bind to the address even after receiving DHCPACK**Describe the bug**
Usually, every DHCPACK message is followed by a bound log message.
```
Mar 29 10:20:46.328836 sonic INFO dhclient[3350]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:20:46.329931 sonic...**Describe the bug**
Usually, every DHCPACK message is followed by a bound log message.
```
Mar 29 10:20:46.328836 sonic INFO dhclient[3350]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:20:46.329931 sonic INFO dhclient[3350]: DHCPACK of 10.210.24.228 from 10.211.0.124
Mar 29 10:20:46.584251 sonic INFO dhclient[3350]: bound to 10.210.24.228 -- renewal in 1536 seconds.
Mar 29 10:21:19.521847 sonic INFO dhclient[7991]: DHCPRELEASE of 10.210.24.228 on eth0 to 10.211.0.124 port 67
```
DHCPRELEASE because there were systemd restarts in between and it made the dhclient to explicitly release the IP Address.
After a few such cycles and following the last DHCPACK, there was no bound to log message and the connection to the device was lost (no lease was generated as expected in the host file). We manually had to run `dhclient eth0` to get the IP Addr back.
```
Mar 29 10:25:54.446311 r-anaconda-70 INFO dhclient[3544]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
Mar 29 10:25:54.447348 r-anaconda-70 INFO dhclient[3544]: DHCPOFFER of 10.210.24.228 from 10.211.0.124
Mar 29 10:25:54.447477 r-anaconda-70 INFO dhclient[3544]: DHCPREQUEST for 10.210.24.228 on eth0 to 255.255.255.255 port 67
Mar 29 10:25:54.448561 r-anaconda-70 INFO dhclient[3544]: DHCPACK of 10.210.24.228 from 10.211.0.124
...
Mar 29 17:29:53.334129 r-anaconda-70 INFO dhclient[3544]: bound to 10.210.24.228 -- renewal in -23800 seconds.
```
The process though is surprisingly not dead, and it threw this bound to message after we manually ran 'dhclient eth0'. (Looked like it kinda stuck in a loop/deadlock)
The -23800 seconds signifies that the dhclient reached that point way after the lease has expired.
Ref: https://gitlab.isc.org/isc-projects/dhcp/-/blob/master/client/dhclient.c#L1616
```
log_info("bound to %s -- renewal in %ld seconds.",
piaddr(client->active->address),
(long)(client->active->renewal - cur_time));
```
We suspected Dhclient Script Failure could be a reason. (https://gitlab.isc.org/isc-projects/dhcp/-/commit/845c85226e30173982f541fc60bd95747deabbe0) but not entirely sure of it.
This is hard to reproduce but happens every now and then.
Any inputs on why such behavior could arise and any suggestions on how to avoid it are appreciated.
**Environment:**
Version: isc-dhclient-4.4.1 (Not Compiled from source)
**dhclient.conf**
```
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option snmp-community code 224 = text;
option minigraph-url code 225 = text;
option acl-url code 226 = text;
option tftp-server-name code 66 = text;
option bootfile-name code 67 = text;
option user-class code 77 = text;
option provisioning-script-url code 239 = text;
option dhcp6.user-class code 15 = text;
option dhcp6.provisioning-script-url code 239 = text;
option dhcp6.boot-file-url code 59 = text;
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, interface-mtu, dhcp6.fqdn,
rfc3442-classless-static-routes, ntp-servers, log-servers,snmp-community, minigraph-url, acl-url;
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/174Overwriting resolv.conf fails when resolv.conf is a bind mount with dhclient.2022-03-09T18:58:52ZPatrick NorthonOverwriting resolv.conf fails when resolv.conf is a bind mount with dhclient.- ISC DHCP version: 4.4.2
- Tested OS: Arch Linux, Fedora
`resolv.conf` become a bind mount typically inside a network namespace, if a file `/etc/netns/<namespace>/resolv.conf` is present. Running dhclient inside the namespace, it will ...- ISC DHCP version: 4.4.2
- Tested OS: Arch Linux, Fedora
`resolv.conf` become a bind mount typically inside a network namespace, if a file `/etc/netns/<namespace>/resolv.conf` is present. Running dhclient inside the namespace, it will fail to overwrite `resolv.conf`, with error `mv: cannot move '/etc/resolv.conf.dhclient-new' to '/etc/resolv.conf': Device or resource busy`.
Simple fix: Use `cat $new_resolv_conf > /etc/resolv.conf` instead of using `mv` in `client/scripts/linux`.Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/161Sending old_ variables in BOUND callout2022-03-09T18:57:54Zcyrilbur-adderSending old_ variables in BOUND callout---
name: Sending old_ variables in BOUND callout
---
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 s...---
name: Sending old_ variables in BOUND callout
---
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.
I have a patch on github please see here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
If you would be so kind as to allow me to post it here in your gitlab as per https://github.com/isc-projects/dhcp/blob/31e68e5e3b863a4859562e0bb808888d74af7497/CONTRIBUTING.md
**To Reproduce**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Expected behavior**
Everything is outlined in the commit message of the patch here: https://github.com/cyrilbur-adder/dhcp/commit/aa3f4947e3a29f7124cdd3a0c4096f7aac09efe5
**Environment:**
Not really relevant since I have a patch
**Additional Information**
None
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Yes
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
NA
- Are you sure what you would like to do is not possible using some other mechanisms?
No
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
I've emailed the patch to dhcp-workers, no response
**Is your feature request related to a problem? Please describe.**
It is a patch to a likely bug
**Describe the solution you'd like**
Merge the patch
**Describe alternatives you've considered**
None
**Additional context**
None
**Funding its development**
I'm trying to provide you with a patch
**Participating in development**
I'm trying to provide you with a patch
**Contacting you**
Please contact me here or on github.https://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.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/118Failed to start the dhclient2022-03-09T18:56:26ZgaoxingwangFailed to start the dhclientThe dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclien...The dhclient can not start when the pid in dhclient-eth0.pid file is holding by another process which is not a dhclient.
The process name corresponding to the PID is not checked.
I think we should check process name before using dhclient -r to kill the process whose pid is saved in /var/run/dhclient-eth0.pidOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/220If DHCPv6 server is not responding, some times dhcp client process terminates...2022-03-09T18:55:11ZRamesh BendigeriIf DHCPv6 server is not responding, some times dhcp client process terminates with an error 'impossible condition reached'If the DHCPv6 server is not responding, some of times dhcp client process terminates with an error 'impossible condition reached' and results in not releasing/clearing previously acquired DHCP IP address and other DHCP attributes.
This ...If the DHCPv6 server is not responding, some of times dhcp client process terminates with an error 'impossible condition reached' and results in not releasing/clearing previously acquired DHCP IP address and other DHCP attributes.
This issue is seen only when the Dhcp server is not available and Dhcp ip address’s lease is expired at the Dhcp client side.
Some times dhclientv6 process stops with an error “Impossible condition at dhc6.c:318” during rebind time (when rebind interval is reaching zero) and results in not generating Dhcp release event.
This is an issue with ISC DHCP package of IPv6 dhcp client module.
What is expected : Dhcp client should not get terminated during rebind6 event if DHCPv6 server is not available.
Instead dhcp client should **release the ip address** and start with solicit messageOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/93dhclient -6 binds unadvertised address2022-03-09T18:51:22Zjvfranklindhclient -6 binds unadvertised address---
name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both
---
**Describe the bug**
After dhclient -6 releases a leased address, and restarts, it sends a Solicit r...---
name: Dhclient -6 binds unadvertised address
about: If solicited and advertised addresses aren't the same, dhclient binds both
---
**Describe the bug**
After dhclient -6 releases a leased address, and restarts, it sends a Solicit requesting that address again. If the DHCP server decides the client needs a different address (like if the system has switched to a different network, or the address was leased to another client), and includes the different address in the Advertise, dhclient winds up calling dhclient-script BOUND6 for both the old address and the new one. Both addresses get added to the interface.
**To Reproduce**
Steps to reproduce the behavior:
1. Start dhclient -6 with empty dhclient6.leases file. See that it gets an address (AddressA) and configures it to the interface.
2. Run dhclient -6 -r to release it.
3. Either switch the interface to a different network, or change the DHCPv6 server so it will be forced to hand out a different address (AddressB) the next time dhclient runs.
4. Start dhclient -6 again. A packet capture will show the Solicit requesting AddressA.
5. DHCPv6 server responds with Advertise containing AddressB.
6. Client and server complete the transaction with the Request/Reply for AddressB.
7. dhclient-script BOUND6 action will be called twice. First for AddressA, then for AddressB.
**Expected behavior**
AddressA should not be used, since it was not advertised to the client in Step 5 above. The host might no longer be on the network segment where that address is reachable, or the address could already be in use by another host, causing an address conflict.
**Environment:**
- ISC DHCP version: Behavior observed on both isc-dhclient-4.4.1 and isc-dhclient-4.4.2
- OS: CentOS 8.1, Dell iDRAC embedded Linux
- Which features were compiled in:
ISC DHCP source configure results:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Package:
Name: DHCP
Version: 4.4.2
C Compiler: gcc
Flags:
DEFS: -DHAVE_CONFIG_H
CFLAGS: -g -O2 -Wall -Werror -fno-strict-aliasing -I$(top_srcdir)/includes -I/home/user/dhcp-4.4.2/bind/include
DHCP versions: DHCPv4 and DHCPv6
Features:
debug: no
failover: yes
execute: yes
binary-leases: no
dhcpv6: yes
delayed-ack: yes
dhcpv4o6: no
relay-port: no
Developer:
ATF unittests : no
**Additional Information**
[dhclient6.pcap](/uploads/82938f52eef5b382f68333fc81bee040/dhclient6.pcap)
[dhclient6.log](/uploads/e08f84161367366eb905e18a068dce45/dhclient6.log)
**Describe the solution you'd like**
Dhclient should only configure the address that was advertised and requested with the DHCPv6 server.
**Participating in development**
Are you willing to participate in the feature development? Yes
Are you willing to take part in the design discussions? Yes
Are you willing to test an unreleased engineering code? Yes
**Contacting you**
jvfranklin@gmail.com or github account jvfranklinOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/232Sanity Check 4.4.3 rc12022-03-08T13:34:04ZWlodzimierz WencelSanity Check 4.4.3 rc1Let's do some sanity checks :)
```
@repo /data/shared/sweng/dhcp/releases/4.4.3rc1]$ sha256 dhcp-4.4.3.tar.gz
SHA256 (dhcp-4.4.3.tar.gz) = 0e3ec6b4c2a05ec0148874bcd999a66d05518378d77421f607fb0bc9d0135818
```Let's do some sanity checks :)
```
@repo /data/shared/sweng/dhcp/releases/4.4.3rc1]$ sha256 dhcp-4.4.3.tar.gz
SHA256 (dhcp-4.4.3.tar.gz) = 0e3ec6b4c2a05ec0148874bcd999a66d05518378d77421f607fb0bc9d0135818
```4.4.3https://gitlab.isc.org/isc-projects/bind9/-/issues/3196Assertion failures in purge_old_interfaces() during shutdown2022-03-07T20:21:02ZMichał KępieńAssertion failures in purge_old_interfaces() during shutdownDuring pre-release testing of BIND 9.16.27-S1, the `rpzextra` system
test in a single [CI job][1] triggered not one, but two crashes at
shutdown. The `purge_old_interfaces()` function is present in the stack
traces for both of these cra...During pre-release testing of BIND 9.16.27-S1, the `rpzextra` system
test in a single [CI job][1] triggered not one, but two crashes at
shutdown. The `purge_old_interfaces()` function is present in the stack
traces for both of these crashes:
- `bin/tests/system/rpzextra/ns1/core.1251`
<details>
<summary>Click to expand/collapse backtrace</summary>
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007fcccde7e42a in __GI_abort () at abort.c:89
#2 0x000056407fce23d5 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:274
#3 0x00007fccd058592a in isc_assertion_failed (file=file@entry=0x7fccd12bc524 "interfacemgr.c", line=line@entry=652, type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7fccd12bbee0 "(__builtin_expect(!!((ifp) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(ifp))->magic == ((('I') << 24 | (':') << 16 | ('-') << 8 | (')')))), 1))") at assertions.c:48
#4 0x00007fccd12909c7 in purge_old_interfaces (mgr=mgr@entry=0x7fccb8000a00) at interfacemgr.c:652
#5 0x00007fccd12921f8 in ns_interfacemgr_scan0 (verbose=<optimized out>, mgr=0x7fccb8000a00) at interfacemgr.c:1116
#6 ns_interfacemgr_scan (mgr=0x7fccb8000a00, verbose=verbose@entry=false) at interfacemgr.c:1152
#7 0x00007fccd1292319 in route_event (task=<optimized out>, event=<optimized out>) at interfacemgr.c:153
#8 0x00007fccd05b829d in task_run (task=0x564081eeb210) at task.c:851
#9 isc_task_run (task=0x564081eeb210) at task.c:944
#10 0x00007fccd059be15 in isc__nm_async_task (ev0=ev0@entry=0x7fcc6c0008d0, worker=0x5640815a4540) at netmgr.c:873
#11 0x00007fccd05a1948 in process_netievent (worker=worker@entry=0x5640815a4540, ievent=0x7fcc6c0008d0) at netmgr.c:952
#12 0x00007fccd05a1b8e in process_queue (worker=worker@entry=0x5640815a4540, type=type@entry=NETIEVENT_TASK) at netmgr.c:1021
#13 0x00007fccd05a2334 in process_all_queues (worker=0x5640815a4540) at netmgr.c:792
#14 async_cb (handle=0x5640815a48a0) at netmgr.c:821
#15 0x00007fcccf13bf83 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#16 0x00007fcccf13c066 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#17 0x00007fcccf14aee8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#18 0x00007fcccf13c924 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#19 0x00007fccd05a1c2c in nm_thread (worker0=0x5640815a4540) at netmgr.c:727
#20 0x00007fccd05bae66 in isc__trampoline_run (arg=0x564081633aa0) at trampoline.c:198
#21 0x00007fccced144a4 in start_thread (arg=0x7fcccb0e6700) at pthread_create.c:456
#22 0x00007fcccdf32d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
```
</details>
- `bin/tests/system/rpzextra/ns2/core.2254`
<details>
<summary>Click to expand/collapse backtrace</summary>
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007fca9280c42a in __GI_abort () at abort.c:89
#2 0x000055b9d91d53d5 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:274
#3 0x00007fca94f1392a in isc_assertion_failed (file=file@entry=0x7fca95c4a524 "interfacemgr.c", line=line@entry=652, type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7fca95c49ee0 "(__builtin_expect(!!((ifp) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(ifp))->magic == ((('I') << 24 | (':') << 16 | ('-') << 8 | (')')))), 1))") at assertions.c:48
#4 0x00007fca95c1e9c7 in purge_old_interfaces (mgr=mgr@entry=0x7fca7c000a00) at interfacemgr.c:652
#5 0x00007fca95c201f8 in ns_interfacemgr_scan0 (verbose=<optimized out>, mgr=0x7fca7c000a00) at interfacemgr.c:1116
#6 ns_interfacemgr_scan (mgr=0x7fca7c000a00, verbose=verbose@entry=false) at interfacemgr.c:1152
#7 0x00007fca95c20319 in route_event (task=<optimized out>, event=<optimized out>) at interfacemgr.c:153
#8 0x00007fca94f4629d in task_run (task=0x55b9dbc74c40) at task.c:851
#9 isc_task_run (task=0x55b9dbc74c40) at task.c:944
#10 0x00007fca94f29e15 in isc__nm_async_task (ev0=ev0@entry=0x7fca500008d0, worker=0x55b9db32f540) at netmgr.c:873
#11 0x00007fca94f2f948 in process_netievent (worker=worker@entry=0x55b9db32f540, ievent=0x7fca500008d0) at netmgr.c:952
#12 0x00007fca94f2fb8e in process_queue (worker=worker@entry=0x55b9db32f540, type=type@entry=NETIEVENT_TASK) at netmgr.c:1021
#13 0x00007fca94f30334 in process_all_queues (worker=0x55b9db32f540) at netmgr.c:792
#14 async_cb (handle=0x55b9db32f8a0) at netmgr.c:821
#15 0x00007fca93ac9f83 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#16 0x00007fca93aca066 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#17 0x00007fca93ad8ee8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#18 0x00007fca93aca924 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
#19 0x00007fca94f2fc2c in nm_thread (worker0=0x55b9db32f540) at netmgr.c:727
#20 0x00007fca94f48e66 in isc__trampoline_run (arg=0x55b9db3bd650) at trampoline.c:198
#21 0x00007fca936a24a4 in start_thread (arg=0x7fca8fa74700) at pthread_create.c:456
#22 0x00007fca928c0d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
```
</details>
In both cases, the same assertion fails:
```c
644 /*%
645 * Remove any interfaces whose generation number is not the current one.
646 */
647 static void
648 purge_old_interfaces(ns_interfacemgr_t *mgr) {
649 ns_interface_t *ifp, *next;
650 LOCK(&mgr->lock);
651 for (ifp = ISC_LIST_HEAD(mgr->interfaces); ifp != NULL; ifp = next) {
652 >>> INSIST(NS_INTERFACE_VALID(ifp));
653 next = ISC_LIST_NEXT(ifp, link);
654 if (ifp->generation != mgr->generation) {
655 char sabuf[256];
656 ISC_LIST_UNLINK(ifp->mgr->interfaces, ifp, link);
657 isc_sockaddr_format(&ifp->addr, sabuf, sizeof(sabuf));
658 isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_INFO,
659 "no longer listening on %s", sabuf);
660 ns_interface_shutdown(ifp);
661 ns_interface_detach(&ifp);
662 }
663 }
664 UNLOCK(&mgr->lock);
665 }
```
In both cases, `ifp->magic` is 0, but `ifp->references` varies: it is
set to 0 in one case and to 1 in the other.
A quick look at the relevant code suggests that these failures could be
caused by various imperfections in `lib/ns/interface.c`. Specifically,
`purge_old_interfaces()` clearly expects that any `ns_interface_t`
present on the `mgr->interfaces` linked list is a valid interface at all
times; meanwhile, other parts of the code violate that assumption:
1. When a failure occurs in `ns_interface_create()` (e.g. when
`ns_clientmgr_create()` returns `ISC_R_SHUTTINGDOWN`), the error
handling section does not remove `ifp` from `mgr->interfaces` (it
also does not detach from `ifp->mgr`).
2. If the reference count for `ifp` drops to zero,
`ns_interface_destroy()` does not remove `ifp` from
`mgr->interfaces`.
I have not reproduced the exact same crashes locally, but it seems to me
that when a route socket event is processed after one of the above
code paths is taken, nothing good can happen...
As a side note, I would expect the relevant `ns_interface_t` structures
in the core dumps to be `memset()` to `0xde`, but I believe that recent
BIND 9.16.x releases (since !5637) no longer use the internal memory
allocator by default and therefore `ISC_MEMFLAG_FILL` is not set.
I do not think these flaws are exploitable in any way.
[1]: /uploads/890b9b6eb2b18d1f81da47f785370c86/artifacts.zipNot plannedhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/142Overflow in lease time and potentially in renew/rebind of IPv6 client2022-03-07T13:16:09ZChristos ChryssochoidisOverflow in lease time and potentially in renew/rebind of IPv6 client---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6...---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6.c` cause overflow in systems using a **32 bit signed integer for the TIME data type**. As a result dhclient enters an infinite loop since a negative relative expiration time is considered immediately expired.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp server IPv6 with a config containing the following:
```
default-lease-time 4294967294; # or -2
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
```
2. A client solicits a new lease by broadcasting a SOLICIT packet. The above server sends then an ADVERTISE, following by the client sending a REQUEST, and finally the server sending a REPLY.
3. The client then immediately repeats sending a SOLICIT packet.
4. This cycle goes on forever.
**Expected behavior**
After receiving the REPLY packet the client should not repeat sending a SOLICIT packet.
**Environment:**
isc-dhclient-4.1-ESV-R16
- OS: Embedded Linux (**MIPS64n32** architecture)
**Additional Information**
An example config for IPv6 dhcp server is the following:
[dhcpd6-example.conf](/uploads/556d0909d055e86398985aa5abc5ef74/dhcpd6-example.conf)
In the logs I'm seeing the following line:
> PRC: Renewal event scheduled in 3600 seconds, to run for 3600 seconds. PRC: Depreference scheduled in 7200 seconds. PRC: Expiration scheduled in **-2 seconds.**
**Some initial questions**
> - Are you sure your feature is not already implemented in the latest ISC DHCP version?
I've tested it with the latest ESV version of dhclient.
> - Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
It's a client issue, therefore migrating to Kea doesn't seem to provide solution to this problem.
> - Are you sure what you would like to do is not possible using some other mechanisms?
No.
> - Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
No.
**Describe the solution you'd like**
I'm attaching a patch that seems to solve this issue:[dhclient.patch](/uploads/d13a046a05524006b6571e003a35e327/dhclient.patch)
**Context**
Seems to happen when the TIME data type used for lifetime and renew/rebind time calculations is a 32 bit signed integer type.
**Participating in development**
Yes, I am willing to participate in the development.
**Contacting you**
contact email: christos.chryssochoidis@nokia.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/73dhclient not releasing IPv6 address2022-03-07T13:13:08ZGhost Userdhclient not releasing IPv6 address---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclie...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient -6 with regular configuration.
2. Send signal 15 to kill the dhclient process.
3. Observed release of the IP address not happening. The following message only seen from dhclient logs.
`Received signal 15, initiating shutdown.`
**Expected behavior**
As part of signal handling dhclient should call the do_release6 for AF_INET6 family. This will gracefully release IPv6 address and calls the script file also.
Where as, dhclient is gracefully releasing the IPv4 address. We can observe the following logs for the same.
`Received signal 15, initiating shutdown.`
`DHCPRELEASE of <SELF IP ADDRESS> on <INTERFACE NAME> to <DHCP SERVER IP> port 67`
`Killed`
**Environment:**
- ISC DHCP version: isc-dhclient-4.4.1
- OS: Linux CentOS
- Which features were compiled in: dhclient
**Additional Information**
NOT sure this behavior is w.r.to IPv6 architecture only. Would like to make sure not missing things from isc-dhclient side.
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Yes
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration? Don't know
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? NOOutstandinghttps://gitlab.isc.org/isc-projects/bind9-docker/-/issues/2Do not use one RUN command per apt-get and mkdir2022-03-03T11:53:58ZMorgan LindqvistDo not use one RUN command per apt-get and mkdirIn the Dockerfile you are using one RUN command per apt-get and mkdir command that is executed in the image. This is not optimum since each RUN command generates a own layer and the cleanup in the end is very inefficient. Changing to the...In the Dockerfile you are using one RUN command per apt-get and mkdir command that is executed in the image. This is not optimum since each RUN command generates a own layer and the cleanup in the end is very inefficient. Changing to the structure in the attachment reduced the size of the image for me from 267 MB to 193 MB. This is a significant change and is in my mind worth the small change.
I do not have the rights to create a fork and upload a fix. If you agree you can either givve me that access or update based on the attached Dockerfile.
/Morgan[Dockerfile](/uploads/795085bd1a477d5f59b72e04d6496fb0/Dockerfile)https://gitlab.isc.org/isc-projects/stork/-/issues/708Exception thrown in console during demo: missing Arguments in response2022-03-01T14:48:59ZTomek MrugalskiException thrown in console during demo: missing Arguments in responseWhen running a demo, I've encountered the following error:
```
server_1 | INFO[2022-02-09 13:31:48] agentcomm.go:198 connecting to existing agent address="agent-kea-ha2:8080"
server_1 ...When running a demo, I've encountered the following error:
```
server_1 | INFO[2022-02-09 13:31:48] agentcomm.go:198 connecting to existing agent address="agent-kea-ha2:8080"
server_1 | ERRO[2022-02-09 13:31:48] statspuller.go:362 error handling stat-lease4-get response: missing Arguments from Lease Stats response {ResponseHeader:{Result:2 Text:'stat-lease4-get' command not supported. Daemon:dhcp4} Arguments:<nil>}
server_1 | isc.org/stork/server/apps/kea.(*StatsPuller).storeDaemonStats
server_1 | /repo/build-root/backend/server/apps/kea/statspuller.go:203
server_1 | isc.org/stork/server/apps/kea.(*StatsPuller).processAppResponses
server_1 | /repo/build-root/backend/server/apps/kea/statspuller.go:360
server_1 | isc.org/stork/server/apps/kea.(*StatsPuller).getStatsFromApp
server_1 | /repo/build-root/backend/server/apps/kea/statspuller.go:334
server_1 | isc.org/stork/server/apps/kea.(*StatsPuller).pullStats
server_1 | /repo/build-root/backend/server/apps/kea/statspuller.go:61
server_1 | isc.org/stork/util.(*PeriodicExecutor).executorLoop
server_1 | /repo/build-root/backend/util/periodicexecutor.go:166
server_1 | runtime.goexit
server_1 | /repo/build-root/tools/1.17.5/go/src/runtime/asm_amd64.s:1581
server_1 | INFO[2022-02-09 13:31:48] agentcomm.go:198 connecting to existing agent address="agent-kea-ha2:8080"
```
This is caused by the agent-ha2 not having stats-cmd hook loaded. That's fine and it's actually a good test case. However, the code should not throw. It should check if the status is non-zero and then print the error message returned in the console, preferably on a warning level.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/694Traffic generator - missing client-class in some subnets2022-03-01T14:25:53ZSlawek FigielTraffic generator - missing client-class in some subnetsThe issue was found during 1.1.0 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/685#note_264710)
Another small thing: in the demo, the traffic generator is not able to start traffic for 192.0.3.0/24 network. ...The issue was found during 1.1.0 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/685#note_264710)
Another small thing: in the demo, the traffic generator is not able to start traffic for 192.0.3.0/24 network. When I click Start, it doesn't turn into Stop button.
The browser console shows 500 internal server error, when doing `PUT http://localhost:5000/subnets/9`. Digging a bit deeper, you can see this in this response.
Looks like a missing class entry in the config. But the sim should probably be made more robust to handling missing client-class.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/692Controls overlap the event toasts2022-03-01T14:24:31ZSlawek FigielControls overlap the event toastsThe issue was found during 1.1.0 sanity checks.
[Source](https://gitlab.isc.org/isc-projects/stork/-/issues/685#note_264663)
Started demo, went to machines page and authenticated several machines quickly. Initially the messages were hov...The issue was found during 1.1.0 sanity checks.
[Source](https://gitlab.isc.org/isc-projects/stork/-/issues/685#note_264663)
Started demo, went to machines page and authenticated several machines quickly. Initially the messages were hovering on top (with the Authorized/unathorized underneath), but then the buttons came on top.
It's not a big deal, just looked weird.backlog