Asus RT-AC66U: Manually Assigning IP addresses is flaky

[rdemopo2]

Not sure if other are running into this issue. I picked up an AC66U yesterday, and just about everything about it is running well. My only problem is with static DHCP.

I have set up several MAC addresses to resolve to specific IPs, and the strange part is that some of them work, but most don't. For example, my main computer is properly configured to be 192.168.1.3, and it works great. However, I can't get my PAP2 to take on 192.168.1.4. In total I've configured about 15 IP addresses manually, and about 3 of them actually are assigned correctly, and the rest are assigned into some random high-level IP address like 192.168.1.219 (etc etc..)

Debugging/tinkering so far:
- I have made sure that "Enable Manual Assignment" is on
- I've tried stock firmware, and also Merlin's 354.27 Beta
- I've checked all the individual networked devices to make sure they are not trying to set their own IP address; they are all set to receive an IP automatically
- I tried setting the lowest lease time (120) and waiting to see if somehow the IP address would renew correctly--didn't work. The random number assignments continue even though I have assigned a specific number.
- There are no other routers attempting to assign IPs on the network
- I tried a factory reset and re-put all the manual assignments in again. No luck.

I know I'm doing something right, since some of the manual assignments work; but most don't.

Anyone have any ideas here?

 

[EvgeniX]

you need to restart each PC/TV or wait 24 hours when they will renew it.... or some times turn of router for 15-30 min... its not bug its how it works....

 

[rdemopo2]

Thanks, I'll patiently wait and make sure that it works and report back.

 

[atkinsom]

I had a similar issue and no amount of resetting, waiting and rebooting fixed the issue for me when I first got the router. Some worked and others just never did. I had to start up the router in recovery mode and do an nvram reset from the menu that appears. Then I did a factory reset again(not likely needed but did anyway) and rentered all my settings. Magically they all started to work..might be your issue or not bot but it's worth a shot.

 

[bluepoint]

Not sure if other are running into this issue. I picked up an AC66U yesterday, and just about everything about it is running well. My only problem is with static DHCP.

I have set up several MAC addresses to resolve to specific IPs, and the strange part is that some of them work, but most don't. For example, my main computer is properly configured to be 192.168.1.3, and it works great. However, I can't get my PAP2 to take on 192.168.1.4. In total I've configured about 15 IP addresses manually, and about 3 of them actually are assigned correctly, and the rest are assigned into some random high-level IP address like 192.168.1.219 (etc etc..)

If you have not changed the default DHCP assignments, the DHCP server will assign ip's beginning in .11 to .254 and .2-.10 is reserved for servers. Erase your manually assigned ip and assign your clients ip's beginning in .11. The router's instruction is a bit confusing but what it means is assigning manually static ip(reserved) must be within the DHCP range.

 

[kayphoonstar]

If you have not changed the default DHCP assignments, the DHCP server will assign ip's beginning in .11 to .254 and .2-.10 is reserved for servers. Erase your manually assigned ip and assign your clients ip's beginning in .11. The router's instruction is a bit confusing but what it means is assigning manually static ip(reserved) must be within the DHCP range.

That isn't how it's worked for me. I've always used the manual list to assign ip's outside the router's DHCP range and kept the available DHCP range very small. It has always seemed to work well that way for me. I'm not saying that's the way it's supposed to work - just what's worked for me.

 

[bluepoint]

That isn't how it's worked for me. I've always used the manual list to assign ip's outside the router's DHCP range and kept the available DHCP range very small. It has always seemed to work well that way for me. I'm not saying that's the way it's supposed to work - just what's worked for me.

It probably worked for you cause you didn't have many reserved ip. The OP have 15 reserved ip's that even exceeded the default assigned 9 ip's for server assignments. I'm assuming the router is in default DHCP settings.

 

[crazyea]

I was able to get mine to take the manually issigned ip's by changing the subnet. Then all the devices get a new subnet ip. If needed after this you can then go back to the original subnet numbering and the devices should take the ip manually assigne ip's if you set it up.

I used merlins info to assign the ip's after a factory reset by using this info (before plugging a single device in, or turning it on):

1) Display the nvram setting:

Code:
nvram get vts_rulelist
nvram get dhcp_staticlist
Note down the resulting output.

2) Flash, then reset.

3) Enable SSH, then re-enter your setting, like this (putting your noted down settings between " "):

Code:
nvram set vts_rulelist="<PC1>600:601>192.168.1.100>>BOTH<PC2>610:619>192.168.1.101>>BOTH"
nvram set dhcp_staticlist="<08:00:27:66:44:33>192.168.1.100>PC1"
nvram commit

 

[kayphoonstar]

It probably worked for you cause you didn't have many reserved ip. The OP have 15 reserved ip's that even exceeded the default assigned 9 ip's for server assignments. I'm assuming the router is in default DHCP settings.

I'm assigning 18 ip's and I've reduced available ip's of the DHCP server to 5.

 

[rdemopo2]

Reporting back...

Some strange behavior as I've let it sit for a couple days. Most of the static IPs I assigned eventually worked--just had to wait ~24 hours as was suggested. But two weird anomalies:

- One device simply never switched to the IP I assigned it. In fairness it's an 'always-on' device and I have purposely not killed power to it just to see if it would pick up the new IP; it appears that it won't. Maybe I'll power cycle it later today to see what happens.

- Another device has been a real head scratcher--my network printer. It initially wouldn't take the static IP, but after waiting 24 hours or so it correctly became 192.168.1.10. I thought that was the end of it, but without changing anything, this morning it has reverted back to 192.168.1.176 (which is in the dynamic range, same as before). I have no idea why this thing is fluttering between the IP I assigned to it, and the dynamic hash-table based IP that the router wants to give it. Weird.

<rant> I'm a big DD-WRT fan, but not ready to take the plunge as it's still very much in development for this router (and also, I actually like the ASUS firmware; overall it's pretty good). That being said, DD-WRT is light years ahead of this firmware in terms of static DHCP assignment. When you manually assign an IP in DD-WRT, it changes almost instantly, and you can even initiate a manual release with the click of a button. I wish the ASUS guys could take a page from that design--seems to me there is no reason this router has to suck so badly at manually assigning IPs. </rant>

At the moment my most important devices are properly assigned to the IPs I need them to be, so for now at least I can get on with my day. I'll continue to wrestle with this thing later--maybe I'll try the subnet switching trick or the recovery mode thing as were previously suggested. Depends on how much drinking I do first.

 

[RMerlin]

<rant> I'm a big DD-WRT fan, but not ready to take the plunge as it's still very much in development for this router (and also, I actually like the ASUS firmware; overall it's pretty good). That being said, DD-WRT is light years ahead of this firmware in terms of static DHCP assignment. When you manually assign an IP in DD-WRT, it changes almost instantly, and you can even initiate a manual release with the click of a button. I wish the ASUS guys could take a page from that design--seems to me there is no reason this router has to suck so badly at manually assigning IPs. </rant>

Last time I checked, there was no official, RFC-backed method to force a client to release its IP. Any method to do so is a hack, and is NOT guaranteed to work.

So Asus implemented it the clean, RFC-specified way. If DD-WRT wants to play with hacks that might or might not work... It's their right.

Let me reiterate: there is no official method to tell a client that it should renew its lease. When the client obtains a lease with a given expiration, it will wait until that expiration time comes up. This is the way DHCP is designed to work.

 

[rdemopo2]

Interesting, thanks for sharing that. I learned something new today.

Welp, kudos to ASUS for keeping it clean then. I personally prefer "beast mode" from DD-WRT , but I can see why ASUS wouldn't want to support anything beyond official standards here.