Feature #7416
closed
DHCPv4 client does not support ``supersede`` statement for option 54
Added by Fabian Kurtz about 7 years ago.
Updated about 2 years ago.
Plus Target Version:
22.01
Description
The German cable internet provider Unitymedia uses DHCP relays which only answer to broadcasts. Dhclient renews WAN leases by sending unicasts to the relay, which doesn't forward them to the DHCP server. If, in the rebind phase, the broadcast packet is lost, the WAN IP expires, all connections are dropped and Dhclient needs to aquire a new lease. This is discussed in [[https://forum.pfsense.org/index.php?topic=127023.0]].
The problem can be avoided by setting DHCP option 54 (dhcp-server-identifier) to 255.255.255.255 via Interfaces->WAN->Advanced configuration->Option Modifiers. However, the required supersede statement for this option is not implemented in dhclient.c. Thus the DHCP client of Pfsense does not use the option and the value given by the DHCP server remains in effect (which points to the IP of the relay), which then results in the observed problem.
To solve this a section which checks if "supersede dhcp-server-identifier" is set has been added to dhclient.c (see "Start of the updated section" at line 855 in the attached file).
Files
- Status changed from New to Needs Patch
- Priority changed from High to Low
- Target version changed from 2.3.4 to Future
Changes to FreeBSD should first be submitted upstream to FreeBSD.
Might be, but it's still an open issue and hasn't been accepted into FreeBSD yet. There isn't even one person on that issue that has actually tested it to confirm it solves the original problem. I don't see it getting pulled into pfSense without at least some confirmation that it works.
I beg to differ and hope I'm not mistaken, but AFAIK Franco pulled that already into OPNsense and the last statement of Fabian is IMHO based on him testing it in a newer release which - as was told to me in the german subforums - now has the changes in dhclient and can set option 54 to broadcast and this far seems to have that specific problem solved. Pulling it into a snapshot would make it easier for others to test.
Rico has alerady started with a bit crude build of dhclient in the german subforums (see: https://forum.netgate.com/topic/121939/verbindungsabbr%C3%BCche/72) but for wider tests a snapshot with it would come in handy. I know it's perhaps a very localized problem but as cable providers in Germany are gaining more and more customers, there are still more users that fall over that specific bug.
At least it would help a few of us german outsiders, that are stuck with a certain cable provider :)
The reply on the FreeBSD PR is ambiguous at best. It would also help if someone that was actually a part of the FreeBSD project was involved in that PR, or at least a patch review from FreeBSD.
We aren't in the habit of applying patches first and testing them later when they come from outside sources like that.
It appears simple, but the last time something broke dhclient is was very painful for a large number of people, and I'm not inclined to repeat the experience.
The patch fixed it in OPNSense in 2017. It has been running flawlessly ever since. That's the only feedback I can provide on this.
- Status changed from Needs Patch to Feedback
- Target version changed from Future to 2.6.0
- Plus Target Version set to 22.01
Fabian Kurtz wrote in #note-6:
The patch fixed it in OPNSense in 2017. It has been running flawlessly ever since. That's the only feedback I can provide on this.
Starting from 2.6.0/22.01 you can check the "Advanced Configuration" and add "supersede dhcp-server-identifier" to the "Option modifiers" field.
- Subject changed from Dhclient does not support supersede statement for option 54 to DHCPv4 client does not support ``supersede`` statement for option 54
Updating subject for release notes.
- Status changed from Feedback to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by Viktor Gurov