Traffic to the Internet stops after 30 minutes.
If I restart networking, it will work for another 30 minutes.
In /var/log/messages
Jan 4 14:13:42 ipfire dhcpd: DHCPREQUEST for 192.168.1.153 (192.168.1.5) from b8:27:eb:a2:c3:12 via green0: unknown lease 192.168.1.153.
Jan 4 14:14:46 ipfire dhcpd: DHCPREQUEST for 192.168.1.153 (192.168.1.5) from b8:27:eb:a2:c3:12 via green0: unknown lease 192.168.1.153.
and then
Jan 4 14:15:30 ipfire unbound: [1799:0] error: SERVFAIL <www.google.com. AAAA IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
Jan 4 14:15:31 ipfire ntpd[3259]: Deleting interface #4 red0, 192.168.0.208#123, interface stats: received=55, sent=56, dropped=0, active_time=1768 secs
Jan 4 14:15:31 ipfire ntpd[3259]: 27.124.125.251 local addr 192.168.0.208 →
Jan 4 14:15:31 ipfire ntpd[3259]: 162.159.200.123 local addr 192.168.0.208 →
Jan 4 14:15:31 ipfire unbound: [1799:0] error: SERVFAIL <dialercallinfolookup-pa.googleapis.com. A IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
Jan 4 14:15:32 ipfire unbound: [1799:0] error: SERVFAIL <clients4.google.com. HTTPS IN>: all the configured stub or forward servers failed, at zone . upstream server timeout
Those are dhcp requests coming from a green device to your dhcp server on IPFire.
For your red interface running dhcp you need to look for logs with dhcpcd: specified.
That is the dhcp client on IPFire that requests IP’s from your red interface (ie to your ISP’s dhcp server.
In the logs there must be the indication that a connection has been made as you have it running for 30 minutes but thene there should also be a message in the logs indicating what occurred at that 30 minute period when you lost connection to the internet.
My ISP gives red0 a 1200s lease, which is not renewed and thus expires. After that happens, logging in as root and executing “/sbin/dhcpcd -d red0” produces
#/sbin/dhcpcd -d red0
dhcpcd-10.0.4 starting
chrooting as dhcpcd to /run/dhcpcd/chroot
sandbox: seccomp
spawned manager process on PID 8723
spawned privileged proxy on PID 8724
spawned controller proxy on PID 8725
DUID 00:01:00:01:2c:ef:c8:22:02:45:53:7e:d1:6e
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks PREINIT
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks CARRIER
red0: IAID ff:00:00:02
red0: delaying IPv4 for 1.4 seconds
red0: reading lease: /var/ipfire/dhcpc/red0.lease
red0: discarding expired lease
red0: soliciting a DHCP lease
red0: sending DISCOVER (xid 0xf3122286), next in 4.5 seconds
red0: spawned BPF BOOTP on PID 8762
red0: sending DISCOVER (xid 0xf3122286), next in 8.3 seconds
red0: process BPF BOOTP already started on pid 8762
red0: sending DISCOVER (xid 0xf3122286), next in 15.1 seconds
red0: process BPF BOOTP already started on pid 8762
red0: offered www.xxx.yyy.zzz from www.xxx.yyy.1
red0: sending REQUEST (xid 0xf3122286), next in 3.5 seconds
red0: process BPF BOOTP already started on pid 8762
red0: acknowledged www.xxx.yyy.zzz from www.xxx.yyy.1
red0: probing address www.xxx.yyy.zzz/24
red0: spawned BPF ARP www.xxx.yyy.zzz on PID 8770
red0: probing for www.xxx.yyy.zzz
red0: ARP probing www.xxx.yyy.zzz (1 of 3), next in 1.7 seconds
red0: ARP probing www.xxx.yyy.zzz (2 of 3), next in 1.6 seconds
red0: ARP probing www.xxx.yyy.zzz (3 of 3), next in 2.0 seconds
red0: DAD completed for www.xxx.yyy.zzz
red0: leased www.xxx.yyy.zzz for 1200 seconds
red0: renew in 600 seconds, rebind in 1050 seconds
red0: writing lease: /var/ipfire/dhcpc/red0.lease
red0: adding IP address www.xxx.yyy.zzz/24 broadcast www.xxx.yyy.255
red0: adding route to www.xxx.yyy.0/24
red0: adding default route via www.xxx.yyy.1
red0: ARP announcing www.xxx.yyy.zzz (1 of 2), next in 2.0 seconds
red0: executing: /var/ipfire/dhcpc/dhcpcd-run-hooks BOUND
conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
conntrack v1.4.7 (conntrack-tools): 0 flow entries have been deleted.
Adding [OK]outes…
Reloadi[OK **]**all
forked to background, child pid 8723
dhcpcd_fork_cb: truncated read 0 (expected 4)
Just after the lease is acquired “ps -ef | grep dhcpcd” doesn’t show any processes running.
On the other hand, when a lease is active on red0 with 181, “ps -ef | grep dhcpcd” shows
which was identified by dhcpcd in version 10.0.4 which was introduced in Core Update 182.
It apparently affects aarch64 systems much worse than x86_64 but in both cases it does not affect 100% of systems. There appears to be a timing or related type problem from scanning through the issue details.
If that is the issue affecting you the fixes for it have been put into version dhcpcd-10.0.5
I will raise a patch submission to have 10.0.5 introduced, which should end up in Core Update 184.
EDIT:
Patch to update dhcpcd to version 10.0.6 (the latest version) has been submitted.
I believe I’m seeing this issue with my update tonight. Is there anything I can do to stabilize things or am I better to roll back to 181 for now? I’ve rebooted my firewall twice already…
If the problem is due to that issue in dhcpc-10.0.4 then the only solutions are
Go back to Core Update 181
Test out the Unstable version which has Core Update 184 with the dhcpc-10.0.6 version.
Currently you can’t do the 2nd option for aarch64 as the nightly builder has been failing to complete its build due to a problem with package python3-msgpack.
I have realised what the problem is (I think) and have just submitted a patch to correct that.
I will let you know when that patch has been accepted and the nightly build for aarch64 next successfully run so that you can test out Core Update 184 Unstable.
You might need to re-install to go back to Core Update 181 if there are any not yet identified problems with Core Update 184 Unstable.
I didn’t see any specific mention of a resolution for this with the 183 update. Is it correct to assume that the resolution for this issue won’t arrive until the 184 core update? No pressure on timing, just trying to make sure I don’t hit this issue again.
