After using the 586 platform version for over a while now, I had established a comfort level with the software. However, few updates ago ( i think 152 ) it told me I was using obsolete platform. So i decided to download the x86_64 version and did a new install on a different drive ( i run ipfire off of fast 16gig class 10 U3 SD cards ).
I wanted to used my configs from my longtime 586 so that i would need to re-enter one by one all my firewall rules, etc etc. So I created a .ipf backup file without logs so that it could restore on the x86_64 version.
What a mistake ! The trace graphs ended up with errors. After doing research, turns out I needed to make changes so that the sensor modules would correctly load. After a number of mistakes and 3 full installs over again, I think I’ve got it working, but I’m not sure the FW is behaving as it should.
My main observation was that on the 586 version, when I unplug the RED network cable, after a while i hear the beep that the connection has closed, and when I re-insert it the beep comes up later to indicate connection is again established. When I look at the System->Home status, it toggles between connected and not-connected as I do this.
However, on the x86_64 version, disconnecting the cable has no change; no beeps. Even leaving the RED disconnected for a number of hours doesn’t change the status. It’s almost as if the software is not actually monitoring the RED’s interface card, but some secondary internal virtual interface, which has me a bit concerned. Even all the previously established internet connections remain shown as still established. The RED interface is static IP to the modem/router, and running 153 (but was same with 152)
Anyone have any ideas ?
This route could lead a not so short downtime…
Take a backup of your current x86_x64 installation.
Then do a full revamp of the network segment assignment: change all the adapters-zone associations and the ip addresses.
Reboot the firewall, verify everything works as expected. Then do the revamp again, re-associating old cards to the zones and putting back all the ip addresses.
Do all the tests you need
If something goes wrong or in a way you don’t like, you still have your “not perfect backup” as rollback.
Not sure where you want me to revamp.
At the web I face “Zone Config Nic assignment” , or at the CLI “setup” cmd. In my experience using the web’s zone config has always given me grief.
I’ve done a full new install from scratch, setting up just the green and blue dchp configs, and the red’s static ip config, everything else as default and results come back same. The web iface still shows red status connected even though at CLI the ip neigh goes from ‘reachable’ to ‘stale’ to ‘failed’ as the red cable is disconnected from modem. The ip -s link also shows red as down even though web iface still shows connected. On the i586 ver, the both the web and cli ip cmd seem to be in sync…
There are some other quirks I’ve encountered and taken screen captures. Not sure how to post them here for you to view.
Go to your favorite editor, copy the portion you want, than paste it into the edit frame.
Consider pixel size and weight please
What i read in your posting, you do not change the hardware (only your sd), so all what you have to do is follow the migration (Architecture Change) instructions.
See also here.
Thanks pike. Hopefully get those pics up within next few days.
That link was what i previously used to get the logs to finally work. The logs isn’t the issue at the moment as the system appears to work except for the quirky behaviour when compared to my i586 version. Still investigating.
To all …
In order to compare apples to apples, I downloaded the i586 version core 153 and config the same as I did on the equivalent x86_64 version. Both behave the same !!! They both don’t beep when the RED network is connected or disconnected, even after a lengthy period, and the connection status doesn’t change.
So there is something with my long running i586 version, updated to core 153, that behaves differently (beeps when RED connection is lost, or re-established). I’m going to dig further to try and figure out why.
One thing that I did notice is that on the Web UI Zone config, my running version show’s NONE on the RED interface, whereas both the fresh i586 and x86_64 versions show NATIVE on the given interface.
Will keep ya’s posted.
My x86_64 system beeps when I pull out the red cable and after refreshing the browser page the status changes to connecting…
Then when I plug the cable back in the system beeps and after refresh the browser page shows connected again.
This is how it has always behaved.
If the beep has stopped and the home screen does not update, even after a refresh for both the x86_64 and i586 then that sounds more like a hardware fault. Do you have any other hardware that you could temporarily install on to test out.
I found what is causing the difference.
If set to STATIC IP it behaves as i indicated whether i586 or x86_64 ver.
If set to DHCP then removing the Red’s network will beep on disconnect and reconnect. The status on the home screen goes from “connected” to “connecting”.
My long time running was set to red=dhcp, where as the new installs i was testing was red=static. Not a showstopper as I’ll simply reserve the ip on the modem side and make red=dhcp
The other quirk i had mentioned was the zone config on the web ui whereby red was showing “native” on the new installs, but my running i586 version was showing “none”. This turned out being that on my running version i had allocated a different mac addr for the red (config via web ui). This also has a secondary side effect in that when i unplug the Red, the home status truly shows “not connected”, whereby the new installs simply shows “connecting” as it retries the dhcp.
So, sorry for all the trouble folks…
Thanks for your experience. Maybe this different behavior will be object of revision from developers