I recently got a new Lenovo machine for home server use. Installed Ubuntu and Samba server on it and connected it into a ORANGE zone. I changed the network setup from RED + GREEN → RED + GREEN + ORANGE.
Now streaming a heavy 4K Blu-Ray movie over from Samba server in ORANGE to a machine in GREEN didn’t work as expected as the stream stalled from time to time.
First I thought that I just had bad Samba configuration but after testing various things I noticed that the stalling happened on all the connections that were going over the GREEN interface.
So the problem was with IPFire. After poking around in IPFire I noticed that kernel was throwing these messages:
23:19:41
kernel:
igc 0000:04:00.0 green0: NETDEV WATCHDOG: CPU: 2: transmit queue 1 timed out 5502 ms
igc 0000:04:00.0 green0: NIC Link is Up 2500 Mbps Full Duplex, Flow Control: RX/TX
So the adapter for green0 interface got reset and that caused the odd stalling.
After Googling for a while and trying various things like disabling EEE and ASPM to get the driver working properly I stumbled on a kind of a workaround by creating a bridge interface for GREEN interface and assigning the only unused eth interace with the original GREEN eth interface to the bridge interface and that solved the connection reset problem.
I honestly don’t know why this solved the problem, but it has pretty much no negative impacts so I’m going to keep it.
My best guess is that there is something wrong with the Intel igc driver or firmware.
Anybody have any idea what is actually going on here?
EDIT: Originally I was running Core Update 199 but while testing various things I also updated the IPFire to Core Update 200 test
EDIT 2: IPFire Mini Appliance (2025) uses Intel I226-V (rev 04) 4 port nic.
For me it worked to disable 2.5 G for the I-226V rev04 cards (2 of them) connected to gigabit cards from Meraki AP and FTTH ONT (where red0 is connected).
The I226 network card toward Meraki was already in bridge mode but did not prevented Meraki to flap - Meraki logs were filled with often speed changes.
so this is still reproducible with Core Update 200?
What triggers it? Some peak bandwidth or just a large number of packets in very short time?
I have one at home and never ran into this and of course we have benchmarked the shit out of the device without ever being able to trip the interfaces.
I’m not exactly sure. From the graphs I could tell that while playing uncompressed 4K Blu-Rays over the network it causes pulses of high network activity. Probably due to the way the players are requesting data.
And yes it is reproducible on Core Update 200 to the extent that it doesn’t necessarily immediately flap. It might require something like 5 - 10 minutes of playback for it to trip up. So the flapping is quite random.
Also it is a little odd that the bridge interface somehow solves the problem. After adding the bridge haven’t had any problems. And after bridging the interface and testing that it works properly with the bridge I also changed the network cabling so that I’m now using all of the devices physical interfaces. My main PC now bypasses the Ubiquity switch while connecting to Internet.
And I also verified that it isn’t anything to do with cables. There is only a 30 cm cable going from my Ubiquity 2.5 GB 8 port switch to IPFire appliance and I replaced the cable with a brand new one, just to be sure.
Hmm, random is never good, because that makes it incredibly hard to find the problem…
I had a look through the kernel’s bug tracker and could not find anything that was standing out.
Bursty traffic should not be a problem. A download would be bursty, backups, so lots of traffic. This is not an unusual traffic pattern that should put the appliance and NIC under any kind of stress so that it will reset.
The bridge workaround is valuable to have for now so that you can enjoy watching films that don’t randomly stop for a second. It could change how the kernel buffers data.
If two nics are being bridged together and it works without the problem could there be a problem with a specific nic?
Rather than bridging the nics together could the GREEN interface be set up with the other nic than was originally being used and then see if the issue still occurs.
If yes then the problem is systematic with the nic type, if not then there is a problem with a specific nic.
I used a miniPC with the same network cards for over a year without any problems.
Sorry, but I’m having trouble understanding this thread.
I’d lean towards a CPU issue. What CPU does the IPFire appliance have? What network card does the Lenovo have? Is it connected directly to the IPFire Orange port?
When you say you’re bridging with two NICs on the green port, is your Lenovo always connected to the Orange port, or are you connecting it to the bridge?
What’s the Ubiquity doing in this context?
A diagram of your network configuration would help clarify things.
Sorry don’t have any diagram drawing tool handy right now, but I’ll try to explain.how it was.
The Lenovo is connected directly to the IPFire appliance and the Lenovo machine has a Realtek RTL8125 2.5GbE Controller which connects to IPFire physical port 3.
Ubiquiti switch for the GREEN network was connected to PFire physical port 1.
RED interface is connected directly to ISP router over Ethernet on physical port 4.
Physical port 2 on IPFire appliance was disconnected (unassigned).
Traffic goes from LENOVO → IPFire ORANGE route to→ GREEN → Ubiquity Switch → directly over Ethernet to a desktop PC.
I also have Macbook Pro that is connected over WiFi to TPLink 800BE WiFi7 router (in access point mode) on GREEN which is then connected to the Ubiquity switch.
But it really doesn’t matter which way you access the data from Orange, the Green interface before Ubiquity will trip up regardless of the machine, OS or media player..
Hope this helps to understand the setup.
EDIT: Some pictures to clarify things maybe. Interface assignment and my network cabinet.
[root@veriappelsiini ~]# sudo ethtool -K green0 rx off tx off gro off lro off tso off gso off
[root@veriappelsiini ~]#
Solves the problem. The problem seems to be about offloading features.
Turning offloading back on with:
[root@veriappelsiini ~]# sudo ethtool -K green0 rx on tx on gro on lro on tso on gso on
Actual changes:
tx-checksum-ipv4: off [requested on]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [requested on]
tx-generic-segmentation: on
rx-gro: on
rx-lro: off [requested on]
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp-mangleid-segmentation: on
tx-tcp6-segmentation: on
tx-tcp-accecn-segmentation: off [requested on]
tx-checksum-fcoe-crc: off [requested on]
tx-checksum-sctp: on
rx-checksum: on
[root@veriappelsiini ~]#
And the problem comes back. I think we have found something.
Either the nic hardware is somehow faulty or we have a problem with either the firmware or the igc driver.
Now we only need to figure out what is broken. I will go and have someone test this in the lab.
It probably makes sense that the bridge code is also working around because the packet will be segmented when being transmitted over the bridge and the NIC won’t have to do it.
Hello everyone,
I have the same issue on my IPFire.
The connection from one computer was constantly being interrupted. So I tried to investigate a little:
The connection looks like this:
PC1 (USB - Realtek 2.5GB) → IPFire (4xi225v 2.5GB) → PC2 (Windows 11 - i225v 2.5GB)
Under heavy load, the IPFire network closes with same log as above (tested with iperf3).
However, when I use a Realtek 2.5GB USB on PC2, I have no problems and get the full 2.5GB throughput. The only problem occurs when the two i225v communicate directly with each other .
And by the way, unfortunately the above commands did not help.
Maybe this will help
I performed a data transfer test between Orange and Green on my N100 mini PC with four I226-V (rev 04).
On Orange, an AntiX VM connected via USB 2.5G RTL8156. (192.168.30.10)
On Green, a Windows 11 VM connected via USB 2.5G RTL8156. (192.168.20.10)
I ran a 10-minute iperf3 test in both directions: iperf3 -c 192.168.30.10 -P 8 -t 600 iperf3 -c 192.168.30.10 -P 8 -t 600 -R
(More than 100GB transferred) with no problems detected.
