I assigned to my wrt54gl router an IP address: 10.0.0.1
And the Subnet Mask: 255.0.0.0
Then I assigned a static IP address to my computer (using network connection in control panel in windows) which was 10.255.255.0
The router worked fine when I browsed the internet, but the problem (which I think it is a bug) started when I wanted to do some work in the "Firwall" section in Gargoyle.
No restrictions, Quotas or QoS can be done for IP addresses that contains 255, and When I try to write an IP address like 10.255.255.0 it will be colored in red (as if it was an invalid IP address)....
I understand that 255 should not be found at the end or the beginning of the IP address (which is not the case here).
Also I can not assign a static IP address containing 255 (like 10.255.255.0) to my computer using the "DHCP" page in Gargoyle for the same reasons.... Even that the router is working fine with that IP address, and I can see in the "Connected Hosts" page that IP address along with my computer MAC address!!!
IP Bug???
Moderator: Moderators
Re: IP Bug???
Yeah, that's a bug in the error checking script. It's the same subroutine used everywhere so even though the buggy code only occurs in one place, it shows up everywhere. I'll see what I can do.
However... I'm hunting down a seriously annoying bug in the bandwidth monitor, and have been for the past week. That takes priority.
However... I'm hunting down a seriously annoying bug in the bandwidth monitor, and have been for the past week. That takes priority.
Re: IP Bug???
This should now be (mostly) corrected in the latest bleeding edge release that I just uploaded.
I say mostly because you're absolutely right that the check for a broadcast address should only check if the last byte is 255, but it's possible for a broadcast address on smaller subnets to actually end in something other than 255. However, in these cases, you need to know the netmask, which isn't always available to check for this. So, the error-check still won't catch those cases, though it will now work where it wasn't working before.
I say mostly because you're absolutely right that the check for a broadcast address should only check if the last byte is 255, but it's possible for a broadcast address on smaller subnets to actually end in something other than 255. However, in these cases, you need to know the netmask, which isn't always available to check for this. So, the error-check still won't catch those cases, though it will now work where it wasn't working before.