D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-330 => Topic started by: deansleonard on February 02, 2010, 12:45:16 PM
-
With a DHCP range of 192.168.1.2 thru 192.168.1.254, i can add a DHCP Reservation for a host with an IP of 192.168.1.25, but I can't add one with an IP of 192.168.1.42. It pops-up an error saying:
42 should be in the DHCP IP Address Range.
It seems as though the software is checking the first digit of the 4th octet for inclusion. Has anyone else seen this bug? It happens in both firmware versions 1.10 and 1.12.
Thank You,
Dean Leonard
-
try the beta, it addresses this issue I believe.
-
I dowloaded and installed the beta (120b44) using the DIR-330 Firmware Upgrade Utility. It appeared to be uploading the new firmware, then asked me to reboot the router. After rebooting, the router will not respond. I power cycled it, but it won't assign an IP address to my DHCP client, so I can't connect to it to diagnose the problem. Have you seen this problem before?
Thank You,
Dean Leonard
-
Yes, this is another problem (besides the Invalid MAC Address issue) with the 1.12 firmware. I'm afraid to try the beta though, if it might brick the router. :-\
-
I had no heard of anyone bricking their router with the beta before the person just recently on here who complained of it. Did you use the utility that came with the firmware?
Call in we will either get you back in or we will start discussing RMAs.
-
Hope I didn't create a misunderstanding, my previous comment was regarding the topic, "Static DHCP Reservations", not bricking the router upon firmware upgrade.
After just now successfully upgrading mine, I can confirm that the issue mentioned above ("should be in the DHCP IP Address Range") seems to be fixed in 1.20beta.
However, the other issue, "Invalid MAC Address" (i.e., beginning with other than "00") definitely is not. This is also a known issue with the DIR-825.
Regards,
-Dan
-
I've located the problem with the "Invalid MAC Address" when trying to create a DHCP Reservation, and determined the necessary fix.
Fortunately, the firmware for the DIR-330 is GPL'ed and available for download from D-Link. After spending a few minutes digging through the sources, I've found the problem in lines 374-377 of the file "DIR-330_gpl/DIR-330_gpl/src/router/www/DIR_330/lan.asp". Those lines should simply be deleted, as there has never been any requirement that the first octet of the MAC address be "00"; in fact, this is contrary to the specifications in the RFCs, as noted previously. This fix probably needs to be made to the DIR-825 as well, some users have posted regarding an identical problem in its forum.
I'm cross-posting this to the other related topic, "DIR-330 [Invalid Mac Address] Issue - Latest firmware 1.12".
Regards,
-Dan
-
I just ran into this same problem with my DIR-130. The 'Network Settings' page that contains the DHCP server settings and the reservations list has some very poorly coded and completely untested javascript in it.
Problem 1:
DHCP range incorrectly tested.
When the DHCP server settings has a starting range of xx.xx.xx.2 to xx.xx.xx.100, you will ALWAYS get an error message stating that the DHCP reservation is NOT within the DHCP server's range.
This is because the javascript in "/cgi/ssi/lan.asp" that provides the network settings page does a test on the ALPHANUMERIC values of the 4th octet, not the NUMERIC value of the 4th octet. An alphanumeric test checks the ASCII values of each character in the variable until one is either greater to or less than the other. In this case, it sees "2" as the start, "1" as the end and nothing will ever match.
The only way to get it to work at all is to always make the first character of the starting range be less than the first character of the ending range.
So a range of 192.168.10.2 to 192.168.10.100 will never allow any DHCP reservation, whereas a range of 192.168.10.2 to 192.168.10.99 will allow DHCP reservations as long as the first character of the 4th octet starts with something greater than 1 and less than or equal to 9
This creates some strange situations, example:
With a range of Start: 192.168.10.2 End: 192.168.10.99
Blocks: 192.168.10.1
Allows: 192.168.10.2 to 192.168.10.9
Blocks: 192.168.10.10 to 192.169.10.19
Allows: 192.168.10.20 to 192.168.10.99
Blocks: 192.168.10.100 to 192.168.10.199
Allows: 192.168.10.200 to 192.168.10.254
Problem 2:
As already posted, the MAC address, for whatever reason, MUST have a "00" as the first octet. This however appears to be a designed-in constraint as opposed to sloppy coding as the first problem above is.
Javascipt from /cgi/ssi/lan.asp:
if( tmp_mac[0] != "00"{
alert("The first mac value must be 00.");
return false;
}
It FORCES the first octet to always be "00".
DLINK: The latest firmware for this router is now 3 years old. Are you ever going to fix it???
I link DLINK.. I have many pieces of DLINK equipment in my office and home, but this is just unfathomable. I was forced to go by a competitors product even though I didn't want to.
-
Hope I didn't create a misunderstanding, my previous comment was regarding the topic, "Static DHCP Reservations", not bricking the router upon firmware upgrade.
After just now successfully upgrading mine, I can confirm that the issue mentioned above ("should be in the DHCP IP Address Range") seems to be fixed in 1.20beta.
However, the other issue, "Invalid MAC Address" (i.e., beginning with other than "00") definitely is not. This is also a known issue with the DIR-825.
Regards,
-Dan
Also confirm beta39 ( all I could find) fixes "DHCP IP Address Range" issue but "invalid mac address" still there, so not able to add Mac Mini or iPad or Iphone. Discovered that trying to load beta120b39.bin from the browser firmware upgrade section doesn't work "the file name had an error" , whoever codes this should be given a broom and shown to the barn. hell a simple unit test would find all of these error.
-
as of 2011-12-06, still only showing firmware 1.12
WTF?!
This is not good for my confidence in DLink stuff. I am about to upgrade a bunch of clients' switches to GBit VLAN, now I have to become suspicious of the amateur coding that has been included (pretty much expected in the early 21st century), yet may never be fixed (definitely not a workable part of the 'ship early and fix later' strategy).
-
@Baratong: Great bit of sleuthing on problem #1. Problem #2 is 100% due to sloppy research. Anybody that reads the current & historical RFCs will find that nowhere is an initial octet of "00" forbidden; in fact, some of the examples show such an address.
I can't fathom where the D-Link programmer(s) got the idea that an initial "00" was invalid, but evidently none of them ever bothered to look up any RFCs. What's especially frustrating is that there is absolutely no response to fix it.
Our company has given up on D-Link products, because the organization seems to have completely fallen apart. What we're using for a router & firewall right now is an older Dell PowerEdge 1750 1U server we found at a surplus sale for $5; running CentOS 5.7, the Shorewall firewall, and the Webmin GUI administration interface -- all of which are free.
I would suggest to consider returning the D-Link product for refund if possible; then find another alternative. In my opinion, the CentOS / Shorewall / Webmin combination running on hardware a few years old is really hard to beat (we've found it to be as easy, and more capable, than OS X Server).