Troubles with 3.0.0.4.374.35_4-sdk5

[scsween]

First time post and let me start of by saying "hat tip" to Merlin for the firmware improvements. Lots of great features over previous routers I've used and Asus should send you a big check.

I'm running 3.0.0.4.374.35_4-sdk5 on a brand new RT-N66U that replaces my DIR-655 A4 workhorse. The D-Link's wifi was flaking out on us.

I've run into a few problems though and would like to figure out whether I'm doing something wrong, or perhaps these are bugs.

I like to use DHCP reservations for all known devices on my network. First, I've noticed that the manual assignments don't always happen. I'm not even certain of a pattern. Some Sonos devices get their assignments, others don't. And even with a specific device, sometimes it will take its assignment, and other times not.

It does seem that wifi devices are taking their assignments and names (in the clients list) more reliably. It is the wired ones that have the problems. Wired devices aren't showing up in the DHCP lease log, but wireless devices are ... even though they are manually assigned.

Second, the "friendly" names that I've specified on the manual assignment, don't always show up on the Network Map | Client Status. I have some devices with the wrong names. That is, they are taking names from other devices that I've defined in the manual assignments.

Some of these settings were entered from the previous sdk5 firmware release. (When I installed that release, I cleared nvram.) Others are since then.

Thanks for any guidance and help.

SS

 

[RMerlin]

I like to use DHCP reservations for all known devices on my network. First, I've noticed that the manual assignments don't always happen. I'm not even certain of a pattern. Some Sonos devices get their assignments, others don't. And even with a specific device, sometimes it will take its assignment, and other times not.

It does seem that wifi devices are taking their assignments and names (in the clients list) more reliably. It is the wired ones that have the problems. Wired devices aren't showing up in the DHCP lease log, but wireless devices are ... even though they are manually assigned.

Second, the "friendly" names that I've specified on the manual assignment, don't always show up on the Network Map | Client Status. I have some devices with the wrong names. That is, they are taking names from other devices that I've defined in the manual assignments.

Make sure you don't have another DHCP server running on your network. That could explain both issues you are mentioning.

 

[scsween]

no rogue dhcp servers

Thanks for the quick reply. Yes, that might explain it but no there are no rogue dhcp servers on the network. The old router is off, and is the only other one in the house. Nothing else but switches and devices.

To be safe, I fired up Wireshark and did an ipconfig release / renew (mac equivalent, anyway). The only DHCP offer was from the new Asus.

Any other ideas? I take it that you (and no one else) are not experiencing the same issues?

PS - Next I was hoping to use the "friendly names" that I'd defined to setup parental controls. We limit internet access to our kid's devices to a set schedule. I am not seeing the friendly names (from the IP reservations) there either. Is that as designed?

 

[RogerSC]

Just a quick thought...address reservations don't take effect until the client that you've reserved the address for reboots or the current lease for that client runs out. There may be other events that can cause a client's address to change to their new reserved address, I'm not sure. If this is what you're seeing, then rebooting or power-cycling the clients that don't seem to take the address reservation should take care of it. Or just wait, and they should switch over.

Also, you won't see the name that you've given the client until the address reservation goes into effect.

 

[scsween]

Thanks Roger. I'll start power cycling devices and see whether that clears things up.

Another data point, my reservations are within the DHCP range, not outside. That's how I've set them up in the past. Statics are outside the range, but are obviously not specified at the router. Could this be a cause of the problem?

 

[RogerSC]

Thanks Roger. I'll start power cycling devices and see whether that clears things up.

Another data point, my reservations are within the DHCP range, not outside. That's how I've set them up in the past. Statics are outside the range, but are obviously not specified at the router. Could this be a cause of the problem?

I don't know if that's the cause of what you're seeing, but I always allocate reserved addresses outside of the DHCP pool addresses, and that works for me.

 

[scsween]

Resolution

Rebooting all of the devices sorted out my issue, for the most part. Those devices I reserved are now showing the correct names in the client status list. Thanks for your help.

For clarification to others in the future, reserved IP addresses do not need to be outside of the DHCP pool. They can be, but they don't have to be.

A few of nice to haves, which I suppose are enhancement requests:

1) In the Manual Assignment section on the LAN | DHCP Server page, it would be great if the list were sorted by IP address, not order entered.
2) I'm not super crazy about the Client Status List on the Network Map. It would be nice to have a tab under LAN with all of this information. I suppose the DHCP log suffices, though with a tab you could add an option to release a specific IP lease and/ or to reserve it.
3) Parental controls are pretty weak & kludgy. It would be great to be able to define schedules and then assign / apply them to devices, as opposed to having to define each schedule individually for each device. Also to be able to toggle the schedule on and off individually. Also to be able to indefinitely suspend access to a device individually, all from the same grid. Practically speaking, this is how internet privileges are curtailed and / or suspended. Asus could do a lot better here.

Thanks again!

SS

 

[jsmiddleton4]

Sorting assigned IP's as well as the client list in network map would be great. I get lost after trying to read through the list to find one client... Sorting them alpha or IP numeric, something, would be great.

I have assigned IP's not within the set of available DHCP assigned IP range. For me it is a quick way I can pickup a possible rogue client. Any "new" client, non-assigned static client, is easy to see because of the IP assigned range.

When I see an IP in the xxx.xxx.xxx.40-50 range I know it had to be assigned via DHCP and I check that IP out to see who/what got a DHCP assigned IP.

 

[bluepoint]

Another data point, my reservations are within the DHCP range, not outside. That's how I've set them up in the past. Statics are outside the range, but are obviously not specified at the router. Could this be a cause of the problem?

That's how I did mine. That's why the reserves are called "DHCP reservation" because they are within the DHCP assigned range, they still renew but always gets the same IP's hence, reserved. Anything outside of the range are my clients that I configured for "static" IP ex. server, printer, etc...

 

[RMerlin]

Sorting assigned IP's as well as the client list in network map would be great. I get lost after trying to read through the list to find one client... Sorting them alpha or IP numeric, something, would be great.

Unfortunately, the way Asus implement their webui is very inflexible. They even actually use the HTML code itself as a place to store and retrieve data (which can lead to quite a few additional quirks - for instance, never use "..." inside field on some of the pages, or it will fail to be properly saved by the router).

I tried once to improve on how those lists were handled, and the only proper way to do it would require rewriting a lot of the webui code, which would then make it a nightmare to maintain whenever Asus did any change to it on their end.

 

[scsween]

Unfortunately, the way Asus implement their webui is very inflexible.

That's too bad. I see now why you added tabs instead of changing what they created.

Thanks again!