I have exactly the same problem with the same symptoms. I'm running a fresh build of OpenWRT trunk. The problem is not new. On some days it happens several times. On other days it doesn't happen at all.
I'm curious to know what your hardware(s) and driver(s) are, Smartwires. Mine is TPLink Archer [AC]7 v[245]. I'm running the QCA 988x driver on the 5GHz radio. My solution is the same as yours: reboot the gateway. It's a terrible solution, having only one advantage, which is that it (sort of) works.
I have seen Sven's remark about unicast packets. I'm not sanguine about getting Qualcomm to fix a driver for an older product. The Candela Technologies driver refuses to function on the DFS channels (100, 116, 132), which in my large, populous US residential environment work far, far better than channels 36 or 149.
All ideas welcome.
On 5/25/20 4:35 AM, smartwires@gmail.com wrote:
I have been battling a weird problem recently, I have this problem occurring on two (2) separate networks, one with 2 nodes and the other with 3 nodes. What happens is the network is fine and all of a sudden the clients can not reach the Internet, This what I have observed. on both Openwrt 19.07, 18.07. A reboot of the gateway corrects the problem.
- Gateway is up and running and able the reach the internet.
- batctl o show the neighbor/s
- batctl ping [MAC] fails
root@Main-GW:~# batctl o [B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: mesh0/e8:5b:b7:00:10:73 (bat0/22:55:4d:3e:5f:8f BATMAN_IV)] Originator last-seen (#/255) Nexthop [outgoingIF]
- e8:5b:b7:00:10:6b 0.880s (255) e8:5b:b7:00:10:6b [ mesh0]
root@Main-GW:~# batctl ping e8:5b:b7:00:10:6b PING e8:5b:b7:00:10:6b (e8:5b:b7:00:10:6b) 20(48) bytes of data Reply from host e8:5b:b7:00:10:6b timed out Reply from host e8:5b:b7:00:10:6b timed out Reply from host e8:5b:b7:00:10:6b timed out Reply from host e8:5b:b7:00:10:6b timed out