Roy’s guys are slow at publishing things, I wonder if they have updated since then.
Looking at the commit log:
Looks like they are addressing what I mentioned earlier.
Roy’s guys are slow at publishing things, I wonder if they have updated since then.
Looking at the commit log:
Looks like they are addressing what I mentioned earlier.
The current version in the dhcpcd github site is still 10.2.2, which we have in CU193 Testing as mentioned in my last post so, no they have not updated yet.
There have been 4 more commits since version 10.2.2 was released on Feb 25th 2025.
I guess we are in the “yay we released it ! but its somewhat broke stage”.
No. Where did you get that impression?
It’s a dedicated mini PC and while it does have Intel NICs, they are built-in so I can’t remove them. As far as I recall it has never had another OS installed. I purchased it without an OS and it’s only ever had IPFire on it.
I’m just trying to rule out something that may be going on, but I think the Intel drivers need to be gone through. Problem is these drivers are not specific to IPFire, because everything Linux and BSD build off the same driver source code and other router OS (Like PFsense, OPNsense, OpenWRt and even OEMs if they use the hardware) will be affected. I am wondering if other people discovered this on other platforms. If so, then it has to be a driver.
@dr_techno Thank you for the suggestion, but I’m not sure what to make of it.
IPFire is using intel kernel drivers (“igb” for my NICs). Even if there had previously been a different OS installed, any drivers that OS used should have no relevance now.
If there was a more general problem with the open source intel kernel drivers I would expect it to have been noticed and fixed by now.
If anything the first of the two problems I have seems to be related to the Bridge connection from IPFire to my ISP. I’d like to understand how IPFire detects a RED DHCP-based connection dropping out.
Well its the same as DHCP client on most Linux os. So if that was broke it would be broken everywhere which it isn’t. However, I’m not ruling out corrupted firmware since port control for DHCP is handed off to firmware that holds the listening port open and it may not flag the -5 error (bad checksum) when the driver is started.
Without hearing the unconfirmed rumor that windows is flashing an area of intel nics, the process of elimination has already determined that the card needs to be replaced or its firmware needs to be re-flashed. Since I’m assuming this is built onto a board, you need to get the proper flash utility from Intel for that and flash it.
For a blind test, take a usb ethernet adapter and plug it in. If the problem goes away you know its a firmware issue.