[F] IP search bug when ip >= 128.0.0.0

[Choli]

Environment (as reported in the AdminCP):
MyBB: 1.4.1
PHP: 5.2.6
DB: MySQLi 4.1.22

Bug:
When you search an IP address using the ModCP (modcp.php?action=ipsearch) and the IP is bigger or equal than 128.0.0.0 (ie: the first byte is >= 128), it turns out that no post nor user is found (assuming that there are such ones registered in the DB, of course).

The problem is with the call to the function fetch_longipv4_range in modcp.php, which it returns a negative integer number for IPs >= 128.0.0.0; and that number is compared with the field longipaddress or longregip in the DB. However, those fields seem to have a positive number, therefore no match is found.

For example, in my forums, the page moderation.php?action=getip&pid=11 returns the IP 213.201.17.42 of that post. In the DB, I see the post in the posts table with these fields: ipadress = "213.201.17.42" and longipaddress = "2147483647". However, when I go to the page modcp.php?action=ipsearch&ipaddress=213.201.17.42&search_posts=1 then MyBB can't find any result.

I hope you can solve this problem shortly. Thank you very much.

[Ryan Gordon]

Ah, the longipaddress column has a limit of 10, which is just enough for everything except the negative sign. This'll be fixed in 1.4.1

[Ryan Gordon]

Thank you for your bug report.

This bug has been fixed in our internal code repository. Please note that the problem will not be fixed here until these forums are updated.

[Ryan Gordon]

Can you put this file in your main directory and run it via your browser? Delete it afterward, and see if it fixes your problems.

Thanks,
Ryan

Edit: Sorry, there was a bug in the file.

[Choli]

(09-08-2008 10:45 PM)Ryan Gordon Wrote:  This'll be fixed in 1.4.1

Better in 1.4.2

(09-08-2008 11:02 PM)Ryan Gordon Wrote:  Can you put this file in your main directory and run it via your browser? Delete it afterward, and see if it fixes your problems.

Thanks,
Ryan

Edit: Sorry, there was a bug in the file.

Ok. Let's see:

(first of all, the file has a little typo: it's longregip instead of logrepip, in the first write_query; but that has not been a problem)

So: the file executes correctly:

Code:

Performing necessary queries..

Repairing ip's 1 - 11

Done

All post ips have been converted to the new ip format.

Repairing ip's 1 - 6...

Done

All user ips have been converted to the new ip format.


Completed the update, please delete this file now.

But I have still the same problem. In phpmyadmin I can see that now the columns are int(11) instead of int(10), but their values are still positive numbers. For some reason, the update queries of fixips.php were not able to update those values. I don't know why.

IMHO, wouldn't it be easier to modify modcp.php in order to make que query using a positive number instead of modifying the DB? Something like this:

PHP Code:

$post_ip_sql = "longipaddress='" . sprintf("%u", $ip_range) . "'"; 


Or maybe it doesn't worth it, because there are lots of places in the code where fetch_longipv4_range is used... i don't know.

Edit: i've just quickly tested the sprintf workarround and it seems not to work ... it's too late at night here, maybe tomorrow i'll give it another try


Edit2: In the DB I have the number 2147483647 in the longip columns for the rows with ip = 213.201.17.42; but that number is 0x7FFFFFFF (the maximun positive integer number in 2's complement using 32 bits) and that number is not the value returned by ip2long (or, at least, it should not be). And that happens before and after applying the patch. Maybe that can be a clue for you

[Yumi]

From memory, PHP's "int" datatype is just a signed 32 bit integer. In MySQL, the "int" type is also a 32 bit integer, signed by default.
Thus, from memory, PHP's ip2long() function returns a signed integer.

Thus using positive numbers won't work.
I haven't tested things, so I'm just putting what I know forward.