- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Base system
- Assigned To No-one
- Operating System All
- Severity High
- Priority Very Low
- Reported Version openwrt-19.07
- Due in Version Undecided
-
Due Date
Undecided
- Private
Opened by guifipedro - 22.02.2020
Last edited by Chuanhong Guo - 06.05.2020
FS#2848 - multicast ff02::2 not responding since 19.07
cannot do multicast in nanostation m5 xw (and maybe applies for other devices with eth0.1 and eth0.2 simulating eth0 and eth1)
multicast is a core feature for running some routing protocols as bmx6 per cable)
iface="my ethernet" ping6 ff02::2%$iface
did tests with several platforms
- 18.06.4 ar71xx custom firmware → works
- 18.06.7 ar71xx openwrt.org → works
- 19.07.1 ar71xx custom firmware → does not work
- 19.07.1 ar71xx openwrt.org → does not work
- 19.07.1 ath79 openwrt.org → does not work
- snapshot ar71xx openwrt.org → does not work
- 0a21d2eb80787083852d92f1519f268df4873c07873ea6e4c1ba17af791fd801 3904.0 KB Mon Jun 17 14:08:48 2019
- snapshot ath79 openwrt.org → does not work
- e6831b128017c83082110191a4cbdf37994beb7e2dae651b5b36b854b4674805 4096.3 KB Thu Feb 20 09:43:23 2020
- OpenWrt SNAPSHOT, r12252-060b58fd6e
when I was figuring out what was happening, I did bmx6 routing (multicast) through br-lan in 3 devices, and I looked results with `tcpdump -i br-lan`. From the other devices I see that the multicast traffic from the affected device arrives (multicast packets go out), but when I see `tcpdump -i br-lan` in the affected device I only see his own multicast traffic (it’s not entering anything else)
hence, looks like 19.07.1 introduced something that it does not allow this
I was pending to try ping ff02::2%eth0 in different devices:
in nexx wt3020 8MB with OpenWrt 19.07.2 r10947-65030d81f3 → works
in TP-Link TL-WDR4300 v1 with OpenWrt 19.07.1 r10911-c155900f66 → works
(this two devices have eth0.1 and eth0.2 switches)
Hence, the problem is only focused in nanostation-m-xw
Tried new versions:
- nanostation-m-xw:
help
Hi,
So I made some tests and narrowed down the range of commits where the one introducing the bug is:
Last known working commit:
First known not working commit:
Hi,
I could find the precise commit where IPv6 multicast stops working.
First, there is commit d3506d1bc160e4ce2833dff357f2a4b219772c77 - ar71xx: ag71xx: fix compile error when enabling debug that broke the whole network for the device. It did not actually affect multicast, though.
Then came a series of commits related to AR8216. In particular, with commit r9699 d6366ce3665f010a7ae7061a557689643073040a - generic: ar8216: mib_work_func: read all port mibs everytime IPv6 multicast would still work, but the network is broken. Therefore:
Next commit is r9700 c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 - generic: ar8216: do a software reset for switch during hw_init and this one makes IPv6 multicast stop working. Plus, network is still broken from the debug-related commit. So:
Finally, there's 31ea08a64bd977e0dc0a65804e4103cb52d81cea - ar71xx: ag71xx: Fix broken networking on some devices (FS#2177) restoring the broken network from d3506d1bc1, but IPv6 multicast will not work anymore.
Summary
So, it seems that c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 - generic: ar8216: do a software reset for switch during hw_init introduced this IPv6 multicast bug, and it happened after d3506d1bc160e4ce2833dff357f2a4b219772c77 - ar71xx: ag71xx: fix compile error when enabling debug broke the device's network, but unrelated.
More tests:
- ar71xx: current master + revert c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8: IPv6 multicast works
- ath79: current master + revert c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8: IPv6 multicast works