dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2021-06-10T16:12:44Zhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/121ISC-DHCP-Server appears abandoned on Ubuntu focal2021-06-10T16:12:44ZAndrew WelhamISC-DHCP-Server appears abandoned on Ubuntu focalIs the ISC-DHCP-Server for Ubuntu 20.04 abandoned ?
The reason for asking is there appear to be no updates since April 2020, and there are critical issues for example you can't launch ISC-DHCP in a cluster on Focal 20.04.
There are al...Is the ISC-DHCP-Server for Ubuntu 20.04 abandoned ?
The reason for asking is there appear to be no updates since April 2020, and there are critical issues for example you can't launch ISC-DHCP in a cluster on Focal 20.04.
There are also lots of reports left in undecided, with no activity that i can see of.
for example
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118
I've email the maintainer and no response.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/88Bug in dhcpd with ipv6 and network interface aliases2021-08-24T14:28:14ZGhost UserBug in dhcpd with ipv6 and network interface aliases
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor bec...
Hi
We have detected a problem when using dhcpdv6 when there are messages received from an IPv6 interface (eth0) which has an interface alias (eth0:0) [1]. dhcpd tries to answer using the alias and fails with a bad file descriptor because eth0 and eth0:0 have the same interface index, so the following patch ignores interfaces with invalid write file descriptors.
Cheers
Alejandro.
[1]
```
# ifconfig
eth0 Link encap:Ethernet HWaddr A
inet addr:B Bcast:C Mask:255.255.255.0
inet6 addr: D/64 Scope:Global
inet6 addr: D/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7182898 errors:0 dropped:22 overruns:0 frame:0
TX packets:4863373 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3551746525 (3.5 GB) TX bytes:4883184122 (4.8 GB)
eth0:0 Link encap:Ethernet HWaddr A
inet addr:E Bcast:F Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
```
**To Reproduce**
1. Run dhcpd with a ip pool in eth0 in ipv6 and a interface alias eth0:0
```
/usr/sbin/dhcpd -d -6 -user dhcpd -group dhcpd -cf /etc/dhcp/dhcpd6.conf --no-pid
```
2. A client does a IPv6 request and doesn't gets an answer.
3. The server doesn't answer.
4. See error
```
Sending Relay-reply to XX::XX port 547
send_packet6: Bad file descriptor
dhcpv6: send_packet6() sent -1 of 239 bytes
```
**Expected behavior**
The server is supposed to send back packet A with address B assigned.
**Environment:**
- ISC DHCP version: isc-dhcpd-4.4.1
- OS: Debian buster
**Additional Information**
gdb shows that ```if_nametoindex(ip->name)``` is equal for eth0 and eth0:0. But eth0:0 does not have a valid file descriptor.
[patch.patch](/uploads/b4773b08980a36cfc4d7a40a3d0b23d5/patch.patch)4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/215Set agent address when using dhcp-relay.2022-01-30T13:31:15ZsliddjurSet agent address when using dhcp-relay.---
name: add agent-address option
about: set the agent-address when using dhcp-relay
---
**Is your feature request related to a problem? Please describe.**
When you have two IP-addresses on an interface, on different subnets, but onl...---
name: add agent-address option
about: set the agent-address when using dhcp-relay
---
**Is your feature request related to a problem? Please describe.**
When you have two IP-addresses on an interface, on different subnets, but only want the relay-agent to use a specific address in the `relay-agent-ip-address` field. The agent uses the "wrong" agent address, and no such subnet scope is configured on the dhcp-server. Meaning the dhcp-server will not find a valid scope to response to.
I am using VyOS routers which uses isc-project.
One such situation is when using VRRP, and having the VIP in another subnet to save IP-addresses. Also, when using non-rfc3768-compliant setup, the VIP is on the same interface as the physical IP.
**Describe the solution you'd like**
An option that could specify the agent-address instead of/or the agent-interface.
**Describe alternatives you've considered**
I have found no solutions.
**Additional context**
Add any other context about the feature request here.
**Contacting you**
You can send me a message here.https://gitlab.isc.org/isc-projects/dhcp/-/issues/211Preload oui.txt in dhcp-lease-list-pl for significantly improved runtimes2022-01-28T19:32:27ZbretgiddingsPreload oui.txt in dhcp-lease-list-pl for significantly improved runtimesThe current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve pe...The current dhcp-lease-list.pl script uses grep to lookup oui's. If you are reading oui's for more than 1 lease, it is more than likely that pre-loading the file into a perl hash keyed on the first three octets of the mac will improve performance. Simple tests show that doing this with 50 valid leases will be 5 times faster. For 1000 leases, the speedup is of the order of 100 time faster - indeed, with the hashed file, 1000 leases is still significantly faster than 50 leases without the hashed data.4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/177DHCPOFFER is not sent out after a DCHPDISCOVER2023-10-09T21:28:22ZFredrik BlixDHCPOFFER is not sent out after a DCHPDISCOVERI have had a couple of incidents where the DHCPOFFER is not sent byt the DCHP-server. I have made some troubleshooting for this.
The actual set-up is one computer (tablet) that is connecting using ethernet to a computer hosting a DCHP-s...I have had a couple of incidents where the DHCPOFFER is not sent byt the DCHP-server. I have made some troubleshooting for this.
The actual set-up is one computer (tablet) that is connecting using ethernet to a computer hosting a DCHP-server. The configuration is not anything special.
- Software: **Internet Systems Consortium DHCP Server 4.4.1**
- [/etc/dhcp/dhcp-server](/uploads/845fea65189dcc4de9dd0ad903c96efb/dhcp-server)
- [/etc/dhcp/dhcpd.conf](/uploads/eeb8d49029fd1aca6533603a9741d1fe/dhcpd.conf)
- [/lib/systemd/system/dhcpd.service](/uploads/fdf276f374e06df3ec6cc1d9fb6d8f65/dhcpd.service)
In this specific case the logs starts at 09:14:10. At this point the tablet did not have any ip-adress and after re-plugging the ethenet dongle for the tablet the tablet start sending out the DHCPDISCOVER package. I would expect that the DHCP sever then would respond with DHCPOFFER, but nothing seems to happens. **At 09:15:50 i restart the DHCP-server and then the DCHP handshaking is successful.**
_Note: I changed the dhcpd.service `After=network.target` to `After=network-online.target`. This i made since this is an embedded system that want to start quickly. The `After=network.target` does not guarantee that the network devices are actually online. So, before this change the DCHP-server sometimes was started befort the `eth0` was up. [[Running Services After the Network is up](https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/)]_
_Note: The tcpdump was made on the same computer running the dhcpd._
### TCPDUMP of the problem
```
# tcpdump -vnes0 -i eth0 -vvv -s 0 port 67 or port 68
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:14:10.072207 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:14:11.054104 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:14:13.167741 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 3, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:14:17.271799 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 7, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:14:24.978766 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 14, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:14:39.545719 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 29, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:15:08.884878 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 58, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
```
### TCPDUMP after the restart
```
09:16:10.107290 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 348: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 334)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 306, xid 0xa57ed7f4, secs 119, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:16:11.108417 b8:27:eb:a7:92:ec > 00:05:1b:d5:20:60, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
10.42.102.2.67 > 10.42.102.150.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa57ed7f4, secs 119, Flags [none] (0x0000)
Your-IP 10.42.102.150
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.42.102.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 10.42.102.2
Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
Domain-Name Option 15, length 17: "domain.thoreb.com"
END Option 255, length 0
PAD Option 0, length 0, occurs 3
09:16:11.156340 00:05:1b:d5:20:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 360: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 346)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:05:1b:d5:20:60, length 318, xid 0xa57ed7f4, secs 121, Flags [none] (0x0000)
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 00:05:1b:d5:20:60
Requested-IP Option 50, length 4: 10.42.102.150
Server-ID Option 54, length 4: 10.42.102.2
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 15: "android-dhcp-10"
Hostname Option 12, length 18: "Galaxy-Tab-Active3"
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
MTU, BR, Lease-Time, RN
RB, Vendor-Option
END Option 255, length 0
09:16:11.156993 b8:27:eb:a7:92:ec > 00:05:1b:d5:20:60, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
10.42.102.2.67 > 10.42.102.150.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa57ed7f4, secs 121, Flags [none] (0x0000)
Your-IP 10.42.102.150
Client-Ethernet-Address 00:05:1b:d5:20:60
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.42.102.2
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 10.42.102.2
Domain-Name-Server Option 6, length 8: 8.8.8.8,8.8.4.4
Domain-Name Option 15, length 17: "domain.thoreb.com"
END Option 255, length 0
PAD Option 0, length 0, occurs 3
```
### Log from the dhcpd server
```
# journalctl -u dhcpd -f
-- Logs begin at Fri 2020-03-27 08:04:30 UTC. --
Mar 29 08:21:46 U1CB2-postbus systemd[1]: Starting DHCPv4 Server Daemon...
Mar 29 08:21:46 U1CB2-postbus systemd[1]: Started DHCPv4 Server Daemon.
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: Internet Systems Consortium DHCP Server 4.4.1
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: Copyright 2004-2018 Internet Systems Consortium.
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: All rights reserved.
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: For info, please visit https://www.isc.org/software/dhcp/
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: Wrote 0 leases to leases file.
Mar 29 08:21:46 U1CB2-postbus dhcpd[515]: Server starting service.
Mar 29 09:15:50 U1CB2-postbus dhcpd[515]: Received signal 15, initiating shutdown.
Mar 29 09:15:50 U1CB2-postbus systemd[1]: Stopping DHCPv4 Server Daemon...
Mar 29 09:15:50 U1CB2-postbus systemd[1]: dhcpd.service: Succeeded.
Mar 29 09:15:50 U1CB2-postbus systemd[1]: Stopped DHCPv4 Server Daemon.
Mar 29 09:15:50 U1CB2-postbus systemd[1]: Starting DHCPv4 Server Daemon...
Mar 29 09:15:50 U1CB2-postbus systemd[1]: Started DHCPv4 Server Daemon.
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: Internet Systems Consortium DHCP Server 4.4.1
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: Copyright 2004-2018 Internet Systems Consortium.
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: All rights reserved.
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: For info, please visit https://www.isc.org/software/dhcp/
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: Wrote 0 leases to leases file.
Mar 29 09:15:50 U1CB2-postbus dhcpd[5866]: Server starting service.
Mar 29 09:16:10 U1CB2-postbus dhcpd[5866]: DHCPDISCOVER from 00:05:1b:d5:20:60 via eth0
Mar 29 09:16:11 U1CB2-postbus dhcpd[5866]: DHCPOFFER on 10.42.102.150 to 00:05:1b:d5:20:60 (Galaxy-Tab-Active3) via eth0
Mar 29 09:16:11 U1CB2-postbus dhcpd[5866]: DHCPREQUEST for 10.42.102.150 (10.42.102.2) from 00:05:1b:d5:20:60 (Galaxy-Tab-Active3) via eth0
Mar 29 09:16:11 U1CB2-postbus dhcpd[5866]: DHCPACK on 10.42.102.150 to 00:05:1b:d5:20:60 (Galaxy-Tab-Active3) via eth0
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/176fixed-address ips not listed in dhcp.leases file2022-01-13T11:46:50ZSrivathsa Sarangapanifixed-address ips not listed in dhcp.leases file---
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**
I have the below config in dhcpd.conf file
host srivathsas-ubua {
hardware ethernet 00:0C:29:71:6F:AA;
fixed-address 10.19.184.50;
}
I dont know how to verify if the host srivathsas-ubua is allocated an ip or not from the server.
Only when I login to client, I know it has been allocated the IP. But from server how do i know whether the client requested and did server successfully allocated the ip?
**To Reproduce**
Steps to reproduce the behavior:
1. Configure dhcpd.conf as below :
authoritative;
subnet 10.19.184.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 10.19.184.255;
pool {
range 10.19.184.100 10.19.184.110;
}
default-lease-time 3600;
max-lease-time 3600;
}
host srivathsas-ubua {
hardware ethernet 00:0C:29:71:6F:AA;
fixed-address 10.19.184.50;
}
2. On client, run : dhclient -d -v ens192
3. dhcpd does allocate 10.19.184.50 ip to the client.
4. But this is not recorded in lease file.
**Expected behavior**
An entry in dhcpd.lease file with possibly all times as 0
**Environment:**
- ISC DHCP version: 4.4.1
- OS: Yocto
- Which features were compiled in
**Contacting you**
please contact me on srivathsa.sarangapani@hpe.comhttps://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/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/dhcp/-/issues/163More detailed logging for DHCPv6-PD operations2022-12-27T12:26:06ZMathieu PoussinMore detailed logging for DHCPv6-PD operations---
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? Yes
- Are you sure your feature is not already imp...---
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? Yes
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration? N/R
- 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
**Is your feature request related to a problem? Please describe.**
Currently, we have some tools taking action from the data in the logs of ISC-DHCP, we have some tools that required the line to contain information about the peer IP and the link address, we had to fork the original isc-dhcp to modify the related log_info line to show the related data.
We have the following like generated
```
Reply PD: address 2001:bc8:xxxx:xxx::/56 to client with duid 00:03:00:01:43:69:26:64:49:b2 iaid = -1578006392 static, peer = fe80::e42:a1ff:fef1:8888, link = 2001:bc8:xxxx:x::1
```
Instead of
```
Reply PD: address 2001:bc8:xxxx:xxx::/56 to client with duid 00:03:00:01:43:69:26:64:49:b2 iaid = -1578006392 static
```
**Describe the solution you'd like**
The corresponding `log_info` line in `server/dhcpv6.c` should be updated to add the information
**Describe alternatives you've considered**
Forking it and maintaining it like we do. Rewriting a dhcpv6 implementation from scratch (we don't need any other feature in our case)
**Additional context**
N/R
**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 am not the one who can decide that for the company unfortunately
**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?
We already have a working implementation that we can pass to your thru MR. (it's just a few lines in a single file)
**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.
Email is finehttps://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 " (")
---
**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/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/135Virtual interface support2020-11-12T20:43:18ZFrederic BorVirtual interface support---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a rem...---
name: Virtual interface support
about: with the rise of VTI IPsec usage, there is a need for virtual interface support in dhcp relay.
---
**Is your feature request related to a problem? Please describe.**
I would like to use a remote dhcp server and relay request to it threw VTI interfaces.
**Describe the solution you'd like**
I'd like to have support for virtual interfaces so I can relay dhcp requests threw them.
**Describe alternatives you've considered**
The only alternative when using VTI is to have a local dhcp server, instead of a remote one. But when you start to have some small remote sites, it's a lot less convenient than simply activate dhcp relay and setting up the ip of the remote server.
**Additional context**
The attached patch is implementing this for IFT_TUNNEL interface type.
I had some trouble with BPF, getting the whole packet. I was only having the first 67 bytes. I'm not sure why. It was working correctly in a small POC code environnement but not within dhcrelay. I managed do get it works by adding a "load (uint)(-1) into the accumulator" instruction before returning the packet.
We are using this patch in production since march on a dozen of firewalls, it's working well. It's untested except on pfSense/FreeBSD.
**Participating in development**
I am willing to participate in the feature development, discusions, tests.
I will see how to do this on linux.
Could I have a project allocation to this intent ?
**Contacting you**
Here is nice, or github.
[vti_support.patch](/uploads/0d96555a7ae7eec4a4c537079f364c28/vti_support.patch)4.5.0-betahttps://gitlab.isc.org/isc-projects/dhcp/-/issues/133can't update object: permission denied2022-01-13T11:24:53ZRamesh Sahoocan't update object: permission deniedTrying to delete a lease from the DHCP server with the following procedure and ending up with the following message.
can't update object: permission denied
```
# omshell
> connect
obj: <null>
> new lease
obj: lease
> set ip-address =...Trying to delete a lease from the DHCP server with the following procedure and ending up with the following message.
can't update object: permission denied
```
# omshell
> connect
obj: <null>
> new lease
obj: lease
> set ip-address = 192.168.6.20
obj: lease
ip-address = c0:a8:06:14
> open
obj: lease
ip-address = c0:a8:06:14
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
> unset ip-address
obj: lease
ip-address = <null>
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
> update
can't update object: permission denied
obj: lease
ip-address = <null>
state = 00:00:00:02
client-hostname = "rhel7-c1"
subnet = 00:00:00:02
pool = 00:00:00:03
hardware-address = 08:00:27:a5:22:0a
hardware-type = 00:00:00:01
ends = 5f:4d:8a:81
starts = 5f:4d:1a:01
tstp = 00:00:00:00
tsfp = 00:00:00:00
atsfp = 00:00:00:00
cltt = 5f:4d:1a:01
flags = 00
```
```
# dhcpd --version
isc-dhcpd-4.2.5
```Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/129Subnet parameters should be overridable per-host2022-01-13T11:20:30ZPhilip PrindevilleSubnet parameters should be overridable per-host---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-tim...---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-time 3600;
max-lease-time 86400;
option domain-name "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.128 192.168.1.254;
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.1;
option domain-name-servers 192.168.1.1;
option ntp-servers 192.168.1.40;
}
...
# and a bunch of static allocations in as "host" reservations
host switch {
hardware ethernet 00:01:02:03:04:05;
fixed-address 192.168.1.2;
option host-name "switch";
}
...
# and an alarm system that should never have a default-route
host alarm {
hardware ethernet 00:01:02:0a:0b:0c;
fixed-address 192.168.1.8;
option host-name "alarm";
option routers none;
}
```
In this case, it's easier to default all of the hosts as getting a default-route, except for one where that isn't the case and call that out explicitly.
In the special case of IPv4 routers, you can set it to "0.0.0.0" and an ISC-DHCP client will reject this value, but the same is not true of many other DHCP clients, including the built-in one in NetworkManager, and indeed this should be handled server-side anyway ("Be conservative in what you send...").
**Prior Discussion**
This has been brought up on the `#isc-dhcp` IRC channel as well as the `dhcp-workers` mailing list.
**Limitations/Genesis**
If I have a subnet with 250 hosts, 249 of which should receive a default route, and 1 of which shouldn't, I shouldn't have to write 250 `host` definitions... and if I'm using dynamic allocations, this isn't even possible. Configuration should be powerful, simple, and easy.
**Desired Solution**
Be able to override subnet defaults on a per-host basis.
**Alternatives**
There really aren't any. Even if I were to use classes as a shorthand, I'd still need to default all hosts on my network.
**Additional context**
None
**Funding its development**
See below.
**Participating in development**
I'd be willing to drive the development of this feature and do most of it myself, but I might need some guidance navigating the code base as I'm not well-versed in it.
**Contacting you**
Comments on this issue, or as `philipp@redfish-solutions.com` via email, or as `philipp64` on IRC (`freenode.org`).https://gitlab.isc.org/isc-projects/dhcp/-/issues/128DHCP cluster crashes after a few hours2022-01-13T11:24:31ZRichard LaagerDHCP cluster crashes after a few hours**Describe the bug**
When running a cluster using dhcpd 4.4.1 or 4.4.2, at least with Ubuntu patches, dhcpd crashes after a few hours.
Here are two instances of the crash with the packaged 4.4.1 from Ubuntu 20.04:
```
2020-07-31T06:28:...**Describe the bug**
When running a cluster using dhcpd 4.4.1 or 4.4.2, at least with Ubuntu patches, dhcpd crashes after a few hours.
Here are two instances of the crash with the packaged 4.4.1 from Ubuntu 20.04:
```
2020-07-31T06:28:28.138646-05:00 salmon sh[764]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace
2020-07-31T06:28:28.138704-05:00 salmon sh[764]: #0 0x7fdd3f4b4a4a in ??
2020-07-31T06:28:28.138768-05:00 salmon sh[764]: #1 0x7fdd3f4b4980 in ??
2020-07-31T06:28:28.138809-05:00 salmon sh[764]: #2 0x7fdd3f4f07e1 in ??
2020-07-31T06:28:28.138849-05:00 salmon sh[764]: #3 0x7fdd3f297609 in ??
2020-07-31T06:28:28.138887-05:00 salmon sh[764]: #4 0x7fdd3f3d3103 in ??
2020-07-31T07:02:54.013649-05:00 salmon sh[32432]: ../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, back trace
2020-07-31T07:02:54.013674-05:00 salmon sh[32432]: #0 0x7fb12a7e0a4a in ??
2020-07-31T07:02:54.013693-05:00 salmon sh[32432]: #1 0x7fb12a7e0980 in ??
2020-07-31T07:02:54.013711-05:00 salmon sh[32432]: #2 0x7fb12a81c7e1 in ??
2020-07-31T07:02:54.013728-05:00 salmon sh[32432]: #3 0x7fb12a5c3609 in ??
2020-07-31T07:02:54.013753-05:00 salmon sh[32432]: #4 0x7fb12a6ff103 in ??
```
**To Reproduce**
At this point, I'm not certain that it has to be a cluster configuration, but everyone reporting it (including me) seems to be running a cluster.
It's also not clear how much configuration is relevant either.
For me, it crashes within a couple of hours on the secondary system.
**Expected behavior**
dhcpd does not crash.
**Environment:**
- ISC DHCP version: 4.4.1 as packaged by Ubuntu (4.4.1-2.1ubuntu5) or 4.4.2 with the same Ubuntu patches as 4.4.1-2.1ubuntu5
- OS: Ubuntu 20.04 x64
The version from 18.04, 4.3.5-3ubuntu7.1, is fine.
**Additional Information**
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118
and before that
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1870729
I am not the original reporter of either of those.
**Some initial questions**
**Contacting you**
Here is fine, or the Ubuntu bug, or rlaager@wiktel.com by email or XMPP. BTW, this item on the template references github, but you're now running your own GitLab instance, so that's probably old.4.5.0-betahttps://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/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/70Add new option type 'k' to parse_option_code_definition2020-07-03T08:19:08ZThomas MarkwalderAdd new option type 'k' to parse_option_code_definition#68 added new option format type 'k', this could be made available to users for custom options.#68 added new option format type 'k', this could be made available to users for custom options.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.comOutstanding