I'm using a WZR-HP-G300NH to connect to Comcast for my internet. When I do certain modifications to the router's configuration it causes the router to drop its WAN DHCP settings and re-request. For example, all I did was update the Syslog Transfer logs. Typically on these requests it fails and just sits there until I play around with it. Sometimes I have to make changes when connected remotely so this kinda kills having that ability. I've set the switch to Router mode and the Method of Acquiring Address is set to DHCP.
Any other suggestions for getting a smooth DHCP transaction? I never had a problem with my older Buffalo router.
Firmware Ver.1.60 (R6.20/B1.03)
I am having a similar problem....
I have comcast as well and my g300nh does not like to make a dhcp connection to the modem. It can take dozens of tries... router reboots.... modem reboots... I try everything.
Even when I manage to get a DHCP connection, the router will drop it when the wind blows... This is very upsetting. I have to use my Linksys for now until this is resolved. If it isn't resolved soon I will return the router and give it a very poor review.
I'm having the exact same issue with my Arris modem on Comcast. Not to mention how absolutely terrible and cludgey the interface is to the admin page. I wish to God someone would port DD-WRT to this router.
I was having the same issue. Mine would happen anytime after any changes and/or an unexpected power cycle (like any storm that cycles/knocks out the power).
After many maddening times of this, I was finally able to get it where it is completely stable even after power outages/flashes and multiple reboots and/or config changes.
It was the simplest of fixes but it took forever for it to occur to me and never even occurred to Buffalo's tech support. Here's the one click trick that worked for me and will hopefully save all of you and many other the headache that we've all experienced:
1. Log into router
2. Click on Internet/LAN
3. Click the radio button next to "Acquire an IP Address Automatically from a DHCP Server"
4. Reboot
When I was going through one of the many painful, failed attempts at getting an IP, I happen to notice that it was trying to get an IP through PPPoE first and then it would send a regular DHCP request. The problem appeared to be, it would time out before it could ever get an ack back from the server.
I'm surprised that the Buffalo support desk didn't have any notes on this and was pretty much bored with the Comcast support figuring I'd try both ends to get some satisfaction/ideas. I didn't expect them to be able to fix it and would have thought that BT would have known how to fix their own product. At the very least, I would have expected the DHCP request to be first in the order since PPPoE is not really that popular these days.
WZR-HP-G300NH (FW v.1.71) doesn't work with my ISP (fiber optic with ethernet coverter) either. I did some research and it seams that the problem is in Buffalo's DHCP client - it does not renew IP address without renewtime, rebindtime (Opt58/59) parameters. Other DHCP clients renew IP by 1/2 leasetime if those two parameters are missing. I've been told that renewtime/rebindtime is not part of DHCP standard but most DHCP servers support it by default. Not in my case though. Any comments from Buffalo staff on this issue?
My 1.65 firmware for US region doesn't even have that option. Actually, on that page I only have Advanced Settings. A rendering problem in IE8/Firefox?
EDIT: This setting can only be changed when the hardware mode switch on the AirSation is set to [ROUTER ON].
I have found that if I have more than 1 wired device, it cannot detect the DHCP server. However, if I limit myself to 1, it is ok.
I can't believe I managed to buy a router which doesn't work with my ISP DHCP. Probably 99% of other modern routers works just fine, but not Buffalo... It's a shame to put this kind of firmware in such a good piece of hardware. As per Buffalo support, I don't believe this issue will ever be fixed in firmware so my only chance is to go with dd-wrt.
@mindungo: same problem with my WZR-HP-G300NH . Now I've send this router back to my seller and change it for Asus RT-N16with dd-wrt FW. Works as router should work. Never Buffalo again.
is there a solution for the DHCP WAN problem yet or is buffalo just waiting for the DD-WRT firmware?
You may find this solution helpful. It seems like the same problem...
I've found a fix to the compatibility problem between Charter and Tomato. To fix the issue, do the following steps:
1) Login to Tomato
2) Go to advanced
3) Go to DHCP / DNS
4) Under DHCPC Options, put the following:
--retries=2 --timeout=5 --tryagain=310
(Note: this causes the router to only try to get an address twice, timeout after 5 seconds, and wait 5 minutes between attempts. On Charter, you could lower the --tryagain to 3 minutes, if you wanted, but I've set it to 5 to be safe)
5) Click save
Note: This fix only has been validated in Tomato-usb 1.28. Stock tomato 1.25 does NOT have the "DHCPC Options" field.
Details:
The root cause of the problem is that Charter's DHCP server stops communicating with any DHCP client that attempts 5 communications in a 3 minute window. Once blacklisted, devices are not able to communicate with the DHCP server until there has been 3 minutes of inactivity. However, Tomato's default behavior is to try 5 communications per attempt, and to try more frequently than every 3 minutes to connect.
When making the connection, some cable modems appear to establish the upstream connection before the downstream is fully established. This allows packets to travel FROM the router but not back TO the router. When the Tomato router attempts to get its IP address, the packets TO the DHCP server are received, but the responses are not. This causes Tomato to retry over and over, getting itself blacklisted. Once blacklisted, Tomato attempts often enough to stay blacklisted.
When power is applied simultaneously (power comes back) to the cablemodem and router, certain cable modems startup at the same time as the Tomato router. This means that Tomato has a timing condition where (after a power outage), it gets itself blacklisted and will not obtain internet access without manual intervention. However, other cable modem models appear to startup much more quickly (or establish upload/download at the same time), and are not affected by the issue.
From a Charter Rep:
The amount of time that it takes to reestablish a connection makes me think we could have a DHCP denial issue. This is where something from the customer's end is requesting an IP address from our DHCP servers more than 5 times in 3 minutes. The culprit of these issues is a router about 95% of the time. When this happens, your service is temporarily blocked. To fix it, the server has to be clear of all requests for 3 minutes. We usually accomplish this by unplugging modem and router for that time.
Fix:
The fix is to reconfigure udhcpc to try fewer times and to wait longer between attempts. This prevents the router from being blacklisted. This is achieved by passing "--retries=2 --timeout=5 --tryagain=310" to udhcpc.
Workaround:
The issue can be worked around by unplugging the Tomato router for 5 minutes, and then plugging it back in. Alternatively, you can power on the cable modem fully before starting the router.
Reproduced this issue on a WRT54GL with the following cablemodems:
Motorola SB 5100
Ambit U10C018.80
Issue did not exist with a WRT54GL the following cablemodems:
Cisco DPC3010