Xiaomi 4A GE br-lan issues

ilija.culap · April 16, 2024, 3:27pm

Is the WAN connection PPPoE or DHCP?

It is DHCP

Have you got enough space for mesh11sd as @bluewavenet has developed a new autoconfiguration that this sounds suited for since version 3.1

I have enough space, but i do not want to use mesh11sd. It is very complicated.

Thank you for your replay @bluewavenet . I think that was indeed my problem. Yesterday i noticed some mpath-s in my main mesh nodes. Then i look online and found:

github.com/openwrt/openwrt

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

opened 06:05PM - 20 Oct 21 UTC

openwrt-bot

flyspray

*nemesisdev:* - Device problem occurs on: reported by [[https://forum.openwrt.o…rg/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: <code>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</code> 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.

According to GitHub it is not a bug but symptom of not seted mesh parameters (If i did understood right). So i tried to remove all mpath-s manually and internet connetion from mesh nodes was immediatly recoverd. Only thing i am not sure about is which params are important? I have some in wireless config (i know they should not work, but they ware there (iw dev ... mesh_param dump)).

So like i said i do not want to use mesh11sd. I created a script that sets all mesh_params and removes those mpath-s. Script runs every minute. I also removed every mesh_param from wireless config file. So now i have to sit back and watch if everything works as intended.

If anybody has interest in my script can post it here.