Author |
Message |
arlinorlando
New Member


Joined: Oct 09, 2006
Posts: 2
|
Posted:
Thu Dec 21, 2006 7:45 pm |
|
Hi,
Nuke Sentinel seems to be blocking "none" for an IP when it is unable to determine Clients Ip, for example:
Forwarded For: none
Client IP: none
Remote Address: 81.182.246.8
Remote Port: 35176
Request Method: GET
He is actualy adding "none..." to the blocked IP list... And when "none..." is on the blocked IP list, everybody with "Client IP: none" are blocked...
So every time that I notice a "none..." was added to the blocked list I have to manualy remove it as soon as possible to allow people with "Client IP: none" to see the site...
Anyone knows how can I avoid "none..." to be inserted to the blocked list ?
Thanks,
Arlin |
|
|
|
 |
kguske
Site Admin

Joined: Jun 04, 2004
Posts: 6437
|
Posted:
Thu Dec 21, 2006 8:23 pm |
|
You could try adding it to the protected list, but that could be risky. |
_________________ I search, therefore I exist...
Only registered users can see links on this board! Get registered or login! |
|
|
 |
arlinorlando

|
Posted:
Thu Dec 21, 2006 10:41 pm |
|
Well... I cant do that since the protect list field is a int and "none..." is a char...
Shouldn't sentinel always block the IP from Remote Address ?
I dont know why, but some times it block the IP "none..." and it's even not a number... |
|
|
|
 |
khaled_dxb
Regular


Joined: Jan 15, 2007
Posts: 66
|
Posted:
Fri Jun 15, 2007 7:21 am |
|
Did u ever manage to get an answer as to why nukesentinel is checking for the remote_ip instead of the remote_addr?
I am always getting none as a client IP and nukesentinel always blocks it.
what is the difference between the two - i noticed that always remote_addr is correct while remote_ip can be none.
in nukesentinel.php i have changed on line 142:
Code:// Invalid ip check
if(isset($bypassNukeSentinelInvalidIPCheck) AND $bypassNukeSentinelInvalidIPCheck) {;}
elseif ($nsnst_const['remote_ip']=="none") { die(_AB_INVALIDIP); }
|
to
Code:// Invalid ip check
if(isset($bypassNukeSentinelInvalidIPCheck) AND $bypassNukeSentinelInvalidIPCheck) {;}
elseif ($nsnst_const['remote_addr']=="none") { die(_AB_INVALIDIP); }
|
in order to get around the problem of being blocked every single time!
Thanks for your input. |
|
|
|
 |
evaders99
Former Moderator in Good Standing

Joined: Apr 30, 2004
Posts: 3221
|
Posted:
Fri Jun 15, 2007 6:06 pm |
|
$nsnst_const['remote_ip'] is a custom variable used by Sentinel. It is set using the function get_ip() and can represent one of several things if they are set
client_ip
forward_ip
remote_addr |
_________________ - Only registered users can see links on this board! Get registered or login! -
Need help? Only registered users can see links on this board! Get registered or login! |
|
|
 |
khaled_dxb

|
Posted:
Sat Jun 16, 2007 3:05 am |
|
yes, i did work my way backwards to that function, however why is it that one constant returns "none" while the other (remote_addr) returns the valid ip address.
Have i compromised the security in any way by changing the code as i have done to get around the "none" problem?
Basically what i'd like to know is Where does this "none" come from? when you say "if they are set" - set where? does the user set them? does the browser?
I've seen quite a number of posts about this "none" issue, but none seem to get to the root of the problem?
Here's another one for you!
If i change the table name "nuke_nsnst_ip2country" to anything else "nuke_nsnst_ip2country_old" for example, then the "none" goes away!?? the valid ip address now shows up and the invalid ip check passes
in mainfile.php - i modified the online() function as follows for troubleshooting only.
Code:function online() {
global $nsnst_const, $user, $cookie, $prefix, $db;
if(!file_exists('includes/nukesentinel.php')) {
$ip = $_SERVER['REMOTE_ADDR'];
} else {
$ip = $nsnst_const['remote_ip'];
echo "IP ADDRESS: " . $ip; //TROUBLESHOOTING
|
so i can see what the function is returning each time and when i changed that table name it shows me correct IP, if i change the table name back - then it shows "none" again!
Thanks! |
|
|
|
 |
evaders99

|
Posted:
Sat Jun 16, 2007 6:58 pm |
|
My guess is that your IP2Country data has not been updated. You can download the most recent updates from http://www.nukescripts.net |
|
|
|
 |
khaled_dxb

|
Posted:
Sun Jun 17, 2007 8:20 am |
|
Thanks evaders99,
I did this step already, since it was recommended in many of the "none" posts i've read so far.
i dont believe that this is contributing to the problem, although it is linked somehow - why would the IP2C table have any effect on what IP address is retrieved by NukeSentinel? am i missing something?
The ip address using one method (remote_addr) works fine, whereas the other using the remote_ip function does not?
In any case, i guess it's some kind of bug - im no expert programmer, as as long as the little work around is working, i'lll keep it there.
Thanks for your help. |
|
|
|
 |
gregexp
The Mouse Is Extension Of Arm

Joined: Feb 21, 2006
Posts: 1497
Location: In front of a screen....HELP! lol
|
Posted:
Sun Jun 17, 2007 9:19 am |
|
Code:if(isset($nsnst_const['client_ip']) && !stristr($nsnst_const['client_ip'], "none") && !stristr($nsnst_const['client_ip'], "unknown") AND !is_reserved($nsnst_const['client_ip'])) {
return $nsnst_const['client_ip'];
} elseif(isset($nsnst_const['forward_ip']) && !stristr($nsnst_const['forward_ip'], "none") && !stristr($nsnst_const['forward_ip'], "unknown") AND !is_reserved($nsnst_const['forward_ip'])) {
return $nsnst_const['forward_ip'];
} elseif(isset($nsnst_const['remote_addr']) && !stristr($nsnst_const['remote_addr'], "none") && !stristr($nsnst_const['remote_addr'], "unknown") AND !is_reserved($nsnst_const['remote_addr'])) {
return $nsnst_const['remote_addr'];
} else {
return "none";
}
//snippet from nukesentinel.php
|
Now you need to see what is failing, If you would like,
print_r($nsnst_const);
will output the array, Now you need to tell where it is failing, it will return none when all the variables fail to meet the criteria of the if statement, here are the criteria to NOT return none, it has to
1. Be set.
2. It cannot contain the word none in it
3. It cannot contain the word unknown
4. It cannot be reserved.
Now you need to figure out where it is failing, probably in the reserved list.
That is the most common and most likely, and updating your ip2c will update your reserved ip list, but may not fix the problem at hand if the ip remains in the reserved ip list. I hope that helps. |
_________________ For those who stand shall NEVER fall and those who fall shall RISE once more!! |
|
 |
 |
|