Hopefully I haven't missed someone else finding a solution to this problem that's been plaguing me.
I think I have the solution to this issue. It is related to the logic behind manually assigned IPs. I am using a RT-AC87U with the 3.0.0.4.378_9177-ge585a63 firmware. I was using the previous release (3.0.0.4.378.5134) until this morning. I set up my DHCP clients using MAC addresses I had saved in an Excel spreadsheet when I had my previous Linksys router and copying them into the form. I had seen the strange behavior previously noted when Googling for a solution (not able to edit names, etc., and the 'This entry has been in list." error) prior to this release. When trying to view the "View List", I initially got data, then subsequently got a blank page. I decided to debug the page using Chrome's debugging tools.
Here is the underlying problem, and the line numbers are from the source code in asuswrt-merlin main branch.
Root cause: I manually added MAC addresses in the manually assigned DHCP list in lower case.
The code in genClientList() in asuswrt-merlin/release/src/router/www/client_function.js line 202 loads data from both dynamic introspection and from NVRAM when you have made changes to the device names.
All the data stored in the array called clientList in the field mac are in upper case (this is important)
After populating the clientList, a number of modifications are made, including the customized names, and values from NVRAM, which begins at the loop that begins at line 458 with for(var i=0; i<originData.customList.length; i++)
Inside this loop at line 509, the mac address is overwritten with the value from NVRAM (which in my case is stored in lower case!)
When the "View List" is populated, it runs code in clients_functions.asp. In the debugger, it was failing to execute drawClientListBlock() (line 2342), failing at line 2482. clientListCode += (clientList[clientlist_sort[j].mac].isWebServer) saying that isWebServer is undefined. This is strange because the client object was being populated in genClientList() - I verified that previously
clientList[clientlist_sort[j].mac] is the culprit:
clientList is indexed by MAC address in upper case; clientList_sort is an array populated from the original genClientList(), with some of the MAC address overwritten by the contents of the NVRAM, and hence in lower case.
In the case where clientlist_sort.mac returns a lower case MAC, the line fails because it is used to index clientList[], which is in upper case. So, it finds no match.
Bug #1. Manual DHCP entry should convert MAC addresses to upper case. Simple as that.
Once I realized what happened, I went to my list of DHCP clients and deleted an entry with lower case MAC, saved it. I then manually entered the upper case MAC, and mysteriously the DHCP list already knew about my device name. I finished configuration and retested. It failed again. I went back to the DHCP list and looked at the detail of the device by clicking on the icon, and the MAC address was in lower case.
Bug #2, when you delete from the DHCP list, it does not delete the entry from NVRAM. So, the data I saved originally is brought "back from the dead" even though I thought I had deleted it. The MAC address is in lower case and non-editable.
Here's the workaround if you are brave enough to use an HTML editor. In the manual DHCP list:
1) View the device detail by clicking on the device icon.
2) In Chrome (and supposedly any other browser with a built-in debugger), right click on the MAC address field, and choose 'inspect element'. A bottom panel will open up showing the source HTML of the page.
3) In the bottom panel you will see an <input> tag saying:
<input id="client_macaddr_field" type="text" value="" class="input_32_table client_input_text_disabled" disabled>
This is the field containing the MAC address, and the element is marked as 'disabled' to stop you editing it in the device detail panel. Edit the input element (typically by double-click) and set it to 'enabled'.
<input id="client_macaddr_field" type="text" value="" class="input_32_table client_input_text_disabled" enabled>
Click enter to save the changes to the HTML.
4) In the DHCP form you can now overwrite the MAC address with the upper case value.
5) Click the Apply button. This sets the value correctly in NVRAM.
6) Repeat these steps for every lower case MAC in your DHCP table.
"View List" works like a charm.
So, in conclusion, if the manual DHCP assignment screen ensures MAC addresses are converted to upper case, none of these issues would exist. Also, deletion of a device from the manual DHCP table should also delete it from NVRAM.
I hope this helps everyone. It took me a couple of hours of debugging to work this out.
I think I have the solution to this issue. It is related to the logic behind manually assigned IPs. I am using a RT-AC87U with the 3.0.0.4.378_9177-ge585a63 firmware. I was using the previous release (3.0.0.4.378.5134) until this morning. I set up my DHCP clients using MAC addresses I had saved in an Excel spreadsheet when I had my previous Linksys router and copying them into the form. I had seen the strange behavior previously noted when Googling for a solution (not able to edit names, etc., and the 'This entry has been in list." error) prior to this release. When trying to view the "View List", I initially got data, then subsequently got a blank page. I decided to debug the page using Chrome's debugging tools.
Here is the underlying problem, and the line numbers are from the source code in asuswrt-merlin main branch.
Root cause: I manually added MAC addresses in the manually assigned DHCP list in lower case.
The code in genClientList() in asuswrt-merlin/release/src/router/www/client_function.js line 202 loads data from both dynamic introspection and from NVRAM when you have made changes to the device names.
All the data stored in the array called clientList in the field mac are in upper case (this is important)
After populating the clientList, a number of modifications are made, including the customized names, and values from NVRAM, which begins at the loop that begins at line 458 with for(var i=0; i<originData.customList.length; i++)
Inside this loop at line 509, the mac address is overwritten with the value from NVRAM (which in my case is stored in lower case!)
When the "View List" is populated, it runs code in clients_functions.asp. In the debugger, it was failing to execute drawClientListBlock() (line 2342), failing at line 2482. clientListCode += (clientList[clientlist_sort[j].mac].isWebServer) saying that isWebServer is undefined. This is strange because the client object was being populated in genClientList() - I verified that previously
clientList[clientlist_sort[j].mac] is the culprit:
clientList is indexed by MAC address in upper case; clientList_sort is an array populated from the original genClientList(), with some of the MAC address overwritten by the contents of the NVRAM, and hence in lower case.
In the case where clientlist_sort.mac returns a lower case MAC, the line fails because it is used to index clientList[], which is in upper case. So, it finds no match.
Bug #1. Manual DHCP entry should convert MAC addresses to upper case. Simple as that.
Once I realized what happened, I went to my list of DHCP clients and deleted an entry with lower case MAC, saved it. I then manually entered the upper case MAC, and mysteriously the DHCP list already knew about my device name. I finished configuration and retested. It failed again. I went back to the DHCP list and looked at the detail of the device by clicking on the icon, and the MAC address was in lower case.
Bug #2, when you delete from the DHCP list, it does not delete the entry from NVRAM. So, the data I saved originally is brought "back from the dead" even though I thought I had deleted it. The MAC address is in lower case and non-editable.
Here's the workaround if you are brave enough to use an HTML editor. In the manual DHCP list:
1) View the device detail by clicking on the device icon.
2) In Chrome (and supposedly any other browser with a built-in debugger), right click on the MAC address field, and choose 'inspect element'. A bottom panel will open up showing the source HTML of the page.
3) In the bottom panel you will see an <input> tag saying:
<input id="client_macaddr_field" type="text" value="" class="input_32_table client_input_text_disabled" disabled>
This is the field containing the MAC address, and the element is marked as 'disabled' to stop you editing it in the device detail panel. Edit the input element (typically by double-click) and set it to 'enabled'.
<input id="client_macaddr_field" type="text" value="" class="input_32_table client_input_text_disabled" enabled>
Click enter to save the changes to the HTML.
4) In the DHCP form you can now overwrite the MAC address with the upper case value.
5) Click the Apply button. This sets the value correctly in NVRAM.
6) Repeat these steps for every lower case MAC in your DHCP table.
"View List" works like a charm.
So, in conclusion, if the manual DHCP assignment screen ensures MAC addresses are converted to upper case, none of these issues would exist. Also, deletion of a device from the manual DHCP table should also delete it from NVRAM.
I hope this helps everyone. It took me a couple of hours of debugging to work this out.