Bug #5957
closedFix for missing route creation during reboot for delegated prefixes (given by DHCPv6 to sub-routers before the reboot)
0%
Description
I have noticed that if pfSense reboots then routes to sub-routers are not re-created.
Meaning subnets given by DHCPv6 using prefix delegation to sub-routers stop to work after pfSense reboots.
The reason for this is that routes are currently only created when there are changes to the lease file content.
Meaning first when a random dhcp6 client is asking for a new lease or a change to an existing lease dhcpleases6 will detect this and recreate all routes to active leases.
- The sub-router is responsible for its own routes from its subnets and out through its WAN interface
- whereas pfSense is responsible for the routes in the direction towards the sub-routers.
- As long as (active) leases are valid in the lease file pfSense should make sure routes to sub-routers exist.
- What happens if something deletes the lease file or e.g. the subnet prefix (global routing prefix + subnet ID) of the pfSense WAN changes or the subnet prefix that pfSense delegates from changes I do not know, but in this case where the lease file contains (active) leases I assume it is irrelevant; something else must choose e.g. to delete the lease file if the subnet prefix changes.
I have tried to analyze the problem and I have found that simply touching the lease file (after a reboot of pfSense) is enough like:
touch -c -m /var/dhcpd/var/db/dhcpd6.leases
, meaning only if file exists (-c) then change modification time (-m) of the lease file.
(So -c to avoid creating the file if someone/something wanted it not to be there.)
This triggers dhcpleases6 to recreate the route to my sub-router. So I have come up with these two alternatives:
- Using this 'hack' and setting it into:
https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558
between lines 1558 (meaning after "mwexec("/usr/local/sbin/dhcpleases6...") and 1559:mwexec("/usr/bin/touch -c -m {$g['dhcpd_chroot_path']}/var/db/dhcpd6.leases");
, e.g. with a 'sleep 1;' in front of '/usr/bin/touch' to make sure dhcpleases6 has deamonized itself.
I have tested this by adding the line to services.inc however without using 'sleep 1;' and it works on all the reboots I have made until now. - Adding some lines between lines 538 - 539 (untested):
else { system(command); }
to dhcpleases6.c ( https://github.com/pfsense/FreeBSD-ports/blob/3faff56ee509fbcfc167c7c6d41f810239cd4e4f/sysutils/dhcpleases6/files/dhcpleases6.c#L538 )
Note - 'command' points to: /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php|/bin/sh
as shown in https://github.com/pfsense/pfsense/blob/b5fcc2b5e4d13a766a3965f0997ccde450051757/src/etc/inc/services.inc#L1558
I will let you decide which of these two suggestions are more appropriate.
Again, thank you all for your time!
Updated by Chris Buechler over 8 years ago
- Status changed from New to Feedback
- Assignee set to Chris Buechler
None of my networks were quiet enough that I'd noticed that. I confirmed the noted change to dhcpleases6 makes it add the routes upon startup. Committed that minus some debug logging I had going, should work when that hits snapshots later today.
Updated by Chris Buechler over 8 years ago
that's in the latest snapshot now. Works here, Anders could you please confirm.
Updated by Greg M over 8 years ago
Hi!
I have also some issues with route6:
/rc.filter_configure_sync: The command '/sbin/route change -inet6 default fe80::2c1:64ff:fed8:3a00' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable route: writing to routing socket: Network is unreachable change net default: gateway fe80::2c1:64ff:fed8:3a00 fib 0: Network is unreachable'
Is this connected?
Updated by Anders Lind over 8 years ago
Thanks Chris! It works!
I made 3 reboots with the latest snapshot and in all 3 reboots pfSense recreated the route to my sub-router!
Great! Thanks again!
Greg: I am not familiar with what rc.filter_configure_sync does nor with FIB.
That type of address is a link local address so I guess it should be on link with your pfSense, but maybe it tries to change the default route to this fib device and fails? Is this device properly configured? (I'm just guessing. I have no idea what it is used for.)
Updated by Chris Buechler over 8 years ago
- Status changed from Feedback to Resolved
Thanks Anders, also checked out fine on a couple more systems here.
Greg M wrote:
Is this connected?
Unrelated. Please post specifics to the forum.