dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2022-03-09T19:00:29Zhttps://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/201DHCP acknowledges dhcprequest after client has been moved to another VLAN2021-08-12T03:47:06ZRoman EkjanovDHCP acknowledges dhcprequest after client has been moved to another VLANisc-dhcp-server on Ubuntu 18.04.05, version 4.3.5-3ubuntu7.3
Server network configuration:
```
...
3: p2p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1b:21:53:81:ce brd...isc-dhcp-server on Ubuntu 18.04.05, version 4.3.5-3ubuntu7.3
Server network configuration:
```
...
3: p2p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1b:21:53:81:ce brd ff:ff:ff:ff:ff:ff
inet 10.100.0.2/16 brd 10.100.255.255 scope global p2p1
valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:fe53:81ce/64 scope link
valid_lft forever preferred_lft forever
...
8: vlan5@p2p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:1b:21:53:81:ce brd ff:ff:ff:ff:ff:ff promiscuity 0
vlan protocol 802.1Q id 5 <REORDER_HDR> numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
inet 10.0.1.80/16 brd 10.0.255.255 scope global main
valid_lft forever preferred_lft forever
inet6 fe80::21b:21ff:fe53:81ce/64 scope link
valid_lft forever preferred_lft forever
```
i.e. interface with the main address and multiple vlans
dhcpd.conf excerpts:
```
shared-network Main {
subnet 10.100.0.0 netmask 255.255.0.0 {
range 10.100.2.0 10.100.5.255;
}
}
shared-network Vlan5 {
subnet 10.0.0.0 netmask 255.255.0.0 {
range 10.0.2.0 10.0.5.255;
}
}
```
Both client and server are connected to the same managed switch, which has all vlans configured.
Initially, the client was on Main network and was assigned ip address 10.100.2.61. Then, on the switch, it was moved to vlan 5 network. Now it is sending DHCPREQUEST for 10.100.2.61 via vlan5 interface, and the server happily acknowledges the address, without paying attention that the request comes via the interface which is configured with a different subnet.
```
Aug 11 20:36:50 server dhcpd[19640]: DHCPREQUEST for 10.100.2.61 from bc:ee:7b:77:1d:2f (roma) via vlan5
Aug 11 20:36:50 server dhcpd[19640]: DHCPACK on 10.100.2.61 to bc:ee:7b:77:1d:2f (roma) via vlan5
```
Naturally, the client's host is not reachable anymore and there is no obvious way how to force it to drop the old address. Client, server and switch are all physically inaccessible.
Maybe related to #109https://gitlab.isc.org/isc-projects/dhcp/-/issues/199Verify that random calls are seeded and used appropriately2022-01-13T11:08:57ZPeter DaviesVerify that random calls are seeded and used appropriatelyVerify that random calls are seeded and used appropriately
The Google Compute Platform randomization attack is a good reminder that we should examine PRNG use dhcp server and relay to ensure that we are using (pseudo-)randomness appro...Verify that random calls are seeded and used appropriately
The Google Compute Platform randomization attack is a good reminder that we should examine PRNG use dhcp server and relay to ensure that we are using (pseudo-)randomness appropriately.
Please treat this ticket as:
a reminder to review PRNG use in your project to ensure that it is used properly
a request to report on the status of that review, so that users who search for this ticket can satisfy themselves that we have checked our usage and believe it to be reasonable
The Google Compute Platform randomization attack in dhclient publicly available here: [https://github.com/irsl/gcp-dhcp-takeover-code-exec.](https://github.com/irsl/gcp-dhcp-takeover-code-exec).
also: [https://gitlab.isc.org/isc-projects/dhcp/-/issues/197](https://gitlab.isc.org/isc-projects/dhcp/-/issues/197)https://gitlab.isc.org/isc-projects/dhcp/-/issues/196dhcp6.unicast option not sent from server to client2021-06-11T06:39:29ZRevathy Sankarrdhcp6.unicast option not sent from server to clientisc dhcp version - 4.4.1
When "option dhcp6.unicast 3001::2" is added in DHCP Server conf file, we are seeing unicast option not beign sent in packet.
We had added the above option in global level as well in subnet level. Still this is ...isc dhcp version - 4.4.1
When "option dhcp6.unicast 3001::2" is added in DHCP Server conf file, we are seeing unicast option not beign sent in packet.
We had added the above option in global level as well in subnet level. Still this is not beign sent to Client.
In Client code , we lookup for DHCP6 option in server packet. Since its not present, client is not able to send unicast packet.
Pls help us solve this issue.
Thanks & Regards,
Revathy Shttps://gitlab.isc.org/isc-projects/dhcp/-/issues/195isc-dhcp-server fails to start after update2022-01-20T15:35:06ZxJustmy2centsisc-dhcp-server fails to start after update---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because ...---
name: Bug report
about: DHCP Server fails to control subservices after upgrade
---
**Describe the bug**
**log from apt upgrade:**
```
Setting up isc-dhcp-server (4.3.5-3+deb9u2) ...
Job for isc-dhcp-server.service failed because the control process exited with error code.
See "systemctl status isc-dhcp-server.service" and "journalctl -xe" for details.
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
* isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2021-06-06 10:34:25 CEST; 82ms ago
Docs: man:systemd-sysv-generator(8)
Process: 20278 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/isc-dhcp-server.service
`-1457 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
Jun 06 10:34:24 derdapp003 systemd[1]: Starting LSB: DHCP server...
Jun 06 10:34:24 derdapp003 isc-dhcp-server[20278]: Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-serve…he other).
Jun 06 10:34:25 derdapp003 isc-dhcp-server[20278]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid curr….. failed!
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 06 10:34:25 derdapp003 systemd[1]: Failed to start LSB: DHCP server.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Unit entered failed state.
Jun 06 10:34:25 derdapp003 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
```
```
root@derdapp003:~# ps -ef|grep dhcp
root 1457 1 0 Apr20 ? 00:03:24 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf
root 20508 19428 0 10:37 pts/0 00:00:00 grep dhcp
```
**Cause**:
I have only IPv4 configured and up and running. On the upgrade isc seems to want IPv6 to be configured and fails with unspecific reason "exit-code".
First issue: the subprocess for dhcpd ipv4 is not stopped or not stopped in a correct manner.
Killing it manualy results in a pid file remaining, that also needs to be removed:
```
Jun 6 10:45:50 localhost isc-dhcp-server[20975]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists) ... failed!
Jun 6 10:45:50 localhost systemd[1]: isc-dhcp-server.service: Control process exited, code=exited status=1
Jun 6 10:45:50 localhost systemd[1]: Failed to start LSB: DHCP server.
```
Even doing so, the ics-dhcp-server fails on the next start with the same error in sequence.
After configuring `nano /etc/default/isc-dhcp-server`
with
```
# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
# Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACESv4="eth0.200 eth0.300 eth0.400"
INTERFACESv6=""
```
the server starts w/o any errors.
**claims**:
1. if no ipv6 interface is configured, the server should not fail to start, but just drop the ipv6 sequence
2. if the ics-dhcp-server fails to start for any reason, it should take care about subprocesses to be stopped in a correct way not leaving ghosts or pidfiles.
**Systeminformation**:
```
Linux derdapp003 4.19.59-sunxi #5.91 SMP Mon Jul 15 14:09:32 CEST 2019 armv7l GNU/Linux
description: ARMv7 Processor rev 4 (v7l)
product: LeMaker Banana Pro
~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch
~# dpkg -l|grep dhcp
ii isc-dhcp-client 4.3.5-3+deb9u2 armhf DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.5-3+deb9u2 armhf common manpages relevant to all of the isc-dhcp packages
ii isc-dhcp-server 4.3.5-3+deb9u2 armhf ISC DHCP server for automatic IP address assignment
```https://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/193DHCP Relay: replay from server is not forwarded (discarded ?)2022-03-09T19:13:59ZOlegDHCP Relay: replay from server is not forwarded (discarded ?)Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running...Hello, I have simple configuration of client-relay-server (by ISC):
1. client - 1 iface in net1 (10.0.0.0/24)
2. relay - 1 iface on net1 and 1 iface on net2 (10.0.10.0/24)
3. server - 1 iface on net2 (10.0.10.0/24).
When running it on **Linux Kernel 4.x.y **: all okey, request and replay are forwarded to/from server and IP address have been assigned to client.
When running on **Linux kernel 5.4.117 **: replay from server is lost somewhere in relay host or relay do not see it.
**Information about Relay**
My command line to run relay: _/usr/sbin/dhcrelay -d -pf /var/run/dhcrelay.pid -id eth3 -iu eth4 -c 10 -a 10.0.10.254_
Ip address of eth3 (to client) of relay is 10.0.0.1/24 and eth4 (to server) of relay is 10.0.10.1/24
**Information about Server**
Ip address of eth0 of server is 10.0.10.254/24
My command line to run dhcp server:_ /usr/sbin/dhcpd -user dhcpd -group dhcpd -cf /etc/dhcpd.conf eth0_
My config of dhcp server concerning to networks and ranges:
```
shared-network net-eth0 {
subnet 10.0.10.0 netmask 255.255.255.0 {
}
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.20;
}
}
```
I've used **tcpdump** on relay iface that looks to server and here is log:
1) Here is Request: 10.0.10.1 - is relay net2 iface of relay, 10.0.10.254 - is server net2 iface of server
`15:23:24.224319 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329`
2) Here is Reply: 10.0.0.1 - is net1 iface of relay
`15:23:24.224778 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300`
I've debugged also relay, and found, that when Replay needs to be received it was read be falback_discard() routine and relay can not see it. Here is debug of relay with some of my own debug-strings (comments starts with //):
```
//Initialization of relay staff
......
IPv4: Sending on Socket/fallback
//Here is omapi_iscsock_cb() called to read request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90 //address of reader (function got_one() )
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0 --status of reading Request
//Here is when and where replay should be read but it is discarded
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
//before calling reader()
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343ce6a70 //address of reader (function fallback_discard() )
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
//Here is 2nd Request try
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f6343cc5e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
```
**For comparison with GOOD case**: this is log of relay:
```
IPv4: Sending on Socket/fallback
IPv4: disc_ifaces: in fallback_iface: setting fcntl
//Getting Request
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=316
IPv4: do_relay4
IPv4: Adding 14-byte relay agent option
IPv4: Forwarded BOOTREQUEST for 08:00:27:ef:1a:e9 to 10.0.10.254
IPv4: omapi_iscsock_cb: af reader(): status=0
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebdaab0
IPv4: fallback_discard()
IPv4: omapi_iscsock_cb: af reader(): status=0
**//Here is REPLAY**
IPv4: omapi_iscsock_cb 0
IPv4: omapi_iscsock_cb1
IPv4: omapi_iscsock_cb2
IPv4: omapi_iscsock_cb: bf reader()=0x7f0d3ebb9e90
IPv4: got_one
IPv4: receive_packet
IPv4: receive_packet: recvfrom() ret=300
IPv4: do_relay4
IPv4: Forwarded BOOTREPLY for 08:00:27:ef:1a:e9 to 255.255.255.255
```
Tcpdump for good case:
```
//here is dump of eth4(to server) iface
18:17:39.866071 08:00:27:eb:f2:44 > 08:00:27:2e:19:cd, ethertype IPv4 (0x0800), length 371: 10.0.10.1.67 > 10.0.10.254.67: BOOTP/DHCP, Request from 08:00:27:ef:1a:e9, length 329
18:17:40.867748 08:00:27:2e:19:cd > 08:00:27:eb:f2:44, ethertype IPv4 (0x0800), length 342: 10.0.10.254.67 > 10.0.0.1.67: BOOTP/DHCP, Reply, length 300
//here is dump of eth3(to client) iface: this is what absent above in bad case: replay seen on net1 (eth3) iface of relay
18:19:04.575007 08:00:27:8f:96:7d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 10.0.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
```
Thanks!Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/191Client link-local address and interface not available in commit hook2021-05-29T03:41:26ZNick GallowayClient link-local address and interface not available in commit hook---
name: Client's link-local address and interface should be available in commit hook
about: Add either an option to get both the link local address and interface (in the usual fe80::abcd%IFACE format) or to obtain them separately.
---...---
name: Client's link-local address and interface should be available in commit hook
about: Add either an option to get both the link local address and interface (in the usual fe80::abcd%IFACE format) or to obtain them separately.
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Pretty sure. I went over all the relevant code and even tried implementing hooks that look at the packet content but didn't see an option available.
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration? It probably is implemented in Kea, but there's already the better part of an implementation for ISC DHCP written so I think it could be an easy addition to ISC DHCP, and it would overall be a lot less work for anyone not wanting to migrate just yet.
- Are you sure what you would like to do is not possible using some other mechanisms? Not directly, no. It is possible by writing a commit hook that executes a neighbour discovery lookup to obtain the link-local address of the client based on the Mac address of the client, but that seems like an incorrect solution.
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists? No.
**Is your feature request related to a problem? Please describe.**
A problem I ran into recently on a popular open source router distribution (OPNsense) is that delegating prefixes to subrouters was broken. I spent some time looking into it and came up with a [solution](https://github.com/opnsense/core/pull/5020), but I think it is less than ideal. It would be better to simply directly have access to the client's link-local address/interface so that routes can be added directly in an on commit hook.
**Describe the solution you'd like**
I think integrating the last five changes here would be along the lines of what I'd go for: https://github.com/Oryon/isc-dhcp/commits/mpalmer/client-address-data-expression
I don't agree with all the specifics of the patches there and would probably present it as a single string to the commit hook, but it's roughly what I'd like.
**Describe alternatives you've considered**
I've considered just migrating to Kea, but as this seems like a relatively small change to improve commit hooks for delegating prefixes it seems like the better option. If ISC DHCP is being deprecated or development halted then migration would be far more urgent.
**Additional context**
Hopefully this request is fairly clear and the GitHub reference for the Oryon/mpalmer patches are also clear.
**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?
Not in my current role, no.
**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?
I am willing but my time is quite limited. I'm not set on any specific solution to this problem.
**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.
I can keep an eye on this issue but if you need to reach out or send me a message that's also fine.https://gitlab.isc.org/isc-projects/dhcp/-/issues/186FQDN support is incomplete (does not allow partial names)2022-03-23T10:59:39Zsam-luntFQDN support is incomplete (does not allow partial names)Per [RFC 4704](https://datatracker.ietf.org/doc/rfc4704/) section 4.2:
> A client MAY be configured with a fully qualified domain name or with
a partial name that is not fully qualified. If a client knows only
part of its name, i...Per [RFC 4704](https://datatracker.ietf.org/doc/rfc4704/) section 4.2:
> A client MAY be configured with a fully qualified domain name or with
a partial name that is not fully qualified. If a client knows only
part of its name, it MAY send a name that is not fully qualified,
indicating that it knows part of the name but does not necessarily
know the zone in which the name is to be embedded.
> To send a fully qualified domain name, the Domain Name field is set
to the DNS-encoded domain name including the terminating zero-length
label. To send a partial name, the Domain Name field is set to the
DNS-encoded domain name without the terminating zero-length label.
However, the `fqdn_encode` function unconditionally adds the terminating zero-length label [here](https://gitlab.isc.org/isc-projects/dhcp/-/blob/79110e525e0584d195327d31f4ee67e6a5e2fe7a/common/options.c#L3363). This means that if they do not know the domain name, then it is impossible for clients to request that the AAAA and PTR records be updated in a compliant way.
Looking at the code, since this function is part of `common/options.c`, it seems that there is an issue determining whether the logic is being invoked by a client or a server (since only the client may provide a partial name). This field is currently populated with the `fqdn.fqdn` config option. Maybe another option `fqdn.host_name` (or `fqdn.partial_name`) could be added. If `fqdn.fqdn` is empty but `fqdn.host_name` is not, then the encoding logic would omit the terminating zero-length label.
I'm not too familiar with the code base, though, so maybe that's not a practical suggestion.https://gitlab.isc.org/isc-projects/dhcp/-/issues/185IPv6 dhclient does not accept server provided prefix length2022-03-09T19:12:43ZSunitha HarishIPv6 dhclient does not accept server provided prefix length---
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**
IPv6 dhclient does not accept server provided prefix length. It always set it to 128
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient -6 -nw -cf /etc/dhclient.conf -lf /tmp/dhcp/dhclient6-eth0.leases -pf /tmp/dhcp/dhclient6-eth0.pid eth0
2. DHCP server sends the value 64 for prefix-legth
3. The dhclient sets the default value 128 , and ignores the value 64 sent by the server
4. dhclient's new IPv6 ip is not pingable from the dhcp server machine, since the prefix-length is not matching
**Expected behavior**
dhclient must parse the prefix-length sent from the server and set it to the interface
**Environment:**
Internet Systems Consortium DHCP Client 4.4.1
- OS: Linux 5.4.85
**Additional Information**
My /etc/dhcp/dhcpd6.conf is
subnet6 2001:db8:0:2::/64 {
range6 2001:db8:0:2::120 2001:db8:0:2::130;
}
IP set by dhclient is
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 14:0d:4f:68:74:8d brd ff:ff:ff:ff:ff:ff
inet6 2001:db8:0:2::126/128 scope global deprecated dynamic
valid_lft 2590893sec preferred_lft 0sec
inet6 fe80::160d:4fff:fe68:748d/64 scope link
valid_lft forever preferred_lft forever
**Some initial questions**
I explored the dhclient code in the isc project and saw that the prefix length is set to 128 by default. What is the reason for the hardcoding?
I also saw a forum where this is discussed : https://kb.isc.org/docs/aa-01141
When is the fix is planned to come? My product is using this dhclient and it needs this change at the earliest
**Is your feature request related to a problem? Please describe.**
My product is required to accept the dhcp server sent prefix-length.
**Describe the solution you'd like**
Parse the prefix-length at the dhclient.c and set the {new_ip6_prefixlen} at the dhclient script
**Describe alternatives you've considered**
Alternative is to again hardcode the prefix-length to other value at my dhclient environment using --address-prefix-len option. But that again does not help since its again a hardcoded value
**Participating in development**
No
**Contacting you**
sunithaharish04@gmail.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/184[PATCH] relay: fix IPv6 multicast address in documentation2022-03-09T19:11:59ZFoster Snowhill[PATCH] relay: fix IPv6 multicast address in documentation```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in do...```diff
From e6ca44a168b5ae07cb2b6d7aa9c7548eaf82b7ff Mon Sep 17 00:00:00 2001
From: Foster Snowhill <2516-forst@users.noreply.gitlab.isc.org>
Date: Sun, 25 Apr 2021 15:23:16 +0200
Subject: [PATCH] relay: fix IPv6 multicast address in documentation
In the dhcrelay source code, parse_upstream() function by default defines the
destination address to be the All_DHCP_Servers multicast group (ff05::1:3).
However, the documentation says that it uses All_DHCP_Relay_Agents_and_Servers
(ff02::1:2). This is inconsisent with the implementation.
This commit fixes the documentation to also specify All_DHCP_Servers as the
default multicast group.
---
relay/dhcrelay.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/relay/dhcrelay.8 b/relay/dhcrelay.8
index 53cd28bf..10ebfe3d 100644
--- a/relay/dhcrelay.8
+++ b/relay/dhcrelay.8
@@ -325,7 +325,7 @@ forwarded. At least one \fB-u\fR option must be included in the command
line when running in DHCPv6 mode. The interface name \fIifname\fR is a
mandatory parameter. The destination unicast or multicast address can be
specified by \fIaddress%\fR; if not specified, the relay agent will forward
-to the DHCPv6 \fIAll_DHCP_Relay_Agents_and_Servers\fR multicast address.
+to the DHCPv6 \fIAll_DHCP_Servers\fR multicast address.
.PP
It is possible to specify the same interface with different addresses
more than once, and even, when the system supports it, to use the same
--
2.31.1
```
---
This patch is against `master` (commit 79110e525e0584d195327d31f4ee67e6a5e2fe7a).
For reference, the relevant line in `parse_upstream()` function: https://gitlab.isc.org/isc-projects/dhcp/-/blob/79110e525e0584d195327d31f4ee67e6a5e2fe7a/relay/dhcrelay.c#L1532
If possible, can I also please get a project allocation, so that in the future I can submit proper merge requests? Thanks!Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/183dhcpd will not use corresponding address if network interface activated after...2022-03-29T10:58:47Ze-piratedhcpd will not use corresponding address if network interface activated after dhcpd startedI spent several days on figuring out how to make dhcpd respond on network interfaces that became available/configured after dhcpd is started. The reason for this is that if dhcpd serves more than one iface and dhcpd service is in strong ...I spent several days on figuring out how to make dhcpd respond on network interfaces that became available/configured after dhcpd is started. The reason for this is that if dhcpd serves more than one iface and dhcpd service is in strong dependency of both interfaces, dhcpd will fail if any interface fail to start. In my case dhcpd is serving lan and wlan. Both can fail randomly on a long run/ Known reasons: lightning can take lan out, wlan can fail to start because of hotsapd problems, any driver/kernel update/configuration mistake will bring iface down taking dhcpd out if it "need" any of network interfaces.
Originally, I had both lan0 and wlan0 specified as options to dhcpd service, but this resulted in:
```
No subnet declaration for lan0 (no IPv4 addresses).
** Ignoring requests on lan0. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface lan0 is attached. **
```
error message in logs if corresponding interface is activated (get IPv4 address) after dhcpd was started.
So, I removed interfaces from service command arguments and introduced `interface` option to my subnet:
```
subnet 10.0.0.0 netmask 255.255.255.0 {
interface lan0;
range 10.0.0.8 10.0.0.16;
default-lease-time 14400;
max-lease-time 86400;
option domain-name-servers 10.0.0.1;
option routers 10.0.0.1;
option ntp-servers 10.0.0.1;
option broadcast-address 10.0.0.255;
}
```
wlan0 configuration is omitted.
When dhcpd is started after lan0, I can see the fallowing (client side):
```
22:05:30.454105 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:05:31.585355 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:05:33.796111 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:05:33.797024 IP 10.0.0.1.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:05:33.797306 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 298
22:05:33.798182 IP 10.0.0.1.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
```
Notice the dhcpd replaying from 10.0.0.1.
Then I simulate interface failure by 1) brinning lan0 down (the link will go down as well, test client will notice this and will start sending discovers) 2) restarting dhcpd, it will report `receive_packet failed on lan0: Network is down` 3) staring lan0.
Finally, dhcpd will receive a discover from a client:
```
22:06:02.453552 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:02.454528 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:04.057172 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:04.058009 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:06.076225 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:06.077561 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:07.647378 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:07.648335 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:11.751204 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:11.752284 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:18.830728 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:18.831779 IP 0.0.0.0.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:35.453960 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
```
But dhcpd will respond from 0.0.0.0 and the client seems to ignore (tested on two different clients) this DHCPOFFER never sending DHCPREQUEST until dhcpd is restarted with lan0 up/configured. If I restart dhcpd, it will use corresponding IP address and client will accept offers responding with request:
```
22:06:35.454256 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 292
22:06:35.454550 IP 10.0.0.1.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
22:06:35.456998 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:xx:xx:xx:xx:xx, length 298
22:06:35.457165 IP 10.0.0.1.67 > 10.0.0.4.68: BOOTP/DHCP, Reply, length 300
```
This seem to be invalid because even if interface is not ready when dhcpd starts up, dhcpd is aware of the correct address because of `interface` option in subnet and therefore can use correct src address for offers and acks. It maybe needed to accomplish some percedure to use new address after pointed iface becames ready. For example, bind starts before any network interface become ready, and then reports something like:
```
named[2060]: listening on IPv4 interface lan0, 10.0.0.1#53
```
So there is no need to watch for interfaces and start orders. BIND will take care of this by itself. And it will be nice to be able to configure dhcpd is such way it will be able to serve DHCP on interfaces that became ready after dhcpd is started in case dhcpd is able to match interface and subnet.https://gitlab.isc.org/isc-projects/dhcp/-/issues/179Need to add support for structured options2022-03-09T19:11:17ZBen DonnetteNeed to add support for structured options---
name: Support for dhcp structured options
about: Dealing with eg. MAP-T configuration options by generating several environment variables
---
**Some initial questions**
- Are you sure your feature is not already implemented in the ...---
name: Support for dhcp structured options
about: Dealing with eg. MAP-T configuration options by generating several environment variables
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version?
It was not last time I had a look.
- Are you sure your feature is not already implemented in the latest Kea version? Perhaps it's a
good time to consider migration?
- Are you sure what you would like to do is not possible using some other mechanisms?
- Have you discussed your idea on dhcp-users or dhcp-workers mailing lists?
**Is your feature request related to a problem? Please describe.**
I'm trying to use dhcp to configure a MAP-T CE. This involves the DHCPv6 options as described in the RFC 7498. The idea is to then push the options as environment variables useable in shell scripts called upon lease recepit.
If we take the S46 rule (option 89) as an example and use the S46RULE prefix, one could expect the following environment variables generated :
S46RULE_FLAG
S46RULE_EALEN
S46RULE_IPV4PREFIX (network notation eg. 192.168.1.0/24)
S46RULE_IPV6PREFIX
S46RULE_OPTIONS (the latter giving rise to deeper structures).
This is actually what udhcpc already does (probable contribution from OpenWRT).
**Describe the solution you'd like**
Upon receipt of an option, an environmen,t variable gets filled when a text representation is relevant. For structured options, the idea is to mimic the structure with the generation of autrtomatic environment variable using a "_" (underscore) syntax.
**Describe alternatives you've considered**
The project I'm on would not be easy to migrate to other dhcp clients.
**Additional context**
See RFC 7498
**Funding its development**
I could implement the feature.
**Participating in development**
I could implement the feature. Of course complying to the architecture team's directives.
**Contacting you**
E-mail, github woiuld be relevant.Outstandinghttps://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/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/175DHCP bug2022-01-13T11:46:10Zosullo23DHCP bug```
sudo /etc/init.d/isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since...```
sudo /etc/init.d/isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-03-22 05:02:56 PDT; 9min ago
Docs: man:dhcpd(8)
Process: 3086 ExecStart=/bin/sh -ec CONFIG_FILE=/etc/dhcp/dhcpd.conf; if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi; [ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf $CONFIG_FILE $INTERFACES (code=exited, status=1/FAILURE)
Main PID: 3086 (code=exited, status=1/FAILURE)
Mar 22 05:02:56 ubuntu dhcpd[3086]:
Mar 22 05:02:56 ubuntu dhcpd[3086]: If you think you have received this message due to a bug rather
Mar 22 05:02:56 ubuntu dhcpd[3086]: than a configuration issue please read the section on submitting
Mar 22 05:02:56 ubuntu dhcpd[3086]: bugs on either our web page at www.isc.org or in the README file
Mar 22 05:02:56 ubuntu dhcpd[3086]: before submitting a bug. These pages explain the proper
Mar 22 05:02:56 ubuntu dhcpd[3086]: process and the information we find helpful for debugging.
Mar 22 05:02:56 ubuntu dhcpd[3086]:
Mar 22 05:02:56 ubuntu dhcpd[3086]: exiting.
Mar 22 05:02:56 ubuntu systemd[1]: isc-dhcp-server.service: Main process exited, code=exited, status=1/FAILURE
Mar 22 05:02:56 ubuntu systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
```
tomek: formatted for readability.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/173Multihomed usecase/dhcpv6: Different ipv6 addresses are getting set/unset on ...2022-01-13T11:44:09ZRevathy SankarrMultihomed usecase/dhcpv6: Different ipv6 addresses are getting set/unset on interface when multiple vlans run dhclient and request from same server.Multihomed usecase/dhcpv6: Different ipv6 addresses are getting set/unset on interface when multiple vlans run dhclient and request from same server.
**Isc version:** isc-dhcp-4.4.1
**Configurations:**
**SetUP:** 40 vlans connected ...Multihomed usecase/dhcpv6: Different ipv6 addresses are getting set/unset on interface when multiple vlans run dhclient and request from same server.
**Isc version:** isc-dhcp-4.4.1
**Configurations:**
**SetUP:** 40 vlans connected back to back between Client & Server.
**Client details:** dhclient is running on each vlan. Each of the VLAN(SVI interface) requests for ipv6 IA_NA address and IA_PD prefix from server
**Server details:** 1 dhcpd server with 40 vlans and conf file having 40 different subnets.
**Issue explanation:**
When IA_NA & IA_PD are requested from dhclient, we see the from 1st renewal, the ipv6 address/prefix learnt at the client side keep changing.
At times even 2 ipv6 address and prefixes were present are present in the VLAN SVI interface.
Sequence of operations between client & server:
- Dhclient: All the vlan interfaces acquire ipv6 addr/prefix from server.(IPV6_ADDRESS_1)
- Dhclient sends renewal upon half lease expiry, in few VLANs dhcpd server replies with NoBinding option.
- Now dhclient starts a new handshake by sending Solicit message. This dhcpd server offers new ipv6 address and prefix (IPV6_ADDRESS_2) ---- > Now interface has 2 ipv6 address and prefix.
- When the lease of V6_ADDRESS_1 expires, it is removed by the dhclient. Now interface has just 1 ipv6 address.
This sequence continues for few VLAN interfaces and affects the underlying networks which was constructed based on the learned prefixes.
**Points to be noted:**
- ia_na /ia_pd transaction id,device duid are unique for each vlans.
- Dhcpd server lease file is having the details of 1st ipv6 address. Still it returns NoBindings
Please find the attached packet capture of dhclient/dhcp server and dhclient logs.
1. [dhcp_client.pcap](/uploads/e91997f7929078378fb207180172b414/dhcp_client.pcap)
2. [dhcp_server.pcap](/uploads/75efcf0243ca7d3a661d6aaeff05c9c2/dhcp_server.pcap)
3. [dhclientv6__logs.txt](/uploads/87c90a5df3ca7661c753912134eac18b/dhclientv6__logs.txt)
Thanks & Regards,
Revathy Sankarrhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/172DHCPd alternates between returning the primary IP assignment and the backup IP2021-03-12T14:53:32ZwaynegemmellDHCPd alternates between returning the primary IP assignment and the backup IPI run lxc containers that make heavy use of dhcp and ddns services. The containers run Ubunut Focal. When I run netplan apply on the containers then they get the primary IP address some times and the backup IP address other times. Both a...I run lxc containers that make heavy use of dhcp and ddns services. The containers run Ubunut Focal. When I run netplan apply on the containers then they get the primary IP address some times and the backup IP address other times. Both addresses are correctly assigned to the appropriate hosts in the leases file.
**To Reproduce**
Steps to reproduce the behavior:
1. netplan apply
2. the container sends DHCPRELEASE and starts with reaquiring the IP address.
3. The communication flow looks ok but regularly a backup IP address is assigned.
**Environment:**
- isc-dhcp-server version 4.3.5-3ubuntu7.1 on the server
- isc-dhcp-client version 4.4.1-2.1ubuntu5 on the client
- OS: Server is Ubuntu 16.04.7 LTS
- OS: Client is Ubuntu 20.04.2 LTS
- Which features were compiled in
**Config file**
```
ddns-updates on;
ddns-update-style interim;
#update-static-leases on;
key "dhcpdupdate" {
algorithm hmac-md5;
secret "blahblahblah==";
};
ddns-domainname "lxc";
#ddns-rev-domainname "in-addr.arpa.";
zone lxc {
primary 127.0.0.2;
key dhcpdupdate;
}
# option definitions common to all supported networks...
option domain-search "lxc", "iron";
option domain-name-servers 10.3.0.214, 10.3.0.118;
default-lease-time 86400;
max-lease-time 86400;
option classless-routes code 121 = array of unsigned integer 8;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
failover peer "failover-partner" {
secondary;
address zed1.server;
port 520;
peer address zabbix1.server;
peer port 519;
max-response-delay 60;
max-unacked-updates 10;
load balance max seconds 3;
}
allow booting;
subnet 10.3.0.0 netmask 255.255.0.0 {
class "kannel" {
match if substring (option host-name, 0, 6) = "kannel";
}
pool {
deny members of "kannel";
failover peer "failover-partner";
range 10.3.0.150 10.3.0.210;
range 10.3.3.2 10.3.3.250;
range 10.3.4.2 10.3.4.250;
option classless-routes 16,10,5,10,3,0,129,16, 10,4, 10,3,0,129,0,10,3,0,129;
filename "pxelinux.0";
}
pool {
allow members of "kannel";
failover peer "failover-partner";
range 10.3.2.10 10.3.2.100;
range 10.3.5.10 10.3.5.100;
option classless-routes
16,10,5,10,3,0,129,16, 10,4, 10,3,0,129,0,10,3,0,113;
}
}
next-server 10.3.0.214;
# insert this (with your own key text substituted) into dhcpd.conf on primary and secondary.
omapi-port 7911;
omapi-key omapi_key;
key omapi_key {
algorithm hmac-md5;
secret moo=;
}
```
Lease info
https://pastebin.com/jf11bcC9
Logs
https://pastebin.com/jB1YWZQm
I've chatted on the IRC about this but hit a wall. I'm happy to send out any other information that is necessary or pay for an hour or 2 of an engineers time if it comes down to that.