Connectivity Issues with an established 802.11s Mesh Connection

Hi guys,

I need some help here, trying for 3 days now. It seems, connectivity is lost after a short time as soon as there is real traffic between the devices.

Following Hardware:

Main Router with Internet connection is a Netgear Nighthawk X4S R7800 with OpenWrt 24.10.4, second connected via mesh is a Buffalo WZR-HP-G300NH v1 with OpenWrt 24.10.3, both with a static IP, 192.168.2.1 for the Netgear and 192.168.2.3 for the Buffalo.

On the Netgear the non-CT version of the ath10k firmware is installed.

After a failed sysupgrade on the Netgear and a clean new installation and configuration, I’m having trouble with my mesh connection, which is somehow established with the two stations connected:

image

image

As you can see, the IP address of the Mesh-Point is not recognized by the Netgear, but is in the ARP table:

192.168.2.3      0x1         0x2         00:1d:73:b3:e5:7a     *        br-lan

Netgear /etc/config/network and wireless:

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 ula_prefix 'fd0f:2c5d:781d::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

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

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option username 'Provider Username'
	option password 'Provider Password'
	option ipv6 'auto'
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
	option channel '48'
	option band '5g'
	option htmode 'VHT80'
	option txpower '23'
	option cell_density '0'
	option country 'DE'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'SSID'
	option encryption 'psk2+ccmp'
	option key 'password'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
	option channel '8'
	option band '2g'
	option htmode 'HT20'
	option cell_density '0'
	option country 'DE'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option encryption 'psk2+ccmp'
	option key 'password'
	option ssid 'SSID'

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

And for the Buffalo:

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

config globals 'globals'
	option ula_prefix 'fdfd:297b:4682::/48'
	option packet_steering '1'

config interface 'lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '192.168.2.1'
	option ipaddr '192.168.2.3'
	option device 'br-lan'
	list dns '192.168.2.1'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 5t'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/ahb/180c0000.wmac'
	option htmode 'HT40'
	option country 'DE'
	option txpower '17'
	option cell_density '0'

config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'ap'
	option encryption 'psk2'
	option key 'password'
	option network 'lan'
	option ssid 'SSID'

config wifi-iface 'mesh0'
	option device 'radio0'
	option ifname 'mesh0'
	option mode 'mesh'
	option encryption 'sae'
	option mesh_id 'b2a24067f717'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
	option key 'mesh-password'
	option network 'lan'

‘iw phy0-mesh0 mpath dump’ gives:

DEST ADDR         NEXT HOP          IFACE	SN	METRIC	QLEN	EXPTIME	DTIM	DRET	FLAGS	HOP_COUNT	PATH_CHANGE
02:1d:73:b3:e5:7a 02:1d:73:b3:e5:7a phy0-mesh0	6050	64	0	0	100	0	0x14	1	1

And with ‘iw phy0-mesh0 station dump’ I see the Buffalo connected:

Station 02:1d:73:b3:e5:7a (on phy0-mesh0)
	inactive time:	120 ms
	rx bytes:	620576131
	rx packets:	7762829
	tx bytes:	458658
	tx packets:	6464
	tx retries:	44
	tx failed:	0
	rx drop misc:	159086
	signal:  	-32 [-42, -47, -42, -43] dBm
	signal avg:	-33 [-38, -46, -42, -40] dBm
	Toffset:	18446743640204104459 us
	tx bitrate:	130.0 MBit/s MCS 15
	tx duration:	146180 us
	rx bitrate:	144.4 MBit/s MCS 15 short GI
	rx duration:	246468817 us
	last ack signal:-38 dBm
	avg ack signal:	-34 dBm
	airtime weight: 256
	mesh llid:	0
	mesh plid:	0
	mesh plink:	ESTAB
	mesh airtime link metric: 64
	mesh connected to gate:	no
	mesh connected to auth server:	no
	mesh local PS mode:	ACTIVE
	mesh peer PS mode:	ACTIVE
	mesh non-peer PS mode:	ACTIVE
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		yes
	TDLS peer:	no
	DTIM period:	2
	beacon interval:100
	connected time:	426347 seconds
	associated at [boottime]:	172741.737s
	associated at:	1766148552803 ms
	current time:	1766574898192 ms

Sporadically I’m even able to ping the Buffalo from the Netgear for a few seconds, up to about 5 to 10 successful pings or even ssh into it until it isn’t responding anymore.

And now I’m out of ideas what possibly is wrong with my setup. If any additional information is necessary, I will provide it.

Please note, that this worked before I did the update.

So please, has someone here any idea?

Thanks in advance.

What did you reflash from => to ?

There is a potential issue caused by the DSA migration in that some firmwares do not ensure all vifs (virtual intefaces) have unique mac addresses.

Consequently, if the mesh vif and some other vif or bridge device or physical interface has a duplicated mac address, the built in HWMP 802.11s mac-routing will periodically break and play a game of "now_you_see_me_now _you _dont" depending on which vif mac is current in the mac-routing tables.

This could explain why it used to work but no longer does - but it could also be something else.

Look at the output of ip link. This will list all the vifs and generally they should all be different mac addresses.

Thank you for your reply.

I updated from 24.10.3 to 24.10.4.

‘ip link’ on the Netgear is:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc mq state UP qlen 1000
    link/ether dc:ef:09:ef:ed:a0 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1502 qdisc mq state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
4: lan4@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
5: lan3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
6: lan2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
7: lan1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
8: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether dc:ef:09:ef:ed:a0 brd ff:ff:ff:ff:ff:ff
9: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether dc:ef:09:ef:ed:9f brd ff:ff:ff:ff:ff:ff
14: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:a1 brd ff:ff:ff:ff:ff:ff
15: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether dc:ef:09:ef:ed:a2 brd ff:ff:ff:ff:ff:ff
19: phy0-mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether de:ef:09:ef:ed:a2 brd ff:ff:ff:ff:ff:ff
25: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN qlen 3
    link/ppp 

and on the Buffalo it’s:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 00:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 00:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff
6: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 00:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff
7: phy0-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 00:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff
8: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 02:1d:73:b3:e5:7a brd ff:ff:ff:ff:ff:ff

What does this mean?

Netgear:

Here you have:
phy0-ap0 has mac addrerss dc:ef:09:ef:ed:a2
and
phy0-mesh0 has mac address de:ef:09:ef:ed:a2

Note: THE SAME MAC ADDRESS.

But on the Buffalo:

Here you have:
phy0-ap0 has mac address 00:1d:73:b3:e5:7a
and
mesh0 has mac address 02:1d:73:b3:e5:7a

Note: DIFFERENT MAC ADDRESSES

Show the output, on the Netgear, of the following command:
uci show wireless

From that I can give you commands to fix the duplicate mac address.

Okay, I see.

On Netgear, ‘uci show wireless’ gives this:

wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio0.channel='48'
wireless.radio0.band='5g'
wireless.radio0.htmode='VHT80'
wireless.radio0.txpower='23'
wireless.radio0.cell_density='0'
wireless.radio0.country='DE'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='SSID'
wireless.default_radio0.encryption='psk2+ccmp'
wireless.default_radio0.key='password'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
wireless.radio1.channel='8'
wireless.radio1.band='2g'
wireless.radio1.htmode='HT20'
wireless.radio1.cell_density='0'
wireless.radio1.country='DE'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.encryption='psk2+ccmp'
wireless.default_radio1.key='password'
wireless.default_radio1.ssid='SSID'
wireless.mesh0=wifi-iface
wireless.mesh0.device='radio1'
wireless.mesh0.mode='mesh'
wireless.mesh0.encryption='sae'
wireless.mesh0.mesh_id='b2a24067f717'
wireless.mesh0.mesh_fwding='1'
wireless.mesh0.key='mesh-password'
wireless.mesh0.network='lan'
wireless.mesh0.mesh_rssi_threshold='0'

Run the following commands on the Netgear:

uci set wireless.mesh0.macaddr='d6:ef:09:ef:ed:a2'

This sets a new locally administered mac address for the mesh vif.

then:
uci commit wireless

This writes the new option to the config file.

Finally:
reboot;exit

This reboots and immediately exits from the SSH session (the exit prevents a long hangup for your terminal session)

It may take 300 seconds or so for the mesh path to settle down.... maybe less.
Hopefully, fingers crossed, this will fix your issue.

1 Like

just noticed: first starts with dc, second with de, so they are not the same.

changing it anyway like you suggested unfortunately didn’t solve the problem.

HaHa, my dyslexic brain mixed up the lines and made me read the same one twice....

Yes I thought that was odd.

Oh well, I did say it might be something else, sorry.

You could try turning on mesh_mac_forced_forwarding as a test:

On the Netgear, do:
echo 1 > /proc/sys/net/ipv4/conf/phy0-mesh0/proxy_arp_pvlan

and on the Buffalo do:

echo 1 > /proc/sys/net/ipv4/conf/mesh0/proxy_arp_pvlan

Then maybe start a ping and see if it still drops out like it did before.

Unfortunately, that didn't work either.

I just installed tcpdump on my Netgear and had it listen to the Mesh-Interface.

tcpdump: listening on phy0-mesh0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 0, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 21519, seq 0, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 1, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 21519, seq 1, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 2, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 21519, seq 2, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 3, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 21519, seq 3, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 4, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 21519, seq 4, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 5, length 64
14:08:50.825294 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 6, length 64
14:08:51.865276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 7, length 64
14:08:52.905386 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 21519, seq 8, length 64
14:08:54.822420 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:08:55.865741 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:08:56.906161 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:08:58.825989 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:08:59.865318 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:00.905107 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:02.828480 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:03.875322 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:04.905528 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:06.833176 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:07.865777 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:08.905200 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:10.841616 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:11.865575 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:12.906464 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:14.847665 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:15.865282 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28
14:09:16.905229 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.3 tell nighthawk.groovy.home, length 28

In this situation, there are 5 successful Pings before it got unresponsable. So it seems like it’s losing information who has 192.168.2.3, although the IP-address is still in the ARP table:

192.168.2.3      0x1         0x0         00:1d:73:b3:e5:7a     *        br-lan

but withe the FLAG set as 0x0, which means ‘incomplete’.

So I tried setting the ARP entry permanent with:

ip neigh replace 192.168.2.3    lladdr 00:1d:73:b3:e5:7a nud permanent   dev br0

I get an ARP flag of 0x6, which means ‘complete and manually set’, but it still fails after a few seconds:

tcpdump: listening on phy0-mesh0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 0, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 22817, seq 0, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 1, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 22817, seq 1, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 2, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 22817, seq 2, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 3, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 22817, seq 3, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 4, length 64
    192.168.2.3 > nighthawk.groovy.home: ICMP echo reply, id 22817, seq 4, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 5, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 6, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 7, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 8, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 9, length 64
14:42:18.460522 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has nighthawk.groovy.home tell 192.168.2.3, length 28
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 10, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 11, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 12, length 64
    nighthawk.groovy.home > 192.168.2.3: ICMP echo request, id 22817, seq 13, length 64

Anyone any idea, what could be wrong?
The connection worked before upgrading the main router.