The isp’s (cable-provider in germany) dhcp-server answer with “NAK”, when it’s time to renew the ip-configuration of the red-interface. This happens since update from core 158 to core 159. Sometimes there are “red0: failed to renew DHCP, rebinding” message too, but this has happened before core 159 already.
Aug 26 04:18:22 ipfire dhcpcd[1884]: red0: failed to renew DHCP, rebinding
Aug 26 04:18:22 ipfire dhcpcd[1884]: red0: NAK: from <isp’s dhcp-ipv4-adress>
Aug 26 05:18:28 ipfire dhcpcd[1884]: red0: NAK: from <isp’s dhcp-ipv4-adress>
.
.
.
Aug 26 20:19:49 ipfire dhcpcd[1884]: red0: NAK: from <isp’s dhcp-ipv4-adress>
Aug 26 21:19:55 ipfire dhcpcd[1884]: red0: NAK: from <isp’s dhcp-ipv4-adress>
Aug 26 22:20:00 ipfire dhcpcd[1884]: red0: NAK: from <isp’s dhcp-ipv4-adress>
Everytime there is a “NAK” answer from isp’s dhcp-server (1h intervall), red goes down (dropping routes etc.) and initiate a rebind and new dhcp lease. So every hour i got disconnected from the internet - very annoying.
Then I saw, that there were some configuration changes in /var/ipfire/dhcpc/dhcpd.conf from arne:
But I’m not into it, to know exactly, what change causes my isp’s dhcp-server to answer with “NAK”. Need some help with that.
Ok, that’s interesting. Put back old /var/ipfire/dhcpc/dhcpd.conf from core 158 and rebooted. The first initiate of the red-interface after a reboot differs slightly from core 158 to core 159:
core 159:
Aug 26 22:53:13 ipfire dhcpcd[1883]: red0: waiting for carrier
Aug 26 22:53:17 ipfire dhcpcd[1883]: red0: carrier acquired
Aug 26 22:53:17 ipfire kernel: ixgbe 0000:05:00.0 red0: NIC Link is Up 1 Gbps, Flow Control: None
Aug 26 22:53:17 ipfire dhcpcd[1883]: red0: IAID XX:XX:XX:XX
Aug 26 22:53:17 ipfire dhcpcd[1883]: red0: adding address fe80::XXX:XXXX:XXXX:XXXX
Aug 26 22:53:17 ipfire dhcpcd[1883]: ipv6_addaddr1: Permission denied
Aug 26 22:53:17 ipfire dhcpcd[1883]: red0: soliciting an IPv6 router
Aug 26 22:53:18 ipfire dhcpcd[1883]: red0: soliciting a DHCP lease
Aug 26 22:53:18 ipfire dhcpcd[1883]: red0: probing address <my external ipv4-adress>/24
Aug 26 22:53:24 ipfire dhcpcd[1883]: red0: leased <my external ipv4-adress> for 7200 seconds
Aug 26 22:53:24 ipfire dhcpcd[1883]: red0: adding route to <isp subnet ipv4-adress>/24
Aug 26 22:53:24 ipfire dhcpcd[1883]: red0: adding default route via <isp gateway ipv4-adress>
Aug 26 22:53:24 ipfire dhcpcd.exe[1936]: red0 has been (re)configured with IP=<my external ipv4-adress>
core 158:
Aug 27 09:42:38 ipfire dhcpcd[1882]: red0: waiting for carrier
Aug 27 09:42:42 ipfire dhcpcd[1882]: red0: carrier acquired
Aug 27 09:42:42 ipfire kernel: ixgbe 0000:05:00.0 red0: NIC Link is Up 1 Gbps, Flow Control: None
Aug 27 09:42:42 ipfire dhcpcd[1882]: red0: IAID XX:XX:XX:XX
Aug 27 09:42:42 ipfire dhcpcd[1882]: red0: adding address fe80::XXX:XXXX:XXXX:XXXX
Aug 27 09:42:42 ipfire dhcpcd[1882]: ipv6_addaddr1: Permission denied
Aug 27 09:42:42 ipfire dhcpcd[1882]: red0: soliciting an IPv6 router
Aug 27 09:42:43 ipfire dhcpcd[1882]: red0: soliciting a DHCP lease
Aug 27 09:42:43 ipfire dhcpcd[1882]: red0: offered <my external ipv4-adress> from <isp dhc-server ipv4-adress>
Aug 27 09:42:43 ipfire dhcpcd[1882]: red0: probing address <my external ipv4-adress>/24
Aug 27 09:42:49 ipfire dhcpcd[1882]: red0: leased <my external ipv4-adress> for 7200 seconds
Aug 27 09:42:49 ipfire dhcpcd[1882]: red0: adding route to <isp subnet ipv4-adress>/24
Aug 27 09:42:49 ipfire dhcpcd[1882]: red0: adding default route via <isp gateway ipv4-adress>
Aug 27 09:42:49 ipfire dhcpcd.exe[1935]: red0 has been (re)configured with IP=<my external ipv4-adress>
As you can see, with core 159 there is no dhcp offering…
Edit: No disconnects with old /var/ipfire/dhcpc/dhcpd.conf, so there must be something with the new options, that my isp’s dhcp-server doesn’t like.
I looked at my dhcpcd logs and I am getting the offered line with Core Update 159.
This means that your isp’s dhcp server didn’t give any reply at all to your soliciting request.
Looking at the differences between the two conf files the part that may be causing the problem in your case could be
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
The old version only had the clientid line and it was also commented out. The entry says that some non-RFC compliant DHCP servers do not reply with duid set.
So you could try commenting out duid and either removing the comment from clientid or leave it commented out as in the previous version and see if that then works for you.
Okay. Then my only suggestion is to comment out each additional entry until you find which one gets you a response from your isp.
Quick check, after making those changes did you reboot or release and rebind the red0 interface. Just changing the conf file doesn’t change anything once dhcpcd is running.
The commands to release and rebind the red0 interface, which is quicker than a reboot ,can be found in this thread
Ok, did that (thx 4 shortcut commands, always did a reboot :x) and tada, the problematic option is:
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
Commented out and i got offering again. Looks like that is not so safe to enable it as the comment stated :x.
I think I have found what the problem might be. Looking at the man page for dhcp (not dhcpc) then it refers to rapid-commit as an option. So it might need to be a - instead of an _
If correct and the - works for you then I will raise a patch to fix this.
Maybe, but I am not totally sure and I can’t test it as my system is quite happy with the underscore. If your system works okay with the - and not with the _ then I will raise a bug otherwise not.
Sorry to bump this old thread however, I have also had this issue for some months on Google Fiber in the United States. I have experimented with the settings here in this thread and I feel confident in posting my results now.
When I leave the dhcpcd.conf file in its base configuration my IPFire router will not route traffic to WAN. It will pull a WAN IP but after 600 seconds, the initial WAN lease will drop with a NAK. During this time no traffic is able to pass to the WAN.
If I comment out the “option rapid_commit” line, and renew the WAN link I instantly get a lease and traffic routes perfectly. The router will maintain its lease over many days and is perfectly stable.
I also tried changing the config file to “option rapid-commit”. I changed the _ to a -. The WAN IP renewal also works perfectly with this however, I also see the error “unknown option: rapid-commit” when attempting to renew the lease. So it would appear as though the ‘-’ syntax is also incorrect and is just being ignored.
Then leave the option rapid_commit line commented out.
A properly configured ISP dhcp server will use rapid_commit if it is able to or will just ignore the option if it cannot use it.
Some ISP’s have dhcp servers that are not configured in line with the RFC’s and so their dhcp servers don’t work well with the rapid_commit option. They can’t use the option but they don’t ignore it as the RFC’s for dhcp specify.
As you are unlikely to make your ISP fix their dhcp server the simplest option is just to comment out the rapid_commit option.
Any modification you make to the dhcpcd.conf file, like commenting out the rapid_commit option, will be saved in your IPFire backup and so will be maintained across Core Updates.
I use all of the main firewall distros and even some of the lesser known ones. IPFire has been the only distro that will not pull a WAN address and work for my ISP. I understand that from the perspective of the developers this is an ISP issue however, based on user input in this thread it seems a great many ISPs are not using or honoring the “rapid commit” function as it is used on the IPFire WAN DHCP lease request.
While I am willing to spend hours searching through logs and googling issues (and thus, finding this old thread), many users will simply not do this and will abandon IPFire and just go with another option. OpenWRT, pfSense, OPNsense all pull a WAN IP on a fresh install with just the default config, no other customization required.
So my question is this. Is there a benefit to forcing the ‘option rapid_commit’ to remain in place for IPFire? Does removing it cause issues with other ISPs and the ability to request and maintain a WAN DHCP lease? It seems to be causing more harm than aiding in function. Even though it should be a standard respected by the ISP we can unfortunately see that it is not in quite a few cases.
I have used three ISP’s in the last 15 years and all three of them had no problems with the presence of the rapid_commit option.
For the other firewalls that worked fine you would need to check if that option was in the dhcpcd.conf file or if they used a different dhcp client that didn’t use that option.
Having the option usable at both ends means that a dhcp connection can be made about twice as quick as normal but if the option is not there for dhcpcd then the normal longer commit process is just used.
Some ISP’s do all sorts of things that are not correct and modifying IPFire to work with the lowest denominator is not something that we intend to do.
While there have been a few cases where that option has not worked, there have been far more where it has just worked.
Interesting, how much time do you think the rapid commit option is saving?
In my case even with it commented out, a forced WAN renewal (dhcpcd -k red0 && dhcpcd -n red0) takes maybe 3 seconds? It takes longer to reload the IPFire services as part of the red0 init than it does to actually request and commit the WAN lease.
I would not suggest a lowest common denominator here. More of a case that the forced option is causing issues and doesn’t seem to give much benefit than I can find?
I think this issue would be particularly hard for most new users to troubleshoot because the WAN IP still shows on the red0 interface with the rapid_commit option enabled. However, IPFire will not route any traffic and WAN lease will expire in a short interval and continue renewing an different WAN IP as it try to restart the DHCP request process. Most users would see a WAN IP and think the issue was somewhere else, not realizing it’s an obscure DHCP option that was enabled on their WAN interface.