[pim] Issues with MLD and Android powersaving / sleep mode...

Linus Lüssing <linus.luessing@c0d3.blue> Tue, 24 March 2020 20:54 UTC

Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47B3A0E2A; Tue, 24 Mar 2020 13:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef4BTakqXg40; Tue, 24 Mar 2020 13:54:06 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:171:314c::100:a1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB863A0D96; Tue, 24 Mar 2020 13:54:06 -0700 (PDT)
Date: Tue, 24 Mar 2020 21:54:02 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1585083243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gwZeJ5dO9FkmCMuF2zBKlDHZAXGm2gTPeVwhcR4qUrY=; b=WJgPLteqYl8m3jbqFWz7Vnv0UCQnvcdE3Rav/NnmMOH43qipQEZG6Fg7fEudsBSIHAhkCE DEI9qiVKNWU4gjfxxgbhVmnyAC6JfMsDCm4nRZyemWggflxhlOJhvnydbd5DxX2kzv8Nlq +BUHZ4oDy3ScYVqSk9aKTQdrd6rpJV1P18WIezKjcRFGU8H1ShqbLGYB43OJk6ZeA8dAwn jBUYc1/NpVNDbGpA1ecXfwIrLE2tUIJfZpa0zd1RFZ5JWJ4XpT+RBlEV05tLL7HrwUTsxB jUnVtWo9Ew8+B0HD16LuI5uDQKqiyoXgVZodx+8N8IUEDdobyqEHlrRfgWwWvQ==
From: Linus =?utf-8?Q?L=C3=BCssing?= <linus.luessing@c0d3.blue>
To: mcast-wifi@ietf.org, pim@ietf.org
Message-ID: <20200324205402.GD2357@otheros>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/2BJeM1SI5_AA6LPJWt64aafbtzc>
Subject: [pim] Issues with MLD and Android powersaving / sleep mode...
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 20:54:08 -0000

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/