Bug #4207
closedIPv6 - PHP error "Warning: inet_pton(): Unrecognized address" in DHCPv6/RA (possibly due to bad format of IPv6 address?)
0%
Description
Short Version¶
I received the following error while trying to configure DHCPv6/RA.
Details¶
Error¶
Warning: inet_pton(): Unrecognized address 2001:470:XXXX:YYYY:ffff:ffff:ffff:ffff in /etc/inc/util.inc on line 710 Warning: inet_pton(): Unrecognized address 2001:470:XXXX:YYYY:ffff:ffff:ffff:ffff in /etc/inc/util.inc on line 710 Warning: inet_pton(): Unrecognized address 2001:470:XXXX:YYYY:ffff:ffff:ffff:ffff in /usr/local/www/services_dhcpv6.php on line 238 Warning: inet_pton(): Unrecognized address 2001:470:XXXX:YYYY:ffff:ffff:ffff:ffff in /usr/local/www/services_dhcpv6.php on line 250
Behaviour¶
Entering various IPv6 addresses for the Start Range and End Range fields, hitting save. At some point (I'm not sure if it happened more than once) I got the error above, dumped as a PHP inline error, not a "pfSense error"
It is quite possible that the screenshot below shows an invalidly formatted IPv6 address; I'm an absolute beginner with IPv6.
I've attached a screenshot (probably awkward to read due to 2560 screen, sorry) screenshot of my setup at the time of getting the error.
All the times I'd hit "save" Various entries I'd made in the 'range start' field likely included (at least) the following:
- 2001:470:XXXX:YYYY::60
- 2001:470:XXXX:YYYY::::60
- 2001:470:XXXX:YYYY::
- 2001:470:XXXX:YYYY::1
- 2001:470:XXXX:YYYY:ffff:ffff:ffff:0000
I also had initially left a space at the end of the End Range field.
Files
Updated by Chris Buechler almost 10 years ago
- Status changed from New to Closed
there were some issues with IPv6 validation in 2.1.5 that are since fixed in 2.2. That was triggered by an invalid IPv6 address that wrongly passed our checks for a valid v6 IP. If you can still find a means of replicating on 2.2, let us know.
Updated by Phillip Davis almost 10 years ago
I tried your formats above and got no "Unrecognized address" text error stuff, just the proper errors reported on the webGUI when I purposely put ranges out of order, or out of the subnet.
In your screen shot you have left the subnet and mask displayed in clear text. Given that, there is no advantage to be gained in blacking out the data entry bits. If I knew exactly what the values and where the colons and other punctuation was in that input, then it might be possible to replicate. Then I can easily track down the bug in IPv6 address format validation.
Updated by Overand IRC-Priv almost 10 years ago
Well, I figured I might have left something in by accident - figures!
I've attached (but not embedded) the un-munged screenshot.
It's quite likely I tried some other formats when trying to get this to work, such as "0060" as the last block (dual octet?) with the various other setups I'd listed above.
Updated by Overand IRC-Priv almost 10 years ago
Aha! Looks like a leading space on the "range start" is what does it.
Leading space on this first one: 2001:470:1f07:fc1::10 - 2001:470:1f07:fc1:ffff:ffff:ffff:ffff
Also works with 2001:470:1f07:fc1::
as the range start (again with the leading space).
Updated by Phillip Davis almost 10 years ago
No problems with white space or anything for me on 2.2-RC. As Chris says, this is fixed in 2.2 and I can't find a combination here that breaks it.
Updated by Overand IRC-Priv almost 10 years ago
Awesome! Thanks for checking, Phillip, great to know it's fixed in the new release.