dhcp issueshttps://gitlab.isc.org/isc-projects/dhcp/-/issues2021-08-24T14:28:14Zhttps://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/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/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/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/142Overflow in lease time and potentially in renew/rebind of IPv6 client2022-03-07T13:16:09ZChristos ChryssochoidisOverflow in lease time and potentially in renew/rebind of IPv6 client---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6...---
name: Lease time calculations overflow in IPv6 client.
about: dhclient v6
---
**Describe the bug**
For large values of life time for IPv6 leases, e.g. `default-lease-time 4294967294 # or -2`, dhclient calculations in `client/dhc6.c` cause overflow in systems using a **32 bit signed integer for the TIME data type**. As a result dhclient enters an infinite loop since a negative relative expiration time is considered immediately expired.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhcp server IPv6 with a config containing the following:
```
default-lease-time 4294967294; # or -2
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
```
2. A client solicits a new lease by broadcasting a SOLICIT packet. The above server sends then an ADVERTISE, following by the client sending a REQUEST, and finally the server sending a REPLY.
3. The client then immediately repeats sending a SOLICIT packet.
4. This cycle goes on forever.
**Expected behavior**
After receiving the REPLY packet the client should not repeat sending a SOLICIT packet.
**Environment:**
isc-dhclient-4.1-ESV-R16
- OS: Embedded Linux (**MIPS64n32** architecture)
**Additional Information**
An example config for IPv6 dhcp server is the following:
[dhcpd6-example.conf](/uploads/556d0909d055e86398985aa5abc5ef74/dhcpd6-example.conf)
In the logs I'm seeing the following line:
> PRC: Renewal event scheduled in 3600 seconds, to run for 3600 seconds. PRC: Depreference scheduled in 7200 seconds. PRC: Expiration scheduled in **-2 seconds.**
**Some initial questions**
> - Are you sure your feature is not already implemented in the latest ISC DHCP version?
I've tested it with the latest ESV version of dhclient.
> - Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration?
It's a client issue, therefore migrating to Kea doesn't seem to provide solution to this problem.
> - Are you sure what you would like to do is not possible using some other mechanisms?
No.
> - Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists?
No.
**Describe the solution you'd like**
I'm attaching a patch that seems to solve this issue:[dhclient.patch](/uploads/d13a046a05524006b6571e003a35e327/dhclient.patch)
**Context**
Seems to happen when the TIME data type used for lifetime and renew/rebind time calculations is a 32 bit signed integer type.
**Participating in development**
Yes, I am willing to participate in the development.
**Contacting you**
contact email: christos.chryssochoidis@nokia.comOutstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/120Unable to get MAC in the DHCPv6 leases database while MAC address is availabl...2020-08-12T14:34:40ZGaneshUnable to get MAC in the DHCPv6 leases database while MAC address is available in the DHCPv6 client request packet.---
name: Get DHCPv6 MAC Address of client in dhcpd6.leases database.
about: Need a way to print DHCPv6 MAC address in the dhcpd6.leases.
---
**Describe the bug**
I have captured a DHCPv6 IP request packet. In that packet, I am getting...---
name: Get DHCPv6 MAC Address of client in dhcpd6.leases database.
about: Need a way to print DHCPv6 MAC address in the dhcpd6.leases.
---
**Describe the bug**
I have captured a DHCPv6 IP request packet. In that packet, I am getting Link-Layer Address(MAC) as a parameter under the DHCPv6-Client Identifier section. I want that MAC address should print in the dhcpv6 leases database file /var/lib/dhcpd6.leases. Let me know is there any way to print DHCPv6 request options in the leases database.
**Expected behavior**
If DHCPv6 request packet is getting any specific options like MAC address then there should be configuration to print that data in the dhcpd6.leases database.
**Environment:**
- ISC DHCP version: 4.4.2
- OS: CentOS7Outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/73dhclient not releasing IPv6 address2022-03-07T13:13:08ZGhost Userdhclient not releasing IPv6 address---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclie...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhclient not releasing the IPv6 address where as IPv4 address release working fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Run dhclient -6 with regular configuration.
2. Send signal 15 to kill the dhclient process.
3. Observed release of the IP address not happening. The following message only seen from dhclient logs.
`Received signal 15, initiating shutdown.`
**Expected behavior**
As part of signal handling dhclient should call the do_release6 for AF_INET6 family. This will gracefully release IPv6 address and calls the script file also.
Where as, dhclient is gracefully releasing the IPv4 address. We can observe the following logs for the same.
`Received signal 15, initiating shutdown.`
`DHCPRELEASE of <SELF IP ADDRESS> on <INTERFACE NAME> to <DHCP SERVER IP> port 67`
`Killed`
**Environment:**
- ISC DHCP version: isc-dhclient-4.4.1
- OS: Linux CentOS
- Which features were compiled in: dhclient
**Additional Information**
NOT sure this behavior is w.r.to IPv6 architecture only. Would like to make sure not missing things from isc-dhclient side.
**Some initial questions**
- Are you sure your feature is not already implemented in the latest ISC DHCP version? Yes
- Are you sure your requrested feature is not already impemented in Kea? Perhaps it's a good time
to consider migration? Don't know
- Are you sure what you would like to do is not possible using some other mechanisms? Yes
- Have you discussed your idea on dhcp-users and/or dhcp-workers mailing lists? NOOutstanding