Hello. First time user of IPFire, I’ve installed it on an old SFF desktop with an extra NIC. Config looks fine and I’ve tested it at work where I can plug red into the network and double-NAT out so I know the NICs etc are OK. At home I have (UK) TalkTalk fibre which is presented as an ethernet port on a BT Openreach ONT. This works fine with my old Teltonika router or I can plug my laptop in (Windows) and get a DHCP IP that routes straight out to the internet.
With IPFire it does not get an IP, it times out on boot. If I try launching dhcpcd again it does the same. If I use dhclient instead it immediately responds with the correct IP but then sits there apparently not doing anything. EDIT: I’ve manually added the missing dhclient-script and I can now get an address with dhclient.
Interestingly, if I boot my laptop into Linux and just use dhcpcd to try and bring up the interface it does the same thing, but if I use networkmanager it works immediately, so it does look like a dhcpcd specific issue? I’ve looked at every similar thread on here that I can find with no luck.
I’ve contacted the ISP to try and determine if there are any specific oddities with how the connection is presented but with no luck. Any help or advice greatly welcomed!
Hi @hobthrust
Welcome to the IPFire community.
In Core Update 159 an updated dhcpcd was installed. That included additional standard options in its conf file. Some forum members have had some issues with some of these, where it looks like their ISP has a dhcp server that is not fully compliant with the RFC standards for dhcp.
If you can provide the dhcpcd logs from your IPFire system it might give some clue as to what is causing the problem. You can get the logs from the WUI menu Logs - System Logs. Then select RED in the drop down box, choose a date when you tried to make a connection with dhcpcd (or you can choose all to have all days in the selected month) and press Update.
Thank you for the response @bonnietwin
Please see here the logs:
| 18:52:05 | dhcpcd[4544] | : dhcpcd-9.4.1 starting |
|---|---|---|
| 18:52:05 | dhcpcd[4547] | : DUID 00:04:43:4e:46:37:30:34:32:4c:4b:57:00:16:36:e3:03:b1 |
| 18:52:05 | dhcpcd[4547] | : red0: IAID e8:4b:80:63 |
| 18:52:05 | dhcpcd[4547] | : red0: adding address fe80::9eeb:e8ff:fe4b:8063 |
| 18:52:05 | dhcpcd[4547] | : ipv6_addaddr1: Permission denied |
| 18:52:06 | dhcpcd[4547] | : red0: soliciting an IPv6 router |
| 18:52:07 | dhcpcd[4547] | : red0: soliciting a DHCP lease |
| 18:53:05 | dhcpcd[4547] | : timed out |
| 18:55:44 | dhcpcd[5273] | : dhcpcd-9.4.1 starting |
| 18:55:44 | dhcpcd[5276] | : DUID 00:04:43:4e:46:37:30:34:32:4c:4b:57:00:16:36:e3:03:b1 |
| 18:55:44 | dhcpcd[5276] | : red0: IAID e8:4b:80:63 |
| 18:55:44 | dhcpcd[5276] | : red0: adding address fe80::9eeb:e8ff:fe4b:8063 |
| 18:55:44 | dhcpcd[5276] | : ipv6_addaddr1: Permission denied |
| 18:55:45 | dhcpcd[5276] | : red0: soliciting an IPv6 router |
| 18:55:46 | dhcpcd[5276] | : red0: soliciting a DHCP lease |
| 18:56:44 | dhcpcd[5276] | : timed out |
I installed the missing dhclient script to allow dhclient to run and tried it, with this result:
[root@prototyp ~]# dhclient -v red0
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit ISC DHCP - ISC
Listening on LPF/red0/9c:eb:e8:4b:80:63
Sending on LPF/red0/9c:eb:e8:4b:80:63
Sending on Socket/fallback
DHCPDISCOVER on red0 to 255.255.255.255 port 67 interval 7
DHCPOFFER of 2.100.251.198 from 2.100.224.1
DHCPREQUEST for 2.100.251.198 on red0 to 255.255.255.255 port 67
DHCPACK of 2.100.251.198 from 2.100.224.1
bound to 2.100.251.198 – renewal in 373 seconds.
The device was able to get out onto the internet, but the firewall / NAT was not operational. I have tried altering the functions.network file to add a function:
dhclient_start() {
# This function will start dhclient on a specified device.
local device="$1"
boot_mesg -n “Starting dhclient on the ${device} interface…”
# Start dhclient.
dhclient -v ${device}
}
Which is called from “red” rather than dhcpcd_start(). This applies an IP address to the RED interface on boot, but again the firewall / NAT isn’t started so I am missing something from your startup sequence.
Lastly, I have tried temporarily replacing dhcpcd with an older version, 9.1.4. The first time I tried to run this it almost worked, but I think some paths have changed, such as dhcpcd.conf:
| 19:10:00 | dhcpcd[4550] | : read_config: /etc/dhcpcd.conf: No such file or directory |
|---|---|---|
| 19:10:00 | dhcpcd[4550] | : dhcpcd-9.1.4 starting |
| 19:10:00 | dhcpcd[4552] | : DUID 00:04:43:4e:46:37:30:34:32:4c:4b:57:00:16:36:e3:03:b1 |
| 19:10:00 | dhcpcd[4552] | : read_config: /etc/dhcpcd.conf: No such file or directory |
| 19:10:00 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:10:00 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:10:00 | dhcpcd[4552] | : red0: IAID e8:4b:80:63 |
| 19:10:00 | dhcpcd[4552] | : red0: adding address fe80::9eeb:e8ff:fe4b:8063 |
| 19:10:00 | dhcpcd[4552] | : ipv6_addaddr1: Permission denied |
| 19:10:01 | dhcpcd[4552] | : red0: soliciting an IPv6 router |
| 19:10:01 | dhcpcd[4552] | : red0: soliciting a DHCP lease |
| 19:10:02 | dhcpcd[4552] | : red0: offered 92.23.174.181 from 92.23.160.1 |
| 19:10:02 | dhcpcd[4552] | : red0: probing address 92.23.174.181/20 |
| 19:10:08 | dhcpcd[4552] | : red0: leased 92.23.174.181 for 900 seconds |
| 19:10:08 | dhcpcd[4552] | : red0: adding route to 92.23.160.0/20 |
| 19:10:08 | dhcpcd[4552] | : red0: adding default route via 92.23.160.1 |
| 19:10:08 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:16:08 | dhcpcd[4552] | : script_runreason: No such file or directory |
I created a symlink from the old dhcpcd.conf location to the correct one, but after that it wouldn’t get an address at all:
| 19:31:10 | dhcpcd[4550] | : dhcpcd-9.1.4 starting |
|---|---|---|
| 19:31:10 | dhcpcd[4552] | : DUID 00:04:43:4e:46:37:30:34:32:4c:4b:57:00:16:36:e3:03:b1 |
| 19:31:10 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:31:10 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:31:10 | dhcpcd[4552] | : red0: IAID e8:4b:80:63 |
| 19:31:10 | dhcpcd[4552] | : red0: adding address fe80::9eeb:e8ff:fe4b:8063 |
| 19:31:10 | dhcpcd[4552] | : ipv6_addaddr1: Permission denied |
| 19:31:10 | dhcpcd[4552] | : red0: soliciting an IPv6 router |
| 19:31:11 | dhcpcd[4552] | : red0: soliciting a DHCP lease |
| 19:32:10 | dhcpcd[4552] | : timed out |
| 19:32:10 | dhcpcd[4552] | : script_runreason: No such file or directory |
| 19:32:10 | dhcpcd[4552] | : dhcpcd exited |
Okay, IPFire is requesting a dhcp lease and there is no reply whatsoever.
In the /var/ipfire/dhcpc/dhcpcd.conf it mentions that some non-RFC compliant DHCP servers do not reply with duid set and that clientid should then be uncommented and duid commented out.
# 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
I would give that a try and then release and rebind the red interface.
dhcpcd -k red0 ( release interface red0 )
dhcpcd -n red0 ( rebind interface red0 )
If having clientid enabled doesn’t help then you could try with both duid and clientid commented out. The previous version of dhcpcd.conf did not have the duid option and the clientid was present but commented out.
If neither of those work then compare the current dhcpcd.conf file with the previous version and try commenting out in turn any options that are new in the current version. Your ISP must be handling one of these options incorrectly and not replying.
Here is a thread of a case that had the problem that the ISP responded with a NAK response to a request to renew a lease and promptly dropped the ip connection.
https://community.ipfire.org/t/hourly-internet-disconnects-after-upgrade-to-core-159/6139
Commenting out
option rapid_commit
solved his problem.
Any change you make to dhcpcd.conf is backed up with the IPFire backup so will be maintained over Core Updates.
EDIT:
This link shows the commit with the differences in the dhcpcd.conf file made in July 2021. The lines with a + are new lines, the ones with a - at the start have been removed and the ones with neither a + or a - have not been changed. You can see the new entries compared with the previous version.
https://github.com/ipfire/ipfire-2.x/commit/8a59f75a51af312b2fb457c473a3db006472bc45
@bonnietwin thank you, it seems that by commenting rapid_commit, clientid AND duid I am able to get online. I’ll swap this device into service now and see how it works out.
Much appreciated!
Glad you were able to get things working again.