Since core update 178 I recognize several “drops” of the RED connection.
The Internet connection does not drop, only the red network connection reconnects.
It looks like if you would unplug / replug the network cable and I realized this as the status indicates the connection time. It lasts 1-2 minutes until internet is back again available.
This issue never happened before since years running IPfire and it just happens since core 178.
Has there been any change or anybody has a clue what the reason could be?
The logs you posted first show a restart of syslogd at 07:37:56.
This can be initiated by system restart between 07:37:12 ( the last dhcpd log ) and 07:37:56.
Your second post shows the restart of suricata and unbound as part of the boot process.
Therefore, I do not think you loose internet connection only. The whole system restarts. The state of the logs seem to show a short power loss. A normal reboot would log its events to syslog.
Another idea. Do you have some kind of watchdog activated?
Hi, after 4 days running, similar behaviour now.
The system does not reboot. No watchdog activated here.
I will further observe, but it is strange as the system was running long time fine, just after 178 update this behaviour occurs.
Back in post 3 it is said that the connection is a Static IP connection. My understanding is that would still be via dhcpcd but I don’t know what would be in the logs for the RED connection. I have only ever used a dhcp connection.
I will try and find some time to set a vm IPFire up with a static address and see what is put in the logs when IPFire starts and makes a connection unless someone else knows what occurs from their own experience.
In post 6 Bernhard has identified that syslog is restarting and that would not occur as part of just dropping a RED connection. syslog is restarted as part of a reboot. Maybe looking in the /var/log/bootlog for any messages leading up to around and just after Sep 19th, 07:37:12 to 07:37:56 would help see what is happening.
Suricata looks to have been restarted. Unless you disabled the IPS on the WUI and then enabled it again then those messages, I believe are only seen when a reboot occurs.
The ERRCODE messages are just warnings saying that some of the signatures that have been provided are checking the flowbit but the flowbit has not been set so it is a pointless check. The signatures don’t need to check for the flowbit or they should ensure that the flowbit is set. This has been seen is various signatures for a long time but the signature providers have not corrected the involved signatures but it doesn’t stop the signatures fulfilling their main purpose.
I can’t easily see how Core Update 178 would trigger dropping a RED connection.
Core Update 178 was a security release with very limited changes - only some kernel fixes for the latest AMD and Intel cpu hardware vulnerabilities and a fix for a bug in Hyper-V virtual system that prevented those users booting at all with Core Update 177. https://blog.ipfire.org/post/ipfire-2-27-core-update-178-released
The file /var/ipfire/dhcpc/dhcpcd-red0.info would give details of the IP’s etc that were received from your Fritzbox modem but I would suspect that for a static connection that file would just contain the IP’s, gateway,dns etc that you provided when you did your setup of IPFire.
I am going to try and get some time to set up a static connection vm and see what is in that file and what shows up in the logs.
In fact there is no file /var/ipfire/dhcpc/dhcpcd-red0.info
All files in /var/ipfire/dhcpc/ seem to have the timestamp of the initial installation.
I also checked the /var/log/bootlog.x files:
Beside the manual reboots triggered by me yesterday and this morning, I can see the last bootlog file is 10 days old. So this would not be in line with the previous “drop” 4 days ago.
I scheduled now a daily reboot in the morning. Maybe this will help to be stable during the day.
Will keep you posted.
I have managed to set up a static address vm system.
That is what I have also found.
Having thought about it for a while, I think that with a static address specified then nothing needs to be provided from external because everything is defined within IPFire and stored in /var/ipfire/ethernet/settings
This stores the red IP Address, the red gateway IP address and the red subnet address.
When IPFire is rebooted then the red nic has the appropriate IP address assigned to it.
With a dhcp connection the ISP server is asked fort an IP address which is then assigned to the red nic. With a static connection IPFire just assigns the defined IP address to the nic in the same way that it assigns the IP addresses to the green, blue and orange nics.
When the problem happens again, run ip address show which will show if your red nic is UP and what IP address is assigned to it.
If the nic is UP and your static IP address is assigned to it then I think the connection problem is unlikely to be with the red interface in IPFire but more likely some problem in your fritzbox modem that is dropping the connection.
Ok, I will try. But as said, the issue lasts only for 1-2min and then its up again.
Sometimes not even directly recognized, but during web conferences the drop is clearly recognized …
Btw, Fritzbox shows also nothing unusual. However, as there was also a firmware update lately, it could also have some relation to that. Will observe and post update.
Thanks!
FYI - if I physically unplug the ethernet cable I see this in the message log:
Sep 24 10:39:15 ipfireAPU kernel: igb 0000:04:00.0 red0: igb: red0 NIC Link is Down
. . .
Sep 24 10:44:29 ipfireAPU kernel: igb 0000:04:00.0 red0: igb: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
I do not know if your issue will error in a similar way.
