IPv6 track interface prefix bug
-
Hello,
I believe there could be a minor ui improvement made. When editing an interface and setting ipv6 to track and providing a prefix id, if the user accidentally sets a decimal id (like 190 instead of hex be), this should be flagged (> 0xff) and errored before saving.It will currently accept it.
Just had a goose chasing evening where no ipv6 was pulling because dhcp6c failed immiediately with exit code 1 because the /var/etc/dhcp6c.conf had an illegal prefix id. None of this is caught or indicated to the user, you just dont get ipv6 anymore.
-
@GenericStudent what was the delegated prefix set to on WAN?
If 0x190 (hex) is an allowed prefix id for the PD from WAN, then there is nothing to complain about for pfSense (I can't test that scenario at the moment myself). Otherwise it indeed would be a input validation bug. In that case you can open a ticket at https://redmine.pfsense.org/.
-
There's definitely something weird here. This is from a CE 2.8.1 system I just checked:
-
@tinfoilmatt if you don't select a WAN interface to track, it won't have any max value (from 0 to ...) to show.
-
@patient0 it was indeed set to 190 (I meant decimal but didnt read it wanted hex), the helper noted range was 0 - ff which my value (interpreted as hex) would overflow
-
Cant upload screenshot from mobile, but WAN has PD size of 56 (vodafone UK FTTP).
When this 190 value is used, dhcp6c exits instantly with error code 1 and none of the interfaces get an ipv6 address.
Interestingly, /var/etc/dhcp6c.conf does state sla-id 190; plus sla-len 8; for this interface in question, which if its declaring it as 8 bits the 0x190 would be an overflow, something pfsense could detect up front / on config generation. At a minimum having more logging to catch the exit code 1 indicating a possible bad conf may help.
-
There is so much left to be desired when it comes to PD...
