I’m a bit frustrated with IPfire, and hoping I can find a solution before I consider trying another router distro. Since I’ve bought my APU2D4 router from Teklager, I’ve used IPfire on it, and it has never been stable. At some point, red refuses to connect. And yes, I am shutting it down in the proper manner. It used to go months at time working fine, but in the last few months I’m lucky to get a few weeks out of it before it stops working. Re-installing IPfire always fixes the issue. And I’ve done that so many times since I’ve bought this router it’s not even funny. I’m almost at my wits end with this. I just want this to work reliably.
I’m using the latest supported BIOS version 4.12.0.6 installed via pcengines-apu-firmware in IPfire. IPfire is the current version 2.25 core update 155.
I contacted Pawel at Teklager to see if perhaps I was looking at a hardware issue, and he had me look /var/log/messages on IPfire. Here’s what I found:
Mar 22 12:58:01 ipfire dhcpcd[13529]: red0: waiting for carrier
Mar 22 12:58:02 ipfire kernel: igb 0000:02:00.0 green0: igb: green0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Mar 22 12:58:04 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 22 12:58:04 ipfire dhcpcd[13529]: red0: carrier acquired
Mar 22 12:58:04 ipfire dhcpcd[13529]: red0: IAID b9:53:e2:a0
Mar 22 12:58:04 ipfire dhcpcd[13529]: red0: adding address fe80::20d:b9ff:fe53:e2a0
Mar 22 12:58:04 ipfire dhcpcd[13529]: ipv6_addaddr1: Permission denied
Mar 22 12:58:04 ipfire dhcpcd[13529]: red0: soliciting a DHCP lease
Mar 22 12:58:04 ipfire dhcpcd[13529]: red0: soliciting an IPv6 router
Mar 22 12:58:05 ipfire dhcpcd[13529]: red0: offered 65.183.137.205 from 204.13.41.66
Mar 22 12:58:05 ipfire dhcpcd[13529]: red0: probing address 65.183.137.205/24
Mar 22 12:58:07 ipfire dhcpcd[13529]: red0: carrier lost
Mar 22 12:58:07 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Down
Mar 22 12:58:07 ipfire dhcpcd.exe[13578]: red0 has been brought down (EXPIRE)
Mar 22 12:58:11 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 22 12:58:12 ipfire dhcpcd[13529]: red0: carrier acquired
Mar 22 12:58:12 ipfire dhcpcd[13529]: red0: IAID b9:53:e2:a0
Mar 22 12:58:12 ipfire dhcpcd[13529]: red0: soliciting an IPv6 router
Mar 22 12:58:13 ipfire dhcpcd[13529]: red0: soliciting a DHCP lease
Mar 22 12:58:13 ipfire dhcpcd[13529]: red0: offered 65.183.137.205 from 204.13.41.66
Mar 22 12:58:13 ipfire dhcpcd[13529]: red0: NAK: requested address not available from 204.13.41.66
Mar 22 12:58:13 ipfire dhcpcd[13529]: red0: message: requested address not available
Mar 22 12:58:13 ipfire dhcpcd.exe[13753]: red0 has been brought down (NAK)
Mar 22 12:58:14 ipfire dhcpcd[13529]: red0: soliciting a DHCP lease
Mar 22 12:58:31 ipfire dhcpcd[13529]: timed out
Mar 22 12:58:31 ipfire dhcpcd[13529]: dhcpcd exited
The above message is back when this issue started happening, and I could still get it to connect by shutting down IPfire and restarting it. As of this morning IPfire will not connect at all even with restarting it several times.
Oddly enough, the same log shows a different message than above.
Mar 29 08:25:41 ipfire dhcpcd[13378]: red0: carrier acquired
Mar 29 08:25:41 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 29 08:25:41 ipfire dhcpcd[13378]: red0: IAID b9:53:e2:a0
Mar 29 08:25:41 ipfire dhcpcd[13378]: red0: adding address fe80::20d:b9ff:fe53:e2a0
Mar 29 08:25:41 ipfire dhcpcd[13378]: ipv6_addaddr1: Permission denied
Mar 29 08:25:42 ipfire dhcpcd[13378]: red0: soliciting a DHCP lease
Mar 29 08:25:42 ipfire dhcpcd[13378]: red0: soliciting an IPv6 router
Mar 29 08:25:43 ipfire dhcpcd[13378]: red0: carrier lost
Mar 29 08:25:43 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Down
Mar 29 08:25:43 ipfire dhcpcd.exe[13426]: red0 has been brought down (EXPIRE)
Mar 29 08:25:46 ipfire kernel: igb 0000:01:00.0 red0: igb: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Mar 29 08:25:46 ipfire dhcpcd[13378]: red0: carrier acquired
Mar 29 08:25:46 ipfire dhcpcd[13378]: red0: IAID b9:53:e2:a0
Mar 29 08:25:46 ipfire dhcpcd[13378]: red0: soliciting an IPv6 router
Mar 29 08:25:47 ipfire dhcpcd[13378]: red0: soliciting a DHCP lease
Mar 29 08:26:09 ipfire dhcpcd[13378]: timed out
Mar 29 08:26:09 ipfire dhcpcd[13378]: dhcpcd exited
Is there anything to be done that will make IPfire stable on this hardware platform?
The problem on the WAN side can originate in problems on both sides of the line, your ISP and your IPFire system.
To check the ISP side, you can try to connect a client directly to your modem ( I suppose it is a cable internet/DOCSIS modem ). In case of a DOCSIS modem restrart the modem, usually the connection is related to the MAC of the endpoint ( your IPFire). If the ISP side is ok, you should get an IP without problems ( and the error maybe the NIC of your APU ).
To check the NIC you can change the association of the interfaces ( your green NIC becomes the red NIC and vice versa ).
I recommend to do the IPFire tests from the serial console of your APU. A SSH console depends on the proper networking, which is to be examined.
My ISP connection does work, as I switched the network cable directly to my Linux desktop PC that I’m currently using. It is fiber to the building, so no user accessible modem. I get an Ethernet port from the wall of my apartment that goes directly to my router, or desktop in this case since the router stopped working.
With this latest install of IPfire I did change the NIC being used for RED. If this were a hardware NIC problem, I would not think that reinstalling IPfire would suddenly make it work again regardless of which NIC is being used. Am I wrong about this?
A reinstall doesn’t change anything, if you use the sam settings. That’s right.
But you could change the relations <NIC,interface> with setup.
If the error goes to green, one NIC is defective.
Ok, so I swapped the NIC assignments of RED and GREEN in setup. And then restarted IPfire. And RED shockingly connected to the internet. It’s working just fine at the moment.
I think you misunderstand me. Both RED and GREEN connect. I used the router normally for the rest of the day into the evening after swapping the NIC assignments, then shutdown normally. And this morning they both connected normally and I’m using the router.
I do not really know much about FTTH. But your description “fibre comes to the house, internet is provided at an ethernet outlet” supposes a kind of modem between fibre and ethernet.
Maybe your provider registers the MAC of the end equipment. If you change the NIC assigments, your end point changes ( MAC is the identification ) also, thus the end point isn’t allowed to get an IP or access the internet.
I know the practice for Cable Internet ( DOCSIS ) here in Germany. The modem is registered at the provider for a specific client, The modem itself identifies the end point at boot up and allows this end point only to access the internet.
Linux report that the nic has lost the link on the cable. This could be a bad nic, cable or the device on the other end. Also a corroded pin on a jack is possible.
I also had one time problems with an unstable powersupply of an APU that caused Link losses on the a Nic.
Yes, there is a non-user accessible modem in the building that changes from Fiber to wired ethernet. Only the ISP have access to this both physically and remotely. If they did register the MAC address, then my understanding is that swapping NIC assignments on IPfire would not have worked if the MAC address for each port is different. And neither would physically switching the WAN cable to my desktop.
Arne.F,
The RED link never drops after getting a connection. Only after shutting down and powering back on once this problem starts happening. And to me it doesn’t explain why swapping RED and GREEN NIC assignments got it working again, and why re-installing IPFire always gets it working again.
you are right. I just forgot your test with the desktop computer.
Then I believe in Arne’s thought about faulty connections. Maybe it is a cable or a connector.
I didn’t check how the IPFire system behaves after a physical loss of connection. Would be interesting to check whether a reboot is necessary to establish the WAN side in a complete state.
Sounds familar to me but not on an apu2. I had a similar effect on an other box with Realtek nic’s but the APU2 should have Intel nic’s.
On this machine the dhcpcd runs in a timeout exact in the moment it got the lease and drop it. So it works at installation but not always at restart/reboot.
If you run into this again try to add:
TIMEOUT 60
or more into /var/ipfire/dhcpc/dhcpcd.conf.
I’ve never dealt with a faulty network cable or connector beyond a pre-made store bought cable that didn’t work at all. I’d assume if that was the case I’d notice either the connection dropping while the unit is on, or poor network performance, neither of which I’ve seen on my router or when WAN is connected directly to my desktop PC. I just powered up my IPfire router again and it connected normally. Out of curiosity I pulled the WAN cable out will it is up and running and it gives the series of downward beeps saying it is not connected. Gave it thirty seconds or so and plugged it back in, and it promptly and successfully reconnected with the upward series of beeps. The thing is, I never thought to try this when IPfire was not connecting RED.
Arne,
You are correct. The APU2D4 does have Intel NIC’s. Thank you for that configuration change. I will try that setting in differing amounts when this problem comes up again and report back.
Also, Pawel from Teklager did mention the possibility that my ISP has configured their DHCP server incorrectly. Does this occur to either you of as a possibility? And if so, how would I check into that more, or even address that with them?
Actually I think your suggestion is correct. Most likely the IPS provider have an MAC filtering switch (ethernet/fiber). I have more or less the same setup APU2 + ethernet + ISP switch. My problem went away after suggesting the IPS 2nd line support to reset the MAC filtering i.e. allow my RED nic mac address.
I am still not certain why it became blocked in the first case. But I found that there have been issues with how the APU2 board BIOS handle DHCPNAK. For more info see ipxe in github.
I do not believe it is problem with the BIOS.
ipxe handles the booting of an OS from a remote repository.
A full installed IPFire system handles DHCP requests/responses by itself.
