Mesh Wireless is not associated

willowen100 · December 28, 2019, 11:30am

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

ParanoidZoid · December 28, 2019, 12:14pm

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:

github.com

kaloz/mwlwifi/blob/c2c8244d8fea5d59762cb14438ded00bf6d5965c/core.c#L883


	if (priv->chip_type == MWL8997)
		mwl_fwcmd_dump_otp_data(hw);


	mwl_fwcmd_radio_disable(hw);
	mwl_fwcmd_rf_antenna(hw, WL_ANTENNATYPE_TX, priv->antenna_tx);
	mwl_fwcmd_rf_antenna(hw, WL_ANTENNATYPE_RX, priv->antenna_rx);


	hw->wiphy->interface_modes = 0;
	hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP);
#if defined(CPTCFG_MAC80211_MESH) || defined(CONFIG_MAC80211_MESH)
	hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_MESH_POINT);
#endif
	hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_STATION);
	hw->wiphy->iface_combinations = &ap_if_comb;
	hw->wiphy->n_iface_combinations = 1;


	mwl_set_caps(priv);


	priv->led_blink_enable = 1;
	priv->led_blink_rate = LED_BLINK_RATE_MID;
	mwl_fwcmd_led_ctrl(hw, priv->led_blink_enable, priv->led_blink_rate);

github.com

kaloz/mwlwifi/blob/382700ce5744fe80271c57a89c6589e767d91620/mac80211.c#L188-L193


	case NL80211_IFTYPE_MESH_POINT:
		if (vif->type == NL80211_IFTYPE_MESH_POINT)
			if (priv->chip_type != MWL8997)
				return -EPERM;
		macids_supported = priv->ap_macids_supported;
		break;

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

github.com

kaloz/mwlwifi/blob/ecd6556aca1f085e53d08df044e5cade963c18ed/debugfs.c#L473-L477


		case NL80211_IFTYPE_MESH_POINT:
			len += scnprintf(p + len, size - len, "type: mesh\n");
			len += scnprintf(p + len, size - len,
					 "mac address: %pM\n", mwl_vif->bssid);
			break;

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.

jeff · December 28, 2019, 3:12pm

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

willowen100 · January 1, 2020, 12:35pm

Happy new year everyone

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.

willowen100 · January 4, 2020, 1:59pm

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?

alexf2015 · January 14, 2020, 6:26am

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.

willowen100 · January 14, 2020, 8:47pm

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

mk24 · January 14, 2020, 9:29pm

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.

willowen100 · January 14, 2020, 9:52pm

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.

mk24 · January 14, 2020, 9:57pm

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.

willowen100 · January 14, 2020, 10:25pm

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

alexf2015 · January 15, 2020, 5:33am

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/)

slh · January 15, 2020, 5:46am

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

Gotthard · December 17, 2020, 6:00pm

Sorry because of feeding old thread, but the problem is still active in 19.07.5

Same problem here on different devices.
Could be solved by

opkg remove wpad-mini wpad-basic ath10k-firmware-qca988x-ct kmod-ath10k-ct
opkg install ath10k-firmware-qca988x kmod-ath10k wpad

working devices on my site with this workaround: tp-link archer c7 v4, re450, ubiquiti ac mesh