[Official Release] AiMesh Firmware v3.0.0.4.384.10007 for All Supported Products

[ggruszynski]

I have Signal Strength and SNR measurements throughout the house and property from a single, non-mesh AC68W. Ranges from great (obviously) to -75dBmon 2.4GHz and -85dBm on 5GHz at the farthest areas I'd like good signal.

-75/-85 dBm is likely too far, but what about maybe -55/-65 dBm? Will that 5GHz signal be strong enough at -65dBm to be an effective node on a mesh network? It certainly isn't a 'dead zone'.

Any input/advice/suggestions?.

-65dBm in my world (telecom) would be considered "hot", but not so much for wifi. Would think that RSSI would provide a good link for backhaul. Can always test and see, but think any closer than -55dBm would cause too much noise with the overlap personally. Below are some useful links:

https://www.excentis.com/blog/wi-fi...ents-wireless-infrastructure-based-shaky-data

https://community.arubanetworks.com...ip-between-data-rate-SNR-and-RSSI/ta-p/178312

 

[Stephen Harrington]

Not quite agree, I also have some ip cam which I want them connect to specific node only because sometime they will connect to another node which have limited backhaul bandwidth

Yep, there are all kinds of situations where the solution to the “problem” is being able to lock a device to a specific Node/AP.

StephenH

 

[arthurlien]

Yep, there are all kinds of situations where the solution to the “problem” is being able to lock a device to a specific Node/AP.

StephenH

If there is no any bug/issue in devices, have any use case you MUST to lock to a specific Node/AP?

我從使用 Tapatalk 的 ASUS_Z012DA 發送

 

[Matt84]

I have spent 3 hours trying to get my AC3100 to see my AC68u as a node. No go. lol I feel like this may still be buggy as anything. Reset the ac68u multiple times. Even had it laying on the ac3100 at one point. nadda. Both are on the 384_10007 firmware. I emailed Asus about it yesterday but just kinda got the run around. I have an ac1900 I was going to set up after this but will leave well enough alone for now I think (68u and 1900 are currently AP's with a ethernet connection to a switch and then the router which I gather is presently also an issue from reading).

 

[glugglug]

If there is no any bug/issue in devices, have any use case you MUST to lock to a specific Node/AP?

我從使用 Tapatalk 的 ASUS_Z012DA 發送

"MUST" is a strong word. I set Rokus, Chromecasts, and the thermostat to guest networks on the access point in the same room as them rather than leave it to chance which they connect to.

 

[Stephen Harrington]

If there is no any bug/issue in devices, have any use case you MUST to lock to a specific Node/AP?

我從使用 Tapatalk 的 ASUS_Z012DA 發送

@arthurlien Well that's a hard one to answer for sure, as I can't definitely say until I roll out the AiMesh setup (4 X AC68U AP's) properly to the house.
I'm hanging off doing that at present and just playing with them "on the bench" whilst following this thread and watching developments.

But I CAN say that under my current setup, which is 4 X TP-Link WDR-4300 "Wireless N" AP's set with identical SSIDs, I have a specific use case that requires this.

I have 2 X IP cameras which are in fixed positions but happen to both be within strong signal zones of at least 2 AP's.
These get triggered by movement and get recorded by software running on a macOS server.
I was finding that both cameras would randomly just disconnect at times and the recordings would be truncated or fail.
I fixed this on the current AP's by blacklisting the MAC addresses of the 2 X IP cams on all but the "closest" AP.
It's worked fine ever since.

Since I see no current way to achieve this "selective AP Node blacklisting/whitelisting" in AiMesh, my concern would be that the IP Cams will behave in the "old" way once I cut across to the AiMesh setup. To reinforce this I also note a lot of comments on here about how devices tend to initially connect to the closest/strongest Node but over time roam to the Router Node, even though that may not be the closest/strongest, which reinforces my concern.

This doubt plus the lack of guest networks across all Nodes is my main excuse for holding off. That and hoping there may be a new build soon that improves some of this.
If it was just me in the house I'd put them into position and see how it goes, but its NOT just me and other members of the household expect working Wifi at all times and if it fails it's always my fault!

If I do get a good chunk of hours on my own I may give it a go anyway ...

StephenH

 

[Richard Li]

Well that's a hard one to answer for sure, as I can't definitely say until I roll out the AiMesh setup (4 X AC68U AP's) properly to the house.
I'm hanging off doing that at present and just playing with them "on the bench" whilst following this thread and watching developments.

But I CAN say that under my current setup, which is 4 X TP-Link WDR-4300 "Wireless N" AP's set with identical SSIDs, I have a specific use case that requires this.

I have 2 X IP cameras which are in fixed positions but happen to both be within strong signal zones of at least 2 AP's.
These get triggered by movement and get recorded by software running on a macOS server.
I was finding that both cameras would randomly just disconnect at times and the recordings would be truncated or fail.
I fixed this on the current AP's by blacklisting the MAC addresses of the 2 X IP cams on all but the "closest" AP.
It's worked fine ever since.

Since I see no current way to achieve this "selective AP Node blacklisting/whitelisting" in AiMesh, my concern would be that the IP Cams will behave in the "old" way once I cut across to the AiMesh setup. To reinforce this I also note a lot of comments on here about how devices tend to initially connect to the closest/strongest Node but over time roam to the Router Node, even though that may not be the closest/strongest, which reinforces my concern.

This doubt plus the lack of guest networks across all Nodes is my main excuse for holding off. That and hoping there may be a new build soon that improves some of this.
If it was just me in the house I'd put them into position and see how it goes, but its NOT just me and other members of the household expect working Wifi at all times and if it fails it's always my fault!

If I do get a good chunk of hours on my own I may give it a go anyway ...

StephenH

I do not think AiMesh will support "selective AP Node blacklisting/whitelisting" in the future anyway. AiMesh is aimed at centralized management with auto node selection. This feature just defeat the purpose. I think you can stay with the manual AP mode to have full control.

 

[Richard Li]

Yes.

Well, I have tried the MAC address filter and it seems it is not working properly in my configuration and I can always repeat it.

Configuration: RT-AC88U AP + RT-AC88U node + RT-AC68U node
MAC address filter settings: Allow + <allow list>

After I have setup both 2.4G and 5G MAC address filtering. I wait a while for the settings to propagate to the nodes, then I figured out that the 2 RT-AC88U is working properly without any problem; while the RT-AC68U node is having problem in authenticating any STA that is in the mac address filtering list.

Then I SSH into the RT-AC68U and check the nvram settings and found that these fields are properly updated with the values found in the main AP:
wl0.1_maclist
wl0.1_maclist_x
wl1.1_maclist
wl1.1_maclist_x

I suspect that the settings that propagated to the RT-AC68U may have some problem.

 

[Richard Li]

I have spent 3 hours trying to get my AC3100 to see my AC68u as a node. No go. lol I feel like this may still be buggy as anything. Reset the ac68u multiple times. Even had it laying on the ac3100 at one point. nadda. Both are on the 384_10007 firmware. I emailed Asus about it yesterday but just kinda got the run around. I have an ac1900 I was going to set up after this but will leave well enough alone for now I think (68u and 1900 are currently AP's with a ethernet connection to a switch and then the router which I gather is presently also an issue from reading).

I have successfully connect 68U to 88U as a node, however you need to make sure the following things:
1. Need to do factory reset of both devices (pressed WPS button -> power on -> wait until power LED flashed -> release WPS button)
2. Place both devices closer to each other for best Wifi signal for binding
3. Can try to repeat the factory reset procedure to the node if not found

Hope this helps.

 

[Richard Li]

It should be, but my experience of mac filter on 384.10007 is it totally broken, when I enable it the node will reject all wifi connect include those white listed

Ha, missed your message. Well, I have 3 devices: 88U as AP, 88U as node and 68U as node. It works for both 88U, only the 68U is not working in which it reject everything.

See if they can fix it.

I always think that they should have some bugs in configuration sync, since they support many different devices with different hardware, they need to take care how the config should be transformed when syncing to other devices and this kind of transformation will generate problems easily.

 

[Stephen Harrington]

I do not think AiMesh will support "selective AP Node blacklisting/whitelisting" in the future anyway. AiMesh is aimed at centralized management with auto node selection. This feature just defeat the purpose. I think you can stay with the manual AP mode to have full control.

@Richard Li Are you speaking in some official capacity or with some inside knowledge?
I don't see why it defeats the purpose. You can have fine-grain control and still centrally manage. They are not mutually exclusive.
Just because options are there doesn't mean you have to use them?
You may well be correct that AiMesh will never get this degree of control but @arthurlien asked for a use case so I gave him one.
There would be many more customers out there with similar use cases, I don't think I'd be alone.
And sure, I've always got the option to go back to pure AP mode, but with that comes pluses and minuses.
At the moment it's line-ball as to whether AiMesh has any advantages for me, but it's keeping my interest for now.
I am still hoping with further development and features being added that on balance it tilts towards AiMesh "helping more than it is hindering" , for my needs at least, as I think the basic idea of it is a good one.

StephenH

 

[Richard Li]

I have encounter another DUMP yesterday, I have attached the full log as well:

Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 srom rev:0
Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 initvars_srom_pci, SROM CRC Error
Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 initvars_srom_pci, Using external nvram
Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 Setting clocks to 800/400/200
Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 si_set_bb_vcofreq_frac: only work on 4360, 4350
Jan 26 10:56:30 kernel: DUMP CONSOLE: 000000.000 Enabling D-cache
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.568 gic_dist_init max_irq 64
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.569 c_init: Watchdog reset bit set, clearing
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.569
Jan 26 10:56:30 kernel: DUMP CONSOLE: RTE (PCIE-MSG_BUF) 10.10.69.69019 (r736230) on BCM4366 r3 @ 40.0/200.0/800.0MHz
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.569 nvram_init: called again without calling nvram_exit()
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.570 initvars_cis_pci: Not CIS format
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 srom rev:0
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 initvars_srom_pci, SROM CRC Error
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 initvars_srom_pci, Using external nvram
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 allocating a max of 511 rxcplid buffers
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 pciemsgbuf0: Broadcom PCIE MSGBUF driver
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 nvram_init: called again without calling nvram_exit()
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.602 initvars_cis_pci: Not CIS format
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.634 srom rev:0
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.634 initvars_srom_pci, SROM CRC Error
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.634 initvars_srom_pci, Using external nvram
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.634 wlc_ucode_download: wl0: Loading non-MU ucode
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.635 reclaim section 0: Returned 216 bytes to the heap
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.635 initvars_cis_pci: Not CIS format
Jan 26 10:56:30 kernel: DUMP CONSOLE: 026738.667 srom rev:0
Jan 26 10:56:31 kernel: DUMP CONSOLE: 026738.667 initvars_srom_pci, SROM CRC Error
Jan 26 10:56:31 kernel: DUMP CONSOLE: 026738.667 initvars_srom_pci, Using external nvram
Jan 26 10:56:31 kernel: DUMP CONSOLE: 026738.667 wlc_bmac_attach, deviceid 0x43c4 nbands 1
Jan 26 10:56:31 kernel: DUMP CONSOLE: 026738.668 ipxotp_init: mapping otpbase at 0x18007000 to 0x18007000

 

[arthurlien]

@Stephen Harrington,
I would like to know what kind of use case can't meet with current design.... In case, when you locked one device to one node and node disappeared, this device will not connect any other nodes. That is why i use the wording as "MUST".

 

[sinman02]

Any ETA on support for RT-AC66U?

 

[arthurlien]

Any ETA on support for RT-AC66U?

Please refer to ASUS official website.

我從使用 Tapatalk 的 ASUS_Z012DA 發送

 

[Stephen Harrington]

@Stephen Harrington,
I would like to know what kind of use case can't meet with current design.... In case, when you locked one device to one node and node disappeared, this device will not connect any other nodes. That is why i use the wording as "MUST".

Apologies @arthurlien but I’m not quite understanding your explanation and question. Could you explain further please?

StephenH

 

[arthurlien]

Apologies @arthurlien but I’m not quite understanding your explanation and question. Could you explain further please?

StephenH

Don't apologies.... I known you need the feature to set a device to connect specific Node. But i need to clarify the reason why you need it. I think if the Mesh network is stabled, no matter which node it connected. Maybe you can give me some use case/reason/problem you meant to discuss with Internal Team....

Base on your IPCAN case, if MAC filter feature is working normal, it could be solved your IPCAN's problem. Am i correct ?

Apologies @Stephen Harrington , i just try to understand what you need and why you need...

BTW, let me check the MAC Filter works normal or not first. (Including AiMesh Router and AiMesh Node)

 

[arthurlien]

Don't apologies.... I known you need the feature to set a device to connect specific Node. But i need to clarify the reason why you need it. I think if the Mesh network is stabled, no matter which node it connected. Maybe you can give me some use case/reason/problem you meant to discuss with Internal Team....

Base on your IPCAN case, if MAC filter feature is working normal, it could be solved your IPCAN's problem. Am i correct ?

Apologies @Stephen Harrington , i just try to understand what you need and why you need...

BTW, Maybe someone can give me for input ......

 

[Richard Li]

Don't apologies.... I known you need the feature to set a device to connect specific Node. But i need to clarify the reason why you need it. I think if the Mesh network is stabled, no matter which node it connected. Maybe you can give me some use case/reason/problem you meant to discuss with Internal Team....

Base on your IPCAN case, if MAC filter feature is working normal, it could be solved your IPCAN's problem. Am i correct ?

Apologies @Stephen Harrington , i just try to understand what you need and why you need...

BTW, let me check the MAC Filter works normal or not first. (Including AiMesh Router and AiMesh Node)

MAC filter is not working in my case:
88U AP + 88U and 68U nodes
After setting sup MAC filtering, both 88U are working properly while the 68U did not accept any connection from any STA

 

[arthurlien]

MAC filter is not working in my case:
88U AP + 88U and 68U nodes
After setting sup MAC filtering, both 88U are working properly while the 68U did not accept any connection from any STA

only 68U did not work ?