merlin firmware 386.4 issue?

[d_v_us]

I recently updated my merlin firmware to 386.4 and everything is rock solid but I've noticed that most of the clients that connect now doesnt show me that name of the device anymore Basically I get the MAC addresses but in previous versions I'd have the device name....comes in handy when I need to configure my parental controls. Has anyone else experienced this with 386.4.?

 

[ColinTaylor]

What exactly are you looking at that doesn't show these names?

 

[hancox]

I recently updated my merlin firmware to 386.4 and everything is rock solid but I've noticed that most of the clients that connect now doesnt show me that name of the device anymore Basically I get the MAC addresses but in previous versions I'd have the device name....comes in handy when I need to configure my parental controls. Has anyone else experienced this with 386.4.?

Are they i-devices? Are you sure they were present immediately prior?

Apple released an iOS change which would hide these names by default.

 

[ozjason]

Can confirm, there appears to be a bug in 386.4 which obliterates the DHCP host names list. I am able to reproduce it 100% of the time. When you open a device from the network map which does NOT have "Mac and IP Address Binding" turned on, and you enable that toggle, the DHCP host names list is wiped out. Restoring a settings backup restores the host names. DHCP reservations can be made via the DHCP server page without issue, this only occurs when the "Mac and IP Address Binding" toggle is used from that particular popup window in the network map (or AIMESH device list).

Exact STR (requires at least one device connected without an existing DHCP reservation):

1. select Network Map from router settings page
2. select Clients
3. click on the icon for any device in the list that does NOT already have a DHCP reservation
4. ensure "Mac and IP Address Binding" is not already toggled on (if it is, bug won't replicate)
5. Toggle "Mac and IP Address Binding" to ON (leave the host name and other settings alone)
6. go to LAN -> DHCP Server
7. Observe that all DHCP host names have been deleted. Adding new names works, but old ones don't come back.

I am seeing this on an RT-AX86U with an RT-AC86U AIMESH node both running 386.4, unsure if this is relevant to the bug. This issue only occurred since 386.4 and I note from the changelog, the format of the dhcp list changed here to adopt ASUS's new format.

 

[JWoo]

Can confirm, there appears to be a bug in 386.4 which obliterates the DHCP host names list. I am able to reproduce it 100% of the time. When you open a device from the network map which does NOT have "Mac and IP Address Binding" turned on, and you enable that toggle, the DHCP host names list is wiped out. Restoring a settings backup restores the host names. DHCP reservations can be made via the DHCP server page without issue, this only occurs when the "Mac and IP Address Binding" toggle is used from that particular popup window in the network map (or AIMESH device list).

Exact STR (requires at least one device connected without an existing DHCP reservation):

1. select Network Map from router settings page
2. select Clients
3. click on the icon for any device in the list that does NOT already have a DHCP reservation
4. ensure "Mac and IP Address Binding" is not already toggled on (if it is, bug won't replicate)
5. Toggle "Mac and IP Address Binding" to ON (leave the host name and other settings alone)
6. go to LAN -> DHCP Server
7. Observe that all DHCP host names have been deleted. Adding new names works, but old ones don't come back.

I am seeing this on an RT-AX86U with an RT-AC86U AIMESH node both running 386.4, unsure if this is relevant to the bug. This issue only occurred since 386.4 and I note from the changelog, the format of the dhcp list changed here to adopt ASUS's new format.

Good troubleshooting!

 

[ColinTaylor]

Can confirm, there appears to be a bug in 386.4 which obliterates the DHCP host names list. I am able to reproduce it 100% of the time. When you open a device from the network map which does NOT have "Mac and IP Address Binding" turned on, and you enable that toggle, the DHCP host names list is wiped out. Restoring a settings backup restores the host names. DHCP reservations can be made via the DHCP server page without issue, this only occurs when the "Mac and IP Address Binding" toggle is used from that particular popup window in the network map (or AIMESH device list).

Exact STR (requires at least one device connected without an existing DHCP reservation):

1. select Network Map from router settings page
2. select Clients
3. click on the icon for any device in the list that does NOT already have a DHCP reservation
4. ensure "Mac and IP Address Binding" is not already toggled on (if it is, bug won't replicate)
5. Toggle "Mac and IP Address Binding" to ON (leave the host name and other settings alone)
6. go to LAN -> DHCP Server
7. Observe that all DHCP host names have been deleted. Adding new names works, but old ones don't come back.

I am seeing this on an RT-AX86U with an RT-AC86U AIMESH node both running 386.4, unsure if this is relevant to the bug. This issue only occurred since 386.4 and I note from the changelog, the format of the dhcp list changed here to adopt ASUS's new format.

Good spot. I don't actually see the problem manifesting on my router when following your process. However, that's probably just luck because I can see that the Client List doesn't seem to be adding the new entries in the same format. Specifically it doesn't seem to be adding the ">>" before what is effectively a null hostname.

For example, adding an entry from the Client List creates:

<94:DE:80:C5:79:52>192.168.1.49>

whereas adding it through LAN>DHCP creates:

<94:DE:80:C5:79:52>192.168.1.49>>

But this doesn't actually sound like the problem the OP was describing.

 

[SANdood]

I am seeing this on an RT-AX86U

I see it also on GT-AX11000 with 386.4

 

[Invisible Boy]

Happens to my AX11000 too but I am not sure if it's 386.4 specific as I didn't pay attention to it. However, a somewhat related issue is that the manually assigned names aren't displayed properly in the Wireless Log. This applies to the older Merlin FWs too even on my AC68U. Maybe it's a coincidence, the affected devices are all DHCP.

 

[d_v_us]

Are they i-devices? Are you sure they were present immediately prior?

Apple released an iOS change which would hide these names by default.

Thanks...just went in and found that info....it was kinda buried under the IOS wifi settings where you can toggle it off and on....thanks. While I applaud Apple for their privacy stance....as a parent makes me work a little harder

 

[bbunge]

Can confirm, there appears to be a bug in 386.4 which obliterates the DHCP host names list. I am able to reproduce it 100% of the time. When you open a device from the network map which does NOT have "Mac and IP Address Binding" turned on, and you enable that toggle, the DHCP host names list is wiped out. Restoring a settings backup restores the host names. DHCP reservations can be made via the DHCP server page without issue, this only occurs when the "Mac and IP Address Binding" toggle is used from that particular popup window in the network map (or AIMESH device list).

Exact STR (requires at least one device connected without an existing DHCP reservation):

1. select Network Map from router settings page
2. select Clients
3. click on the icon for any device in the list that does NOT already have a DHCP reservation
4. ensure "Mac and IP Address Binding" is not already toggled on (if it is, bug won't replicate)
5. Toggle "Mac and IP Address Binding" to ON (leave the host name and other settings alone)
6. go to LAN -> DHCP Server
7. Observe that all DHCP host names have been deleted. Adding new names works, but old ones don't come back.

I am seeing this on an RT-AX86U with an RT-AC86U AIMESH node both running 386.4, unsure if this is relevant to the bug. This issue only occurred since 386.4 and I note from the changelog, the format of the dhcp list changed here to adopt ASUS's new format.

Fresh install of 386.4 with Hard Factory Reset then manual config. Followed your steps except after #5 I clicked OK as you need to do to save a setting.

None of the host names were deleted as you reported in step #7. I seem to remember that there were changes made to dnsmasq in this release. If you did a dirty upgrade or used prior saved settings that may have caused your "bug."

 

[RMerlin]

I am seeing this on an RT-AX86U with an RT-AC86U AIMESH node both running 386.4, unsure if this is relevant to the bug. This issue only occurred since 386.4 and I note from the changelog, the format of the dhcp list changed here to adopt ASUS's new format.

Can't reproduce here, and looking at the code I don't see how this could be happening either. That network client code will only edit an existing entry or add a new entry to the list, it will not touch existing entries, so I don't see how they could be affected. Make sure you aren't running a third party script that also manipulates the dhcp_staticlist array.

Specifically it doesn't seem to be adding the ">>" before what is effectively a null hostname.

New entries are indeed missing that new field, but the rest of the firmware code is able to handle these shorter entries since anyone upgrading from an older stock firmware would have entries without that new field. The firmware code will only require the two first mandatory fields. The missing field would get added whenever the dhcp_staticlist gets edited by the user through the DHCP static lease page.

I'll still fix that for better consistency.

 

[tyspeed42]

I do not see this issue either on my first AX86U nor my second AX86U.