Project

General

Profile

Actions

Bug #5957

closed

Fix for missing route creation during reboot for delegated prefixes (given by DHCPv6 to sub-routers before the reboot)

Added by Anders Lind about 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
DHCP (IPv6)
Target version:
Start date:
03/06/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

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.

I have the following assumptions (just correct me if I am wrong):
  • 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:
  1. 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.
  2. 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!

Actions

Also available in: Atom PDF