Bug #17221
closedMatching IPv6-addresses is not working correctly
0%
Description
Matching IPv6-addresses isn't currently working.
1st:
cmpIPv6($baseIP, $list)
fails for an entry in $list that repesents a subnet like 2001:638:605::/48
Therefore it fails before starting the compare-process.
2nd:
Testing netmask, i.e. comparing starting X bits, fails in interaction with function IPv6Hex2Bin().
Please check out http://t3dev.rz.tu-clausthal.de/ipv6test.php for demonstration of this issue!
This issue affects TYPO3-Core 4.0.6!
(https://svn.sourceforge.net/svnroot/typo3/TYPO3core/tags/TYPO3_4-0-6)
Affected class:
t3lib_div
Affected functions:
cmpIPv6()
IPv6Hex2Bin()
(issue imported from #M5459)
Files
Updated by Rechenzentrum TU over 17 years ago
Due to the fact that functions cmpIPv6() and IPv6Hex2Bin() are the same in Core 4.0.6 and 4.1.1 the bug can be resolved also in 4.1 by replacing these functions by the ones patched in 4.0 by the attached patch.
Updated by Martin Kutschker over 17 years ago
The loop in IPv6Hex2Bin can be made a bit more elegant:
for ($i=0; $i<strlen($hex); $i+=4) {
$binPart = base_convert(substr($hex, $i, 4), 16, 2);
$bin .= str_pad(base_convert($binPart, 16, 2), 16, '0', STR_PAD_LEFT);
}
Updated by Rechenzentrum TU over 17 years ago
Indeed, nice try; but your for-loop isn't working.
But why not use this instead:
function IPv6Hex2Bin ($hex) {
$bin = '';
$hex = str_replace(':', '', $hex); // Replace colon to nothing
for ($i=0; $i<strlen($hex); $i+=4) {
$binPart = base_convert(substr($hex, $i, 4), 16, 2);
$bin .= str_pad($binPart, 16, '0', STR_PAD_LEFT);
}
return $bin;
}
because return result from base_convert is a bit-string; why therefore again a base_convert (in your case again with base 16) on this?
Updated by Martin Kutschker over 17 years ago
Forget the extra base_convert, it's a mistake. But Matthias Kall and I figured out that if you fix validIPv6() you don't need to move to normalize before you check the validity. Here's the code:
function validIPv6($ip) {
$uppercaseIP = strtoupper($ip);
$regex = '/^(?:';
$regex.= '(?:(?:[\dA-F]{1,4}:){7}:)|';
$regex.= '(?:(?:[\dA-F]{1,4}:){7}[\dA-F]{1,4})|';
$regex.= '(?:(?:[\dA-F]{1,4}:){1}:(?:[\dA-F]{1,4}:){1,5}[\dA-F]{1,4})|';
$regex.= '(?:(?:[\dA-F]{1,4}:){2}:(?:[\dA-F]{1,4}:){1,4}[\dA-F]{1,4})|';
$regex.= '(?:(?:[\dA-F]{1,4}:){3}:(?:[\dA-F]{1,4}:){1,3}[\dA-F]{1,4})|';
$regex.= '(?:(?:[\dA-F]{1,4}:){4}:(?:[\dA-F]{1,4}:){1,2}[\dA-F]{1,4})|';
$regex.= '(?:(?:[\dA-F]{1,4}:){5}:(?:[\dA-F]{1,4}:){0,1}[\dA-F]{1,4})|';
$regex.= '(::(?:[\dA-F]{1,4}:){0,6}[\dA-F]{1,4})';
$regex.= ')$/';
return preg_match($regex, $uppercaseIP) ? true : false;
}
Note: the ?: only suppress the subgroup matching of the regexp to make it faster.
Updated by Stefan Neufeind over 13 years ago
Proposed patch to #27210 fixes IPv6-comparison. (Sorry, new ticket opened before I found this.)
Since 4.0.x is no longer supported, I just checked validIPv6 against 4.4, 4.5, 4.6 and they now all use the PHP-internal filter_var()-functionality which is even faster/safer than the regex-check proposed.
So I guess we could close this bug.
Updated by Andreas Wolf over 13 years ago
- Status changed from Accepted to Closed
- Target version deleted (
0)
As Stefan pointed out, this has become obsolete.