On Wednesday, 24 June 2020 23:13:50 CEST Mark Birss wrote:
What other debug information are available to troubleshoot
The first question you have to answer: Is the lower layer working or did the
lower layer break? Can be tested easily with multicast/broadcast and unicast
pings on the lower device. Don't assume that the driver/firmware didn't break
the connection because you see entries in the originator table. And also don't
assume that the link is working just because you've only tested unicast
packets on the lower device. WiFi drivers/firmware started to only partially
(and "accidentally") kill links for only unicast OR for broadcast.
I have enabled for OpenWRT
echo "CONFIG_BATMAN_ADV_DEBUG=y" >> .config
echo "CONFIG_BATMAN_ADV_DEBUGFS=y" >> .config
echo "CONFIG_BATMAN_ADV_BLA=y" >> .config
echo "CONFIG_BATMAN_ADV_DAT=y" >> .config
echo "CONFIG_BATMAN_ADV_MCAST=y" >> .config
echo "CONFIG_BATMAN_ADV_NC=n" >> .config
echo "CONFIG_BATMAN_ADV_BATMAN_V=y" >> .config
echo "CONFIG_BATMAN_ADV_SYSFS=y" >> .config
echo "CONFIG_BATMAN_ADV_TRACING=y" >> .config
echo 255 > /sys/class/net/bat0/mesh/log_level
Seems about right from the batman-adv perspective. Of course, also check the
originator/neighbor and local/global translation tables. Use this information
to check whether the packets are routed correctly through the lower
interfaces. Just use tools like (batctl) tcpdump to capture this traffic. You
can also use a recent wireshark to dissect pcaps from the lower interfaces.
You could also start to trace packets using trace-cmd and similar tools to
figure out where your packets end up inside the kernel.
since i want to understand also why on wifi mesh seems to crash for
I've heard multiple persons complain in recent months about stability problems
of ath10k. So maybe it is the same problem here. But unfortunately, I don't
have more information than various threads  on this mailing list.