Mint Forum

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 209.121.233.126. 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 128.0.0.0 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.

Hi,

A little self-followup: first, apologies that I hadn’t properly dealt with markdown syntax in the previous message, so underlines have come out as emphasis.

Anyway, there is some more info on the problem here, with details on which fields to change, and where the information on signed vs unsigned is found (it is, perhaps unsurprisingly, an “attribute” — sorry I missed it).

I haven’t taken the advice to empty the table, as this seems a bit dangerous — I’m waiting to see if the info just works its way through the displayed hits. (and I still don’t know why I have quite so many different mint tables… I suspect it’s some of my own backing-up and restoring in the distant past about which I’ve forgotten).

-Andrew

We had this problem, too, across the board in nearly every table. The solution, as you inferred, was to change all checksum-based INT(10) field types to INT(10) UNSIGNED. YMMV, of course, but our issue started when we moved the Mint htdocs to a 64-bit server, and our DB is on the same, 64-bit server.