pfSense

One workaround for this is to use pack/unpack or use filter_validate($ip, FILTER_VALIDATE_IP)

As noted by someone on the mailing list, this also affects input validation on things such as the DHCP server that just need to be checked again after fixing the core issue.

This should have been fixed in the PHP5 source as of last April (2009).
If the issue is still there, maybe a bug report to PHP is in order.
See http://bugs.php.net/47365

Sorry wrong link.
I can't find the right one now, but 32-bit will return signed int, and 64-bit will return unsigned.
There was a patch for it, but I am not sure what the status is.

From what I've read it this is not considered a bug from PHP's perspective since it is documented "Because PHP's integer type is signed, and many IP addresses will result in negative integers" See [[http://php.net/ip2long]]

For now I've gone through all the PHP pages on my system and wrapped ip2long calls w/ unpack('l',pack('l',ip2long(...))) but ultimately I think it would be a better idea to encapsulate all IPv4 code in an ipv4 class with address(), netbits(), netmask(), inverse(), network(), broadcast(), ipcompare(), ...

Can you provide us a patch that wraps all ip2long calls with unpack?? We can get that committed. Probably will not make sense to redo the functions until we add ipv6 support.

It would probably be better to make our own ip2long function that does it right, and then change all our calls to use it instead. I don't think PHP will let you overload it though so it would involve renaming all instances of ip2long with whatever we make.

Sure, let me test tonight more thoroughly and I'll submit tomorrow.

The issue on 64-bit is likely that all the high 32 bits are set from sign extension because it considers it negative, interfering with bitwise comparisons when one IP address being compared has those high 32 bits set, so I think ip2long($ip) & 0xFFFFFFFF should work. If you want a function that does this, it could be something like this:

function ip2long32($ip) {
    return ( ip2long($ip) & 0xFFFFFFFF );
}

I've also seen places where subnet masks are negated with the bitwise not operator. In these places, we may also need to use & 0xFFFFFFFF on either the negated mask or the resulting address. Depending on the behavior of long2ip, it may also be necessary to use that bit mask to truncate certain calculated addresses to 32 bits before passing to long2ip. I think long2ip may just truncate to 32-bits on the PHP version used, but I'm not 100% sure.

Thanks Erik, I'll test once it is in the nightly build.

Thanks again, I've verified it is now working on my 64-bit system.