I got a new router to replace my existing IPFire installed device. This one has i226-V NICs as the only real difference. I have installed IPFire on the new device without issue, including the restore from the old device. Everything appears to have gone right.
I initially tested the new router by plugging red0 into a green port on the old router, and everything worked fine, I was assigned an IP (DHCP assigned on my actual internal network), and connected outbound just fine. With everything in order, I swapped out the old router with the new, removing the old completely. red0 never changes status to UP, and working with my ISP, they never see a device connecting.
When I put the old router back in, it connects no issue. When I again connect the new router’s red0 to a green on the old router, it connects no issue. I checked that my ISP is not applying port security to lock the connection to a known MAC address either. I have tried each of the ports on the new router, all work just fine when assigned as red0 to connect to the old router, but fail to communicate with the ISP directly. Closely watching the system load, I see no fails, and no errors in the logs, it just appears like there is nothing plugged into the port.
The I226-V can negotiate a bandwidth of 2500 Mbps.
You haven’t mentioned your ISP’s device. Is it a router, an ONT, or a modem? What is its bandwidth?
It’s possible that the network card in that device can’t provide 2500 Mbps and isn’t automatically scaling up.
Try forcing your red0 port to 1000 Mbps in the console using the command:
ethtool -s red0 speed 1000 duplex full autoneg off
then /etc/init.d/networking/red start
If that works, you’ll need to add this command to /etc/sysconfig/rc.local ethtool -s red0 speed 1000 duplex full autoneg off
Edit: Or maybe it’s just a cable issue; try a Cat6 cable.
So I have tried all of the different suggestions, changing speed, autonegotiation, assigning MAC address, different cables, etc.
Overall situation, ISP is fiber-based with an ONT at my rack providing 1 gig connection. The connection is not locked to the router’s MAC address, so unfortunately assigning MAC address didn’t work.
Changing settings from using ethtool didn’t get anything different to happen. I tried setting the speed at various levels, autoneg off and on at each level, but none of that succeeded.
I got into the logs when I had the new router plugged into the old, and there were no issues. The connection on red was fully established, and plugging a laptop into the assigned green port i could access the WUI, and get on the internet no issue. When I removed the old router and plugged the new directly into the ONT the red connection failed. Once everything came up, I navigated to the WUI and pulled up the log, and every time (including the above attempts with speed/autoneg) the logs just showed it timing out as below:
The log for RED stops at that point for a failed connection after trying each of the various suggestions everyone had. Will keep digging around and see if I can figure something out.
The log is telling me that IPFire has not even got a carrier signal. It never got to the stage of even being able to request an IP.
Changing anything on IPFire will not make any difference to this.
Either there is an issue with the cable being used between the red nic and the ONT ethernet connection, or you have the cable connected into the wrong nic.
Are you certain that the nic that you are connecting the cable from the ONT to, is the one that you have assigned to the red interface during your setup?
The NIC and cable are working fine. Connecting the new router’s red to a green on the old router it connects without issue, and can reach out through the old router and run it’s own green. When I unplug just from the old router, using the same cable that just worked and connect to the ONT it times out. But then plugging the old router back into the ONT, that connects without an issue, and then plugging the new router back into the old, that connects without issue.
The information on the “Waiting for carrier” message timing out gives the following
What Does "Waiting for Carrier" Mean?
When you see the message "waiting for carrier" in dhcpcd, it indicates that the network interface is trying to establish a connection but is not detecting a physical link. This can happen for several reasons, including:
The network cable is unplugged.
The network interface is disabled.
The network switch or router is not powered on or malfunctioning.
When you connect the IPFire router direct to the ONT and reboot it do both the status and data leds on the nic port flash.
If they flash but the dhcpcd package does not find any carrier then I have no idea how that could happen.
Neither LED is flashing when I plug straight into the ONT, but they do when I plug into anything else. The only option from those three is that it is misbehaving, but it also works just fine when plugged into the old router, so that doesn’t really make sense either.
That at least makes sense with regard to the “Waiting for carrier” message.
That is definitely the peculiar thing. I have no quick ideas what could be causing that other than some mismatch between the two sets of nics. Never experienced that myself, so no ideas on potential causes at this point.
Trying to put a network switch between the ONT and the red nic, as suggested by @pscar13 in an earlier post in this thread would be worth testing as that might buffer whatever might be causing the problem and act in a similar way as the old router as a stage in between the ONT and your IPFire hardware.
I have done a bit of searching and have found quite a few reports of users with i226V nics having problems with them. Some of those reports included the nic going dead but in slightly different circumstances to you.
Some of the reports included responses from Intel acknowledging there were some issues.
I have not been able to find any reports that are similar to yours but I have found a range of reports, some with Linux, some with Windows, some after an NvME drive had been connected. Lost of different situations but all related to the i226V and the leds ending up dead after some action or some change.
It might be that there is some hardware issue that occurs under specific (but unknown) circumstances.
None of the workarounds that I have seen mentioned ended up consistently solving the problems.
I know that Intel have had problems in the past with nics with Power Management options and in those cases the issue was fixed by disabling the power management options via ethtool or via the bios.
You could maybe try and search for how to disable power management options on the i226V nics and test those out to see if that helps or not.
It clearly is not as simple as i226V nics connecting to an ONT.
I have the IPFire new Mini system which has the i226V nics and I connect my red nic directly to the mode convertor (which I believe does the same sort of things as an ONT) that changes the light signals from the fibre into Ethernet electrical signals and I have no problem with the connection between red and the mode convertor Ethernet socket and my internet connection has been rock solid over the last 6 months of use.
