Green and blue network down since upgrade core 190

Networking
22

Normal ??? 200000 lines !!! for the kernel logs

what is a martian source ?

Capture d’écran du 2025-01-08 23-48-28
Capture d’écran du 2025-01-08 23-48-28971×767 66.2 KB

23

martian source is a source that is transmitting network packets that the system don’t know how to route or is classified unwanted due to no requests from a client on the network.

What I would do is take screen shots of your settings, and backup settings and make a usb boot with the iso (via rufus) or burn it to a cd and load 190.

I recommend taking screen shots just in case the backup settings file is corrupted.

24

Hello everyone, the green network continues to drop intermittently while the blue one remains stable. Another solution was found by restarting the switch where the firewall/proxy is connected. Some ports on this switch are out of order.

The new switch arrives today; I will keep you informed, but I have the impression that the firewall is not the source of the problem.

Thank you and have a good day to all.

25

Changing the switch is a failure, the green network keeps dropping and I just found this error in the logs : e1000e 0000:00:1f.6 green0: Detected Hardware Unit Hang
I’m continuing the research, I’m tired


26

From memory, on another distro it was recommended to turn off eno and tso using ethtool to stop the hardware hanging. I can’t remember if this was for the e1000 or e1000e driver.

1 Like
27

I agree, I do this : ethtool -K green0 gso off gro off tso off and restart ipfire

I wait


28

It is non-persistent so should be applied after IPF starts.

29

It was a e1000e driver that this was a problem with and that driver has had that problem on and off since at least 2013.

https://community.ipfire.org/t/e10001-detected-hardware-unit-hang/13414/2

That post also mentions about needing to put the ethtool command into rc.local otherwise whenever you reboot those options will be turned on again.

1 Like
30

ok thanks, I put this in /etc/sysconfig/rc.local file, like this :

Capture d’écran du 2025-01-17 10-16-40
Capture d’écran du 2025-01-17 10-16-40693×672 47 KB

31

For the time being, the green network is still standing
maybe was the solution :slight_smile:

32

Here is hoping :crossed_fingers:

1 Like
33

Hello everyone,

The problem seems to be solved with the command ethtool -K green0 gso off gro de tso off

Thank you all f and good day everyone !

34

Good evening, the green network has just fallen with the same error messages without the ipfire restarting
the ethtool command doesn’t look stable?

35

Let’s first check what your nic has for the gso, gro and tso values.

ethtool -k green0

The lower case k will show the values of a range of parameters.

Look for these names

generic-segmentation-offload:
generic-receive-offload:
tcp-segmentation-offload:

Are they showing on or off as the value they are set to.

If they are still showing off then your hanging problem has a different cause than those three offload parameters.

If they are showing as on and you didn’t reboot then you have a nic that is misbehaving.

ethtool is not permanently running. It only runs when you run the command and if the settings don’t stay in place then that is a hardware problem on the nic.

36

Here is the result of the command after the reboot of the server, I will check if the problem is present, the state of the command before the reboot.

Is it in the fcrontab that an action will disable its NIC options?
Thank you.

[root@ipfire ~]# ethtool -k green0 | grep offload
tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
37

No.

You put the command into the rc.local file. That file has a start symlink S98rc.local -> ../../sysconfig/rc.local in the /etc/rc.d/rc3.d/ directory.

So that file, and your command in it, is only run during the boot cycle.

Will wait to hear if you get another identical hang error message and then see what the status of those nic offload parameters are.

1 Like