Hourly internet disconnects after upgrade to core 159

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.

Hi @kuni

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.

Hey, thank you. You’re right, this could be the cause. I will check that now.

#clientid
#duid

no offering.

clientid
#diud

no offering.

So this must be some other changes in that configuration file.

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

https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/21

2 Likes

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.

1 Like

Glad you are working again.

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.

Ah, you think this is mistyped? Will check that later.

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.

Will wait to hear back from you.

You’re right. With
option rapid-commit
i got my offer too. So there is a mistype.

2 Likes

Hi,

You’re right. With
option rapid-commit
i got my offer too. So there is a mistype.

can You check the logfiles - it could also be that THIS is just ignored as THIS is the wrong spelling… just an idea

Cheers, Stephan

That’s right! The option is called rapid_commit. If there are problems with this option set, the problems are on the server side (ISP).

1 Like

Which ISP is this?

in my case: Stadtwerke Rosenheim (komro), fibre
i got the IP-Adress (mostly) but can’t ping anyone
now running with #option rapid_commit