I had my IPFire server stop connections twice today after rebooting to pickup the 175 level. I do not know what the cause is. The first time my server seemed to be running but it was not responding to ping, traceroute, or refresh of a web page. Long story short - put up back up server running a lower level and got my connections back. Ran some diagnostics on my normal server to see if it had lost a disk drive or what (Knopix live disk). Meanwhile upgraded my backup server to 175 and rebooted it, and then, put the normal server back in and booted and it came up and everything connected.
While I was working, connected to a data center where I have access to a Mainframe, I suddenly lost connections. Everything was timing out.
I have noticed some having issues with DNS and similar, but this is something DNS has already been resolved for and ports and ethereal stuff has all been exchanged.
All this said, I know enough to be dangerous, but not enough to figure this out. What is needed to find the problem? Here is the last thing I saw of interest before the reboot: IPV4: FIB TABLE does not exist, followed by RTNETL answers No such file on directory. Don’t know if this is related.
Yes, I had seen those same things. And this is the best I can do for diagnostics for when this happened.
But I’ve had it happen twice in one day since booting 175. I don’t know what causes it, so I can’t work to recreate it. And I really don’t like intermittent problems. But it appears that this is what we have.
And I did have IPF spitting out some message about a file problem, so I did a reboot forcing fsck. Maybe that fixes it. But I didn’t have any file system errors until I loaded 175. Just say’n’.
Currently 25% of all IPFire systems that have the fireinfo option turned on are running on CU175.
If it was an intrinsic issue with CU175 I would be expecting to see many more posts on the topic. Also nothing was flagged up on this during the Testing phase.
If the problem happens again then I would look at the following actions.
Check on the WUI menu Network - Domain Name System and see if the status at the top left of the page show Working in green or Broken in red.
Press the Check DNS Servers button and you will get a status indication for each entry separately. If any or all of these are showing Error in red then hold the mousepointer over the error word and you will get a message about the cause of the error which might give some pointer to the cause.
I would also then go the the WUI menu Logs - System Logs and in the Section: drop down box select RED then select All for the Day: drop down box and then press the Update button. If there has been some problem with the red connection to your isp you will see some messages that can give a clue to what the problem might be.
You can also check the internet connection without worrying if the DNS server is working or not by running the following command in a terminal on IPFire. ping -c4 81.3.27.38
This will ping the ipfire.org server directly by its IP address. You should get 4 responses back with a 0% packet loss.
If after some while you get a response with 100% packet loss then it indicates that you do not have a connection to the internet. In that case I would expect there to be some messages in the RED logs section about why the internet connection has failed.
The above gives a good starting point of checks to make if you lose your connection to the internet and the results from those will help guide as to where to look next.
Just so you know, I did do Ping and traceroute against Google and DNS did not resolve when this occurred (from my W11 Laptop). Also, my connection to an IBM site where I was working remotely dropped and could not be re-established. All devices that were streaming failed within seconds of each other.
The W11 laptop I was running could not refresh its IP address lease… Ping of the ipf server (192.168.1.1) failed.
Yet, from all outward appearances, the box was running, but since I couldn’t connect to it, I powered it off, and got my backup server (running ipf) and got our LAN back up. The rest is in prior postings.
It appears that the problem is solved. It looks like it was related to a file system error that ipf detected and wanted the fix option run with a reboot. Since I did that the problem has not reoccurred.