Mesh Wireless is not associated

Hi

I'm trying to get Mesh (802.11s) to work on my WRT1900ACS. Unfortunately LuCI just says "Wireless is not associated" and using a Wi-Fi analyser I can't see any additional AP's.

I typed the following command to see if my router supports mesh:-

iw list | grep "Supported interface modes" -A 9


        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 1:
                Capabilities: 0x106f
                        RX LDPC
                        HT20/HT40
--
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x106f
                        RX LDPC
                        HT20/HT40

iw wlan1 get mesh_param

Possible mesh parameters are:
 - mesh_retry_timeout
 - mesh_confirm_timeout
 - mesh_holding_timeout
 - mesh_max_peer_links
 - mesh_max_retries
 - mesh_ttl
 - mesh_element_ttl
 - mesh_auto_open_plinks
 - mesh_hwmp_max_preq_retries
 - mesh_path_refresh_time
 - mesh_min_discovery_timeout
 - mesh_hwmp_active_path_timeout
 - mesh_hwmp_preq_min_interval
 - mesh_hwmp_net_diameter_traversal_time
 - mesh_hwmp_rootmode
 - mesh_hwmp_rann_interval
 - mesh_gate_announcements
 - mesh_fwding
 - mesh_sync_offset_max_neighor
 - mesh_rssi_threshold
 - mesh_hwmp_active_path_to_root_timeout
 - mesh_hwmp_root_interval
 - mesh_hwmp_confirmation_interval
 - mesh_power_mode
 - mesh_awake_window
 - mesh_plink_timeout

iw wlan0 get mesh_param

Possible mesh parameters are:
 - mesh_retry_timeout
 - mesh_confirm_timeout
 - mesh_holding_timeout
 - mesh_max_peer_links
 - mesh_max_retries
 - mesh_ttl
 - mesh_element_ttl
 - mesh_auto_open_plinks
 - mesh_hwmp_max_preq_retries
 - mesh_path_refresh_time
 - mesh_min_discovery_timeout
 - mesh_hwmp_active_path_timeout
 - mesh_hwmp_preq_min_interval
 - mesh_hwmp_net_diameter_traversal_time
 - mesh_hwmp_rootmode
 - mesh_hwmp_rann_interval
 - mesh_gate_announcements
 - mesh_fwding
 - mesh_sync_offset_max_neighor
 - mesh_rssi_threshold
 - mesh_hwmp_active_path_to_root_timeout
 - mesh_hwmp_root_interval
 - mesh_hwmp_confirmation_interval
 - mesh_power_mode
 - mesh_awake_window
 - mesh_plink_timeout

/etc/config/wireless > Mesh

config wifi-iface 'wifinet4'
	option mesh_rssi_threshold '0'
	option key 'password'
	option device 'radio1'
	option mode 'mesh'
	option mesh_id 'mesh'
	option mesh_fwding '0'
	option network 'lan'
	option encryption 'none'

Any ideas anyone?

Many thanks in advance

Will

mwlwifi falsely supports mesh mode. It exposes the capability to userspace whilst in reality, the binary blob that gets loaded into the 88w8864 flash doesn't support it.

Here is where it gets exposed to mac80211:



Here is where it exposes it's false capability via information element:

This can't be fixed with what's available in the open source "wrapper" of a driver. A lot of the functions are processed in the binary blob which has not been updated since 2016, and it won't be – given that the 88w8864 has been marked obsolete by the current owners of Marvell's wireless business unit, NXP. Perhaps, in the previous pipeline – the 88w8864 and 8894 was going to get proper mesh support at one point, and this was just the groundwork. However, clearly plans have been scrapped with the acquisition that has happened.

https://www.nxp.com/products/wireless/wi-fi-plus-bluetooth/88w8864:88W8864

Alternatively, instead of 802.11s mesh – you can run a WDS based system instead. @eduperez has experience with how to set up Linksys WRT AC routers with this config.

6 Likes

Conceivably point-to-point links and batman-adv would work as well, though I haven’t tried it.

1 Like

Happy new year everyone :slight_smile:

Well as you know I spent quite a bit of time with you @jeff and others getting my VLAN system working. I did this so that I could add a second AP using the existing WAN cable. I can confirm that all works lovely now.

I now just need to setup the wireless APs so that clients can freely roam across them. With Mesh 802.11s out of the window I will have a look at B.A.T.M.A.N.

I followed this guide here > https://www.radiusdesk.com/old_wiki/technical_discussions/batman_basic

but my mesh point still says "Wireless is not associated" and the interface was saying protocol not supported.

UPDATE
It seems that I missed the BSSID parameter from the Ad-hoc config. It seems to accept any MAC address and from LuCI it seems to be up and running, but I'm not convinced.

Ad-hoc

I also tried encryption but it shows nothing no matter what I select for the encryption method.

Is there anyway I can test to see if it's up and running?

Your wifi device needs to ahve a fixed channel (do not use "auto") otherwise the wireless will not be associated.
But I failed in the next step. My mesh wifi does not seem to have a SSID and therefore it is not shown in the list of wireless networks on my devices. On my Adnroid mobile I found it using "WifiJumper" but it does not have a name/SSID.

The radio this mesh is linked to has a fixed channel. Never use automatic channels.

A typical end-user OS (Android, Windows, etc) kernel wifi cannot connect directly to a mesh node, so it will not show such networks to users in the wifi settings.

Okay. That makes sense. Is there anyway I can test it?

I should mention that I am using a wired backhaul to connect the APs together. Does setting up a mesh add any benefit for better client roaming or am I just better off running dumb APs as I currently am?

Also 802.11s isn't supported on my Linksys WRT1900ACS so the ad-hoc mode is the only other AP mode I can use for setting up mesh.

You generally need at least two compatible routers to test your mesh.

There's no reason to mesh if there is a wired backhaul. Client roaming is a completely different issue than mesh linking. Commercial systems that do both but are advertised as "mesh" confuse this issue.

1 Like

If only someone was to implement a wireless access point management feature into the firmware we could load balance clients across multiple APs...

This is what confused me, too. I found many blog posts which seem to confirm that mesh solves the client roaming issue. (e.g. https://www.jayzon.de/2018/02/09/mesh-wlan-mit-openwrt/)

Unless you have (desktop-) linux clients, none of your smartphones, computers (neither Windows nor MacOS) or IoT/ smarthome appliances can communicate with the mesh itself, they depend on the individual mesh APs to repeat the signal via an ordinary AP interface (and if you look closer, you'll notice in your referenced blog post that they keep the ordinary AP interfaces in place).

The only thing a mesh might improve in terms of roaming issues, is the ability to span a closer -well- mesh of APs throughout the area, so chances for clients to be in range of a strong signal are improved. If you do that traditionally via wired APs or replace the wired backhaul with a dedicated mesh network (which is not seen by your clients) doesn't really matter, but for obvious reasons a wired backhaul will always be faster and more reliable[0] than a mesh.

--
[0] unless you expand your mesh beyond property limits and incorporate your neighbours and their internet connections into a common mesh, to gain failover capabilities, but that's a whole difference can of worms

1 Like