Thank you Adolf, writing a sentence describing the situation accurately is crucial for a proper understanding. In my head I was imagining a sort of negotiation between client and server on the topic “should we go with a two-ways or four-ways handshake”. Wrong mental model. What happened is described way better by your summary. You were right to point that out.
Is this a problem with fixed IPs or
both fixed and DHCP served IPfire?
Is there a note in the wiki on this situation?
1 Like
It’s only for the dhcp connections.
For a static IP you put that into IPFire once and after that IPFire just sends packets via the gateway IP that you have specified. No communication is required between your ISP and IPFire.
No. Not sure how useful that would be. There have been around 4 or 5 people that have mentioned this solution as working for them. There are more that have problems with the time delay between modems and IPFire when booting and with modems that supply a local IP first before changing it to the public IP and there is nothing on that in the wiki either.
You are welcome to update the wiki.
2 Likes
Good point Shaun.
@jon @bonnietwin I have written a note in the final part of the install process. Please let me know if it is all right.
EDIT: also I created a link to dhcpcd in “noteworthy packages” and an entry documenting the daemon.
2 Likes
@cfusco I made a small edit to the dhcp line as dhcpcd is a dhcp client only package.
The ISP will be using a dhcp server, likely the ISC dhcp server as used by IPFire for the IP leases on the green and blue lan.
1 Like
yes, good point. Could you also check the page I just created for dhcpcd?
Just an update after the update ( 180 )
It seems that dhcpcd.conf is back to original state. I need to kiil the rapid_commit forever so I edited /etc/init.d/rc and added as the last line
/bin/sed -i 's/^option rapid_commit/#option rapid_commit/' /var/ipfire/dhcpc/dhcpcd.conf
Now it seems to be ok, got an Omada AP as a new toy…
In CU180 a new version of dhcpcd was installed. However the dhcpcd.conf file is backed up in the IPFire backup file and the core update script does a backup command before doing the update.
So after the update to CU 180 you just needed to do a restore from the backup file.
As a precaution before doing any Core Update I run the IPFire backup first with full logs and then download that file to the machine I am ru8nning the WUI from. That way I have a backup available off of IPFire in case something goes wrong with the update.
2 Likes
Additionally, downloading the latest IPFire ISO before updating can be beneficial. This is useful if the router becomes inaccessible, preventing Internet access needed for the restore process. I personally maintain a backup mSATA mirror of my drive for extra safety.
2 Likes