And speaking of adoption and experiences, an annoying issue with MLD+Android we came across lately. In case someone would like to participate and help on this, too. Implementing some workaround in the Linux bridge might be something worth to consider, too. ----- Forwarded message from Linus Lüssing <linus.luessing@xxxxxxxxx> ----- Date: Tue, 24 Mar 2020 21:54:02 +0100 From: Linus Lüssing <linus.luessing@xxxxxxxxx> To: mcast-wifi@xxxxxxxx, pim@xxxxxxxx Subject: [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode... Hi, With Freifunk [0] we lately came across an annoying issue with Android devices... which I'm not really sure how to solve yet... It seems that (some?) Android devices do not respond to MLD queries when in sleep mode: https://github.com/freifunk-gluon/gluon/issues/1832 https://issuetracker.google.com/issues/149630944 Which causes severe IPv6 connectivity/usability issues when trying to use MLD snooping capabilities. As soon as you turn on the screen of the Android device or connect a charger MLD Reports arrive just fine. My test results were, as noted in the Android ticket: Results with phone on battery: * 0/8 MLD Reports received * 3/8 Neighbor Advertisements received * 8/8 Echo Replies received Results with phone on charger: * 8/8 MLD Reports received * 8/8 Neighbor Advertisements received * 8/8 Echo Replies received Fixing this on the Android devices would need several years to propagate, as noted by an Android dev. Has anyone on this list experienced similar issues, too? And is there maybe even someone who came up with a workaround that they implemented on the router/switch side? If not and if we can't come up with a solution it looks pretty gloomy for (non-flooding) multicast in wifi networks to me for the next years... Regards, Linus [0]: https://freifunk.net/en/ _______________________________________________ Mcast-wifi mailing list Mcast-wifi@xxxxxxxx https://www.ietf.org/mailman/listinfo/mcast-wifi ----- End forwarded message -----
