[FS#4099] Mesh 802.11s blackhole due to bogus mpath routes with nexthop 00:00:00:00:00:00

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Federico Capoano (nemesisdev) 

Attached to Project - OpenWrt/LEDE Project
Summary - Mesh 802.11s blackhole due to bogus mpath routes with nexthop 00:00:00:00:00:00
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - - Device problem occurs on: reported by [[https://forum.openwrt.org/t/mesh-802-11s-routing-table-gets-filled-with-garbage-causing-a-black-hole-openwrt-21-02-rc4-mt7603e-mt7615e/104808|a few users on different devices]], I am using a mediatek based one

- I am experiencing this on current master, [[https://github.com/openwrt/openwrt/commit/ade56b8d9e|ade56b8d9e]]

- Steps to reproduce: I am  not sure what exactly triggers this, the bug happens on its own periodically, if anyone has suggestions on specific actions to do to try to replicate it, please let me know

**What happens**:

Connection to the root mesh node is lost, but inspecting the status of the mesh links with "iw mesh0 station dump" or "iw mesh1 station dump" shows the links are active.

Inspecting "iw mesh0 mpath dump" or "iw mesh1 mpath dump" show a list of mac addresses which are from devices in the LAN, with an invalid next hop (00:00:00:00:00:00), which for some reason end up in the mesh routing table and fill it.

For example, when the problem starts showing up, the mesh routing table may look as follows:

iw mesh1 mpath dump
DEST ADDR         NEXT HOP          IFACE	SN	METRIC	QLEN	EXPTIME		DTIM	DRET	FLAGS	HOP_COUNT	PATH_CHANGE
16:dd:0c:a4:ba:aa 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
fc:93:c3:3b:0b:fe 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
90:f4:c0:8f:de:80 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
bc:a1:da:cb:87:a8 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
1e:f7:95:47:4a:b3 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
3a:e2:e6:88:65:fb 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
6c:cd:48:37:af:bc 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
d8:54:0b:7c:20:46 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
ce:43:28:84:44:7e 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
26:75:58:0b:39:18 00:00:00:00:00:00 mesh1	0	0	0	0	1600	4	0x0	0	0
80:3f:5d:**:**:** 80:3f:5d:**:**:** mesh1	0	4857	0	0	0	0	0x10	1	1

After one minute, the size may have doubled or tripled. 

At some point one of the mesh nodes ends up in the routing table with a bogus route (with nexthop 00:00:00:00:00:00), which basically screws up routing 100%, until that happens, the other rough mesh routes do not cause issues, but once the black hole appears, removing the bogus mesh routes does not fix it, only turning off wifi and then on again fixes it.

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=4099

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.