Assign Device Names in System-Wireless Log specifically for AIMesh Nodes? And change AIMesh Host Name

[jksmurf]

A while back I got some very good advice from @drinkingbird and @RMerlin regarding how Asus or Asus-merlin source the device name under the system log-wireless log tab. In summary:

The vast majority of pages throughout the Asus will use DNS name (which is either what the client has reported when it obtains an IP, or the hostname you assigned when you created a DHCP reservation for it). When neither of those exists, you'll either see a generic vendor name, or "not found" or similar. So if you've set a static IP on something, you're going to see "not found" most likely.

You want all of your LAN devices pointing to the router as your DNS server. The router is the only thing that should point to cloudflare.

If you must have static IPs for anything, only use DHCP reservations, leave all of the devices set to DHCP and let them learn their settings from what you've configured in the router. By setting a static IP on the device it never goes to DHCP thus the router has no way of putting its hostname into DNS.

and

From what I can see and what he confirmed, it follows this:
1. Pull name from DHCP active lease list
2. If not there, pull name from user defined name list
3. If not there, display <unknown>

So I pretty much removed all the Static IP settings from my devices and let the DHCP Reservations name them and the table on the screen looks great.

However I have noticed with some dismay that my AIMESH Node, whose IP Address (that I know) is defined by the AIMESH System and therefore I am loathe to add a reservation for it, shows both device name and IP Address as "unknown".

Is there a simple way to get the system to populate these Mesh Nodes with a name (that I can define or is at least defined in the Router by Model etc)? There is no way you get into the AIMesh Router WebGUI to give it a name (save to update FW and adjust Jumbo Frames). I can SSH into it, and use amtm on on it for the MerlinAU addon.

If it works, are there any disadvantages to adding the IP Address that AIMESH gave the node, to my DHCP reservations or will AIMESH just go and shift this (now reserved) address?

TIA

k.

 

[jksmurf]

Apologies for the wee bump, but was thinking about whether this is just something that cannot be done as the nodes are set up by Asus AIMESH which Merlin notes is closed source.

Or is there still some way to issue a command via the CLI which would make the Wireless log recognize the node beyond “unknown”?

 

[eibgrad]

I don't use AiMesh. But are you even sure it uses IP addressing? It's entirely possible for a mesh network to work at layer 2 (ethernet) using something like WDS, which is based on MAC addresses, NOT layer 3 (TCP/IP).

Same thing happens w/ an OpenVPN bridged tunnel. Assigning an IP address is optional. It's only really necessary if you intend to address the device via that MAC address over TCP/IP (e.g., for configuration purposes). But even then, TCP/IP might be bound to some other network interfaces on the node for those purposes.

Again, I don't use AiMesh, but I'm familiar w/ some of the underlying technologies that often make up such systems. And in order for them to work efficiently and w/ the fewest problems, usually these devices are bound at the ethernet level, NOT TCP/IP.

Might help if you dumped ifconfig to see if in fact there is an IP assigned to that MAC address in the device list.

Just something to consider.

 

[jksmurf]

I don't use AiMesh. But are you even sure it uses IP addressing?

TBH, I do not really know, sorry.

It's entirely possible for a mesh network to work at layer 2 (ethernet) using something like WDS, which is based on MAC addresses, NOT layer 3 (TCP/IP).

Same thing happens w/ an OpenVPN bridged tunnel. Assigning an IP address is optional. It's only really necessary if you intend to address the device via that MAC address over TCP/IP (e.g., for configuration purposes). But even then, TCP/IP might be bound to some other network interfaces on the node for those purposes.

Again, I don't use AiMesh, but I'm familiar w/ some of the underlying technologies that often make up such systems. And in order for them to work efficiently and w/ the fewest problems, usually these devices are bound at the ethernet level, NOT TCP/IP.

Might help if you dumped ifconfig to see if in fact there is an IP assigned to that MAC address in the device list.

I did that, maybe you can see something here but I cannot see any 04:42 etc device?

Just something to consider.

Thank you for looking at this .

 

[Tech9]

shows both device name and IP Address as "unknown"

Unlikely to fix this, but you can get better SNR if you drop the 160MHz wide channel and use 80MHz. The difference is ~3dBm ~3db.

 

[octopus]

The difference is ~3dBm.

dBm is a absolute value, 0dBm is 1mW.
It should be ~3db difference.

 

[eibgrad]

I did that, maybe you can see something here but I cannot see any 04:42 etc device?

As you indicated yourself, there is no 04:42 MAC address in that dump. In fact, it appears to be a dump of the primary router based on the IP address (192.168.9.1), NOT an AiMesh Node. So 04:42 belongs to some other device.

Notice the dump does contains references to wds, which is most likely the building blocks for connecting the AiMesh network. And those are all using IPv6.

 

[jksmurf]

it appears to be a dump of the primary router based on the IP address (192.168.9.1), NOT an AiMesh Node

My apologies, I captured the ifconfig from the Main Router not the Mesh node. Attached is the log from the node.

It does contains 04:42:xx references, quite a few of them. Hopefully some further info that gives you a clue?

k.

 

[eibgrad]

Well that's definitely progress. But now I don't know which of the many 04:42 MAC addresses is the one from your initial posting (you've obscured it).

 

[jksmurf]

Well that's definitely progress. But now I don't know which of the many 04:42 MAC addresses is the one from your initial posting (you've obscured it).

Oops. From the Wireless log. Node is connected wirelessly.

Wireless 2.4GHz
04:42:1A:58:0F:A1
<unknown>
130 / 216 Mbps
-56 dBm 6:30:33 2 (ax)
20MHz _STMAU

Wireless 5 GHz
04:42:1A:58:0F:A4
<unknown> <unknown>
272 / 612 Mbps
-65 dBm 6:30:35 4 (ax)
160MHz _STMAU

 

[eibgrad]

On that same device, post the following dump.

brctl show

 

[jksmurf]

On that same device, post the following dump.

brctl show

 

[eibgrad]

I assume this node is connected over wireless to the router, and NOT over wire (i.e. wired backhaul).

Is the image you posted initially from the router or node?

 

[jksmurf]

I assume this node is connected over wireless to the router, and NOT over wire (i.e. wired backhaul).

That is correct

Is the image you posted initially from the router or node?

From the Router. It’s where I’d like it to show the name of the Node in the Router Wireless Log.

You noted you don’t use AIMESH but FYI the nodes do not have a usable WebGui, you can only update the FW, change Jumbo Frames, that’s it.

 

[eibgrad]

Well given what I'm seeing, it doesn't surprise me that you wouldn't see a named connection. As stated by others, you typically don't see a named connection unless it's coming from DHCP leases, and that, by definition, is at the IP level. As I said, mesh systems typically don't get connected at the IP level, but at the ethernet level, where there is no such thing as naming (devices find each other by arp broadcasts, NOT ip). So I don't see how there's a way to address the issue (i.e., providing a name) in this case. It's hard enough to deal w/ static IPs when it comes naming. But at least you have the option (at least most of the time) to establish a reservation w/ DHCP, and thus assign a name.

Realize that given my limited knowledge of AiMesh, I can only speak is broad terms. I don't know all the intricacies of the ASUS product line in this regard.

 

[jksmurf]

Well given what I'm seeing, it doesn't surprise me that you wouldn't see a named connection. As stated by others, you typically don't see a named connection unless it's coming from DHCP leases, and that, by definition, is at the IP level. As I said, mesh systems typically don't get connected at the IP level, but at the ethernet level, where there is no such thing as naming (devices find each other by arp broadcasts, NOT ip).

OK, thank you, I think I understand that.

So I don't see how there's a way to address the issue (i.e., providing a name) in this case. It's hard enough to deal w/ static IPs when it comes naming.

OK

But at least you have the option (at least most of the time) to establish a reservation w/ DHCP, and thus assign a name.

This is where I am a little bit unsure what will happen if I try; the IP Address is assigned by the Router at the time the AIMesh Node is added, so I know what it is, but I am a wee bit nervous that if I now (on the LAN DHCP Manual Assignment Page) try to assign the known MAC Address(es) to the same (known) Mesh Node IP (or even a different IP), that it'll somehow cause the AIMesh node to disassociate.

The second issue is that there are two MAC Addresses for the "unknown" Node device, a 2.4GHz one and a 5GHz one, so I'd actually need to assign two IP Addresses (and should one be the IP Address already assigned?), whereas AIMesh only assigns one.

Realize that given my limited knowledge of AiMesh, I can only speak is broad terms. I don't know all the intricacies of the ASUS product line in this regard.

No problem and I really appreciate you taking the time to investigate it and have a think about what is happening.

It's no biggie TBH, I know what the device is, just doesn't get a 'nice' name like my other devices do, so I have to think about 'what device is that' when I look at the Wireless log.

ta

k.

 

[jksmurf]

So, being curious about what would happen to the wireless log naming if I manually assigned an IP Address to the known MAC address, I went ahead and did that.

Bearing in mind that the mesh node is on 192.168.9.29 as assigned by the main mesh router, my trial was to see if I assigned an IP address 192.168.9.249 and 192.168.9.250 to the two MACs respectively,

• Wireless 2.4GHz 04:42:1A:58:0F:A1
• Wireless 5 GHz 04:42:1A:58:0F:A4

whether on reboot of the node, or of the main router (both of which I did), the node would pick up the assigned IP address of the (5GHz) Wifi Backhaul. It did not. Note I do not use a wired backhaul.

Instead, as shown in the attached picture, it retained the 192.168.9.29 IP address and shows the MAC as being A0 instead.

• 04:42:1A:58:0F:A0

I was going to do one last try and reset the node to see if when I re-added it, it switched to the assigned IP but when I saw the A0 I decided against it.

What did come out of this though, is that the Wireless Log now actually shows the name of the device I reserved under LAN DHCP, so rather than just showing a MAC Address and an “unknown” device (as it did before), it now shows the MAC and a real name. So that’s useful. No idea what happens to the two reserved IP addresses, they are not accessible. I guess they just become name placeholders as far as this exercise goes.

The devices are both shown as being “offline” in the IP field even though they do appear connected.

Someone with more knowledge than me might be able to comment further based on the ifconfig and brctl show logs posted above, it just seems odd that it uses what appears to be the Ethernet MAC address to assign the Router to, even though it’s not actually connected via Ethernet, but via Wireless.

k.

 

[jksmurf]

Instead, as shown in the attached picture, it retained the 192.168.9.29 IP address and shows the MAC as being A0 instead.

• 04:42:1A:58:0F:A0

Another recent thread pointed me to an older thread which suggested you can modify the AIMesh IP address based on the MAC (which as noted above, still puzzlingly seems to be an Ethernet one, even though I have a wireless backhaul) and this does indeed work. I assigned it 192.168.9.3, rebooted and it sticks.

It shows up in System Log - DHCP leases and in the AIMesh tab network details but as before, not in the Network Map nor in the System Log - Wireless Log.

{EDIT] Just to complete the circle on the desire to:

(a) Assign your preferred IP Address to AIMEsh Nodes vs that assigned by AIMesh itself; and
(b) Change the Host Name of your AIMesh Node (LAN, LAN-IP Tab, Host Name field)
(c) Renaming "unknown" AIMesh Devices in Wireless Log (for easy identification)

(a) As discussed above but summarised here:

If you’re looking to change the IP of the AIMesh Node to what you want, you need to find and assign the ETHERNET MAC in the WebGUIs LAN, DHCP Manual Assignment, but it’s not intuitive at all as that address never shows up in the dropdown list. You need to find it. So where is it?

Well it is in the AIMesh Menu, just select the AIMesh Node and at the top of the RH menu, in the picture is the MAC Address of the Node; it is an Ethernet Address, NOT a Wireless one regardless of whether you have a Wired or Wireless Backhaul.

Note that whilst the Wireless log might show up s 2.4GHz and 5GHz device (which incidentally you can also manually assign an IP Adrress) neither is the AIMesh Node MAC Address.

Folks on wired backhaul will be better placed to accept the AIMesh Node MAC as the MAC address you use to assign your preferred address (once they work out where it is), but those on wireless will be going “huh???”, especially as the Wireless Log doesn’t have any IP addresses but still shows the “unknown” devices.

It’s like ASUS said “here’s AIMesh, it’s all a big secret”. There’s a lot of folks saying “don’t mess with it” but once it’s all connected up and the routers and nodes have been introduced to each other there’s no reason why these “new neighbours” can’t “move house”, if you will; they’re still the same people, they now just live at a different address.

(b) For this item, see Here and Here for the background. Essentially:

"You can access the GUI of a mesh node by running in that node ssh session the command 'nvram set re_mode=0' before acesssing its login page. Remember never to run 'nvram commit' (this includes any action in GUI which could commit) with re_mode set to 0 since it is reported to cause problems. When you are finished just run 'nvram set re_mode=1' to return to a safe state."

What happens is that this CLI command, which you issue via SSH, makes the menu appear as if the AIMesh Node was a Repeater i.e. it IS the repeater menu.

You can then go into (LAN, LAN-IP Tab, Host Name field) and change the host name of the node to what I want it to be.

On mine, originally it was RT-AX3000-FA0D or something and I changed it to just RT-AX3000. Hitting Apply made me lose AIMesh but the router still came up at my (new) IP address and I changed the setting 'nvram set re_mode=1" (i.e. back to 1) and the mesh node came back.

[EDIT] See thread below for a CLI approach to (b).

(c) For Renaming "unknown" AIMesh Devices in Wireless Log (for easy identification)

See above pictures, but simply put, on your main router, LAN, DHCP, Manual Assignment, assign an IP Address (and names) to the MAC Address of the "unknown" devices you see in System Log, Wireless Log.

They will STILL show as 'offline', but they are NOT (as shown by the Rx/Tx & RSSI details and Streams columns). But at least you can see what the device is (as per manual name given by you, based on the Wireless MAC). You cannot access anything using these assigned Wireless IPs, they are for naming purposes only.

 

[ExtremeFiretop]

{EDIT] Just to complete the circle on the desire to:

(a) Assign your preferred IP Address to AIMEsh Nodes vs that assigned by AIMesh itself; and
(b) Change the Host Name of your AIMesh Node (LAN, LAN-IP Tab, Host Name field)
(c) Renaming "unknown" AIMesh Devices in Wireless Log (for easy identification)

For item b) I usually just set this value in nvram instead of poking around the UI first.

nvram set lan_hostname="HOSTNAME"

 

[jksmurf]

For item b) I usually just set this value in nvram instead of poking around the UI first.

lan_hostname="HOSTNAME"

Sure seems easier! Thanks for the heads up

[EDIT] I found full instructions for this CLI (via SSH) approach in this thread.
Essentially (paraphrasing):

1. Verify that nvram get lan_hostname returns the current host name of your satellite node.
2. Change the value of this variable by running nvram set lan_hostname=CoolName.
3. Then type nvram commit.
4. Then type reboot.