Not sure if this is still common issue but I just ran into the issue on a client’s mint installation and while the problem was easily solvable, the solution and explanation was a bit elusive. After matching up the 127.255.255.255 entries in Mint with the actual request in the Apache logs, I did a bit of investigation and figured out what was happening so I thought I’d post here:
Tl;dr: Change the IP field type to signed INT on 64-bit systems.
Let’s say you get a visit from IP address 22.214.171.124. On a 32 bit system, when you run ip2long on the address you get the value -780539522. When you insert that value into a MySQL field with an unsigned INT type, there are no issues since that value is within the range that field can handle (-2147483648 to 2147483647).
Now let’s say you or your host make the move to a 64-bit system. The same IP passed through the ip2long function becomes 3514427774. When you try to insert that value into the same field, the value is too large for the field to handle so MySQL simply chokes and stores it as 2147483647 (the ceiling of the unsigned INT type). If you then pass the long value 2147483647 through the reverse function (long2ip), that function returns, unsurprisingly, 127.255.255.255.
In fact, any IP address larger than 127.255.255.255 (so 126.96.36.199 and up) will become a long too large for the field to handle and will truncate to the 127.255.255.255 value.
So as detailed here before, the solution is to convert the field to a signed INT type. The range of values that field can handle is now 0 to 4294967295. On a 64-bit system, even the “largest” IP possible (255.255.255.255) becomes 4294967295 after passed through the ip2long function which the field can handle.
Anyway, that’s my notes on the problem which will hopefully help some of you fix any of these issues.