dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2021-03-04T17:11:02Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/166Is it feasible to make --enable-use-sockets a runtime configuration setting?2021-03-04T17:11:02ZHazael SanchezIs it feasible to make --enable-use-sockets a runtime configuration setting?From https://kb.isc.org/docs/aa-00379:
> You can compile raw socket behaviour out, and it may sometimes be advisable for performance and simplicity reasons, but administrators should understand the limitation that the DHCP server will n...From https://kb.isc.org/docs/aa-00379:
> You can compile raw socket behaviour out, and it may sometimes be advisable for performance and simplicity reasons, but administrators should understand the limitation that the DHCP server will no longer be able to send unicast replies to clients on the same broadcast domain as the DHCP server.
While enabling this flag by default is certainly the Wrong Thing (TM) I don't believe there's a fundamental reason why this behavior should be set at compile time as opposed to at startup. Having a configuration knob for it simplifies distribution in "interesting" setups where both behaviors are needed.
Unpopular opinion: Having fewer `IFDEF` guards is also a win.https://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/dhcp/-/issues/74please enhance DHCP logging for "peer holds all free leases"2020-07-03T08:13:17Zssbertilsonplease enhance DHCP logging for "peer holds all free leases"---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Not in 4.4.2b1
- Are you sure your feature is not a...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
Not in 4.4.2b1
- Are you sure your feature is not already implemented in the latest Kea version?
Can't easily tell (message not similar enough to quickly find)
- 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 or dhcp-workers mailing lists?
No since it is such a trivial change
**Describe the solution you'd like**
In server/dhcp.c I'd like to see this change:
--- dhcp.c.orig 2019-12-17 13:13:31.000000000 -0600
+++ - 2020-01-09 08:50:16.350350969 -0600
@@ -391,18 +391,19 @@
#endif
/* If we didn't find a lease, try to allocate one... */
if (!lease) {
if (!allocate_lease (&lease, packet,
packet -> shared_network -> pools,
&peer_has_leases)) {
if (peer_has_leases)
- log_error ("%s: peer holds all free leases",
- msgbuf);
+ log_error ("%s: network %s: peer holds all free leases",
+ msgbuf,
+ packet -> shared_network -> name);
else
log_error ("%s: network %s: no free leases",
msgbuf,
packet -> shared_network -> name);
return;
}
}https://gitlab.isc.org/isc-projects/dhcp/-/issues/31ISC DHCP log_fatal aborts while using Failover function2020-07-03T08:23:19ZGhost UserISC DHCP log_fatal aborts while using Failover functionISC DHCP log_fatal aborts were seen in two scenarios while using the failover function. There was a WAN simulator in the testbed across the DHCP failover peers which simulates WAN like latencies/drops on packet exchanges across the Failo...ISC DHCP log_fatal aborts were seen in two scenarios while using the failover function. There was a WAN simulator in the testbed across the DHCP failover peers which simulates WAN like latencies/drops on packet exchanges across the Failover peers
The following scenarios log_fatal were hit
1. dhcpd[21099]: <299801> <21099> <DBUG> |dhcpd| Peer failover-partner: Invalid attempt to move from potential-conflict to communications-interrupted while local state is conflict-done.
2. dhcpd[29438]: <299801> <29438> <DBUG> |dhcpd| Peer failover-partner: Invalid attempt to move from communications-interrupted to communications-interrupted while local state is conflict-done.
```
#0 0x2ae2e774 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1 0x2ae302c0 in abort () at abort.c:92
#2 0x2ae2687c in __assert_fail (assertion=0x4be094 "0", file=0x4c5184 "dhcpd.c", line=234, function=0x4c5128 "exit_handler") at assert.c:81
#3 0x00460eec in exit_handler () at dhcpd.c:234
#4 0x2ae31d78 in __run_exit_handlers (status=1, listp=0x2af63354, run_list_atexit=true) at exit.c:78
#5 0x2ae31dc0 in exit (status=29438) at exit.c:100
#6 0x004a7424 in log_fatal (fmt=<value optimized out>) at omapip/errwarn.c:102
#7 0x00425594 in dhcp_failover_peer_state_changed (state=0x57131c, msg=<value optimized out>) at failover.c:2202
#8 0x004242bc in dhcp_failover_state_signal (o=0x57131c, name=<value optimized out>, ap=0x6) at failover.c:1468
#9 0x0042390c in dhcp_failover_listener_signal (o=0x576484, name=0x4cc8d8 "message", ap=<value optimized out>) at failover.c:1087
#10 0x004ac0ec in omapi_signal (handle=<value optimized out>, name=0x72fe <Address 0x72fe out of bounds>) at omapip/support.c:281
#11 0x004227c4 in dhcp_failover_link_signal (h=0x5b3824, name=<value optimized out>, ap=<value optimized out>) at failover.c:594
#12 0x004ac0ec in omapi_signal (handle=<value optimized out>, name=0x72fe <Address 0x72fe out of bounds>) at omapip/support.c:281
#13 0x0049faa4 in omapi_connection_reader (h=<value optimized out>) at omapip/buffer.c:259
#14 0x004a1a00 in omapi_one_dispatch (wo=<value optimized out>, t=0x7fbf78e0) at omapip/dispatch.c:514
#15 0x0043223c in dispatch () at dispatch.c:92
#16 0x00462da4 in main (argc=<value optimized out>, argv=<value optimized out>) at dhcpd.c:1555
```
Steps to reproduce the behavior:
1. Run DHCP server across 2 failover peers
2. Have a WAN simulator between the failover peers
**Environment:**
- OS: Linux kernel version 2.6.32
- ISC version dhcpd-4.1-ESV-R12-P1
Email: isaactheogaraj@h=gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/24ISC DHCP crash while using failover function2020-07-03T08:23:53ZGhost UserISC DHCP crash while using failover functionI hit a crash in ISC dhcpd while using the failover function. It appears to be a double free error and happens when the connectivity to peer is broken. (crash signature is attached below)
Please review and share if this is seen before.
D...I hit a crash in ISC dhcpd while using the failover function. It appears to be a double free error and happens when the connectivity to peer is broken. (crash signature is attached below)
Please review and share if this is seen before.
Do you need more information from the system/configuration perspective?
Apparently this is happening on a error scenario of select returning failure in omapi_one_dispatch()
394 /* poll once */
395 count = select(max + 1, &r, &w, &x, &now); >>>> (count < 0)
Also, I would like to know whether ISC has a paid support scheme wherein individuals or corporates get expedited support from ISC.
Thanks,
Isaac.
p.s.
<Crash signature>
```
* #0 0x2ae2e774 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
* #1 0x2ae302c0 in abort () at abort.c:92
* #2 0x2ae6cb50 in __libc_message (do_abort=<value optimized out>, fmt=0x2af439c0 "*** glibc detected *** %s: %s: 0x%s ***\n") \nat ../sysdeps/unix/sysv/linux/libc_fatal.c:186
* #3 0x2ae73ebc in malloc_printerr (action=3, str=0x2af43c6c "double free or corruption (!prev)", ptr=<value optimized out>) at malloc.c:6267
* #4 0x2ae79d64 in __libc_free (mem=<value optimized out>) at malloc.c:3739
* #5 0x2add1ea8 in mm_chunk_free (handle=<value optimized out>, chunk=0x26d3, caller=<value optimized out>) at mm_chunk.c:186
* #6 0x2add17d8 in mm_free (h=0x528008, ptr=<value optimized out>, caller=<value optimized out>) at mm_main.c:222
* #7 0x0049edf0 in omapi_object_dereference (h=0x7feac178, file=0x4cc2ac "omapip/dispatch.c", line=476) at omapip/alloc.c:695
* #8 0x004a1d30 in omapi_one_dispatch (wo=<value optimized out>, t=0x7feac500) at omapip/dispatch.c:476
* #9 0x0043223c in dispatch () at dispatch.c:92
* #10 0x00462da4 in main (argc=<value optimized out>, argv=<value optimized out>) at dhcpd.c:1555
```
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcpd with 5 /24 pools and failover function to one peer
2. Connectivity among the peer goes off
3. The server then crashed
**Environment:**
- ISC DHCP version: which release? dhcpd-4.1-ESV-R12-P1
- OS: [e.g. Ubuntu 16.04 x64] Kernel 2.6.32
**Funding its development**
Is there a paid support contract option with ISC?
**Contacting you**
Email: isaactheogaraj@gmail.comOutstanding