SOLVED: Network configuration for mesh11sd with wired nodes

Hi!

I need a fresh look on my mesh11sd config of 2 nodes wired to each other. There are some random connectivity issues and multiple messages
[40491.283361] br-lan: received packet on wlan1 with own address as source address (addr:50:64:2b:5d:63:e4, vlan:0)
which indicates there is probably a mesh loop

The topology is very simple:

<wan> ---------- x.x.x.x <portal node> 192.168.50.1 ----------------- 192.168.50.3 <secondary node>

Portal Node config:

package network

...

config globals 'globals'
	option ula_prefix 'fd9b:12fc:8e8d::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth2'
	option ipv6 '0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.50.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option device 'eth1'
        <wan configuration>
package wireless


config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/a800000.wifi'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option network 'lan'
	option device 'radio1'
	option mode 'ap'
	option ssid 'WIFI-MESH'
	option encryption 'sae'
	option key 'wifi-password'
	option ieee80211r '1'
	option ft_over_ds '0'
	option ft_psk_generate_local '1'

config wifi-iface 'mesh'
	option network 'lan'
	option device 'radio1'
	option mode 'mesh'
	option ifname 'm-11s-0'
	option mesh_id 'MeshNet'
	option encryption 'sae'
	option key 'your-secret-password'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'

Secondary Node config:

package network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option packet_steering '1'
	option ula_prefix 'fd24:0892:5a07::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	option ipv6 '0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.50.3'

config interface 'wan'
	option proto 'dhcp'
	option auto '0'
	option device '@wan'

config route
	option interface 'lan'
	option target '0.0.0.0/0'
	option gateway '192.168.50.1'
package wireless

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'WIFI-MESH'
	option encryption 'sae'
	option key 'wifi-password'

config wifi-iface 'mesh'
	option device 'radio1'
	option mode 'mesh'
	option network 'lan'
	option mesh_id 'MeshNet'
	option key 'your-secret-password'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
	option encryption 'sae'

Have several questions:

  1. At the moment everything (ethernet ports (br-lan), default_radio1 and mesh interfaces) are in lan network. Since nodes are wired, maybe they should go into another network? Also should default_radio1 and mesh use same network lan?

  2. Since 2 devices i am using are from different vendors there is slight software difference:
    portal node:
    mesh11sd - 2.0.0-1
    wpad-mesh-mbedtls - 2023-09-08-e5ccbfc6-3
    secondary node:
    mesh11sd - 2.0.0-1
    wpad-mesh-wolfssl - 2022-01-16-cff80b4f-16.2

will mbedtls and wolfssl work together ?

3.) is the following config good in secondary node:

config route
	option interface 'lan'
	option target '0.0.0.0/0'
	option gateway '192.168.50.1'

need that default route only to update software on secondary node (so it has internet access through portal node at 192.168.50.1)

ps: maybe you also need my mesh11sd config:
portal node:

package mesh11sd

config mesh11sd 'setup'
	option enabled '1'
	option debuglevel '1'
	option checkinterval '10'
	option interface_timeout '10'
	option portal_detect '0'

config mesh11sd 'mesh_params'
	option mesh_fwding '1'
	option mesh_rssi_threshold '-70'
	option mesh_gate_announcements '1'
	option mesh_hwmp_rootmode '3'
	option mesh_max_peer_links '8'
	option mesh_connected_to_as '0'
	option mesh_connected_to_gate '1'

secondary node:

package mesh11sd

config mesh11sd 'setup'
	option enabled '1'
	option checkinterval '10'
	option interface_timeout '10'
	option debuglevel '2'

config mesh11sd 'mesh_params'
	option mesh_fwding '1'
	option mesh_rssi_threshold '-70'
	option mesh_gate_announcements '1'
	option mesh_hwmp_rootmode '3'
	option mesh_max_peer_links '8'
	option mesh_connected_to_as '0'
	option mesh_connected_to_gate '1'

If your two nodes are wired, you do not need, and should not use mesh. What are you trying to achieve with a mesh configuration that cannot be done with basic dumb APs?

1 Like

If you have them wired to each other, why do you need a mesh network?

Because you have both wired and mesh, you have created a bridge loop.

2 Likes

There will only be a difference if you are using different versions of OpenWrt.

Yes

This is not needed, use mesh11sd connect instead.

This is dynamically updated and shows your Internet feed is (still) down.

The question remains unanswered though - ie Why do you need a mesh network when the devices are cabled?

Not devices but mesh nodes as shown on my "text diagram".

Mesh is needed because when you were connected with laptop to secondary node, and you are travelling upstairs, the signal to that node weakens, and system switches you to master node which is closer. This wont happen if there is no mesh communication established between nodes.

Nodes are wired to provide higher transmit speed between nodes.

Why I say it's a mesh, because previously I used some out-of-the-box solutions from Linksys, and they basically recommended to connect all nodes in a chain for better results (each node had 2 ports - in and out). Therefore in my understanding mesh algorithm is something that decides when to disconnect client and make him connect to another node with better signal. Or to manage load. Maybe in OpenWRT world it's different but thats how I understand it.

See above link. Now I am totally puzzled.

A mesh network is for providing wireless backhaul. Only mesh peers can join the mesh. Normal user devices cannot join (eg mobile phones, tablets, laptops etc cannot join).

Your backhaul is ethernet. Your mesh configuration serves no purpose and creates the bridge loop.

Some vendors of wifi hardware have decided to use the word "MESH" as a marketing ploy to sell ordinary vanilla access points at a premium by carefully crafting words in their advertisements to make people think they are getting something special.

Actually it is the entire world of wireless technology, not just OpenWrt, as can be seen if you look at the IEEE standards that are internationally accepted standards.

You can start reading about this here:

Remove either the mesh configuration or the ethernet cable and the bridge loop will go away.

What you are describing is 802.11r

This is NOT mesh.

Pardon me, but there is STP. (But for one reason another it is disabled by default.)

The point here though is that the OP has been confused, like many others, by the marketing ploys of numerous vendors.
What he wants is 802.11r so he can (try to) roam seamlessly around his house.

1 Like

Yes I got that, that the user does not has a need to use 802.11s if there is already Ethernet in-between the APs.

And it bothers me too how the sales guys had muded the water :frowning:

1 Like

@bluewavenet thanks for brining all the necessary 802.11 buzzwords to the plate. Ok, Now got the official understanding of mesh. :slight_smile:

Still about 802.11r
Here https://support.apple.com/en-ae/HT202628#:~:text=To%20use%20802.11k%20and,Mac%20computers%20with%20Apple%20silicon.

it's written that 802.11r is supported only on new macbooks with silicon cpu. I recall that when using Linksys "wired" solution it was possible to travel between nodes with Intel-based mac and it was working seamlessly (my video/audio was not interrupted).

So wonder which standard to implement. I do have some intel-based macbooks in household, and also older ipads are used by kids. Are you sure 802.11r will work with these devices ?

I have never bothered to setup 802.11r and still have good enough roaming for clients when walking around the house while on a video chat. I think this also depends on the density of the APs (and at least with an stock android 11 and Linux it's good enough).

1 Like

It is not widely/correctly supported at all. You can get the same effect by carefully adjusting positions of APs and the transmit power. Proprietary solutions will often use non open source "enhancements" to the built in radio chip firmware, usually specific to a particular chipset. This is why one vendor's "Mesh" roaming will not interoperate with another vendor's offering.

You should close this thread by marking it as SOLVED and open a new thread asking about "Wireless Roaming / 802.11r or alternatives"

1 Like

Many thanks, marked in title SOLVED (could not find any link to close thread)
So will try 802.11r and some distance magic. Btw if technically it's not possible to put wire from some nodeN to nodeN+1, should I create a mesh network between them but use a different interface from 'lan'?

Just create a new mesh for groups of un-cabled APs
Use a unique meshid for each group of un-cabled APs but continue to use lan so that all APs will be bridged together without causing any bridging loops.

I've been using 802.11s since a lot of time ago, but in the latest sysupgrade to master this message started to appear to me too.
I have never seen it before. So not sure if it is a new warning added to the code, or a new bug.

You mean br-lan: received packet on wlan1 with own address as source address ?

Do you have a cabled link like the OP?

It is not a new warning, it is a warning about a bridge loop.
Have you read this entire thread?

Yes, I read the entire thread, mine is similar:

Sun Sep 24 14:57:30 2023 kern.warn kernel: [ 5721.553638] br-lan: received packet on mesh with own address as source address (addr:xxxxxx, vlan:0)

This happened after a sysupgrade, without touching anything in the config, for this reason is strange. But maybe it's a different case.

Similar in that you also have cabled links? Or perhaps you have dual mesh links on 2.4 and 5GHz?
There is nothing new in master that would suddenly make a bridge loop.

What does mesh11sd status show?

It's not a loop it just that by default all interfaces have the same mac addr. If the user just sets an individual mac addr on all devices then the warning disappears.
(A common issue i.e. when using batman-adv or having multiple vlans in place.)

Yes, possible. But a more common cause is after conversion to DSA, any virtual wireless interfaces can, in error, assume the mac address of br-lan instead of the actual mac address of the physical wireless hardware.
This could explain the appearance of the error after an upgrade to current master snapshot.

Version 3.0.0 of Mesh11sd (currently in beta) fixes this if found to be the case.