Re: [Mcast-wifi] [pim] Issues with MLD and Android powersaving / sleep mode...

Mark Smith <markzzzsmith@gmail.com> Sun, 29 March 2020 04:36 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C462E3A10E0; Sat, 28 Mar 2020 21:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.927
X-Spam-Level: *
X-Spam-Status: No, score=1.927 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cv_2vuwDmdAS; Sat, 28 Mar 2020 21:36:14 -0700 (PDT)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 DB54F3A10DF; Sat, 28 Mar 2020 21:36:13 -0700 (PDT)
Received: by mail-ot1-x32a.google.com with SMTP id 111so14384041oth.13; Sat, 28 Mar 2020 21:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mVztKtwhEqqA3fZN8Kz5zqAD2AhLDoR+fhoUhwrBa6E=; b=lc2rlyzEE+6zfNL9xnRpClwyvNWpl9owdpZcq/jnltAL6PZ9V9fUTf8OmnMYV1BFZJ c0j9rd/IllOWpC/kd/EYyfv9c4xReAD3PumJ9OPd0u+CbSNdN4ALPNvk5w8Y6JA2vZfH bp5Zu32kVFmlnH2YSkXa86krOSCgueGSleATcERBw+L9CPtbWC6AU/AujP9EhOKMf1q2 Wpp5W9U+6d/GRVIqP8grhHXv+y7QUOrrP2n8+xqL8yVtDJwcaZ7KG4zrT2LUHA0kh4tq e9Z0+gaZF1WnkJoSWp60/Kbmkv7J+W4HWLtDsaV1g8cPyR6Zo6ojOQx1W0M4qsAsuCLF WUUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mVztKtwhEqqA3fZN8Kz5zqAD2AhLDoR+fhoUhwrBa6E=; b=jUad5DZ3tBeRYw44iuOIFsHzaQJVB4khFBboRYhX+SceoBpE5aBdL92GzWdzqooSEZ uuqEtq1984t0UOUJDztAVipfwDbIt/ECPalxTJWlp7aU/IzqhnpI5JtXRQmTGgrL2PiL LYOEKGOCXmJ0cS9iUHcfaw4PnZFGs8DvBDjm5PZi9ChJ4qWW7S+dkqx6wkBRUebX087X lYB+qXyrtZYe1Rcz5hvLvSKFDCkgLci+ILapm4OGDwxhPGrzi4woybW6nwkK0jHaALde UNue2F0/R8QwBiq4V8qyESyMlVvhKHMcoOui6xlCne1Q7CONJNeqdUXyt8R7sT5kDWcU PigQ==
X-Gm-Message-State: ANhLgQ3Umf4iD4sZcY6e+yRATm8OkGGu6znO7ifZXCE+axgxOkNKDfMk 5Kv2zCegFR4XhE9L9FCPGWbkDtL3puVMYuVZ0dA=
X-Google-Smtp-Source: ADFU+vtNx6lx4tg+6tL0n2gfjxT+mYpQAMpX63kN0Mu/tLhhUsm4Rl6t0S/8+L0XglSpq6ZW2LjySlInazRJfknUua8=
X-Received: by 2002:a9d:2004:: with SMTP id n4mr4970129ota.74.1585456573011; Sat, 28 Mar 2020 21:36:13 -0700 (PDT)
MIME-Version: 1.0
References: <20200324205402.GD2357@otheros> <CAO42Z2zKxbJU85y9GT6tyF93MwbsXKWeFWRPAYXP6KHkn+L+8g@mail.gmail.com> <20200325113540.GF2357@otheros>
In-Reply-To: <20200325113540.GF2357@otheros>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 29 Mar 2020 15:35:46 +1100
Message-ID: <CAO42Z2yRwzZj1b1syU_qammE=VU7p8PhqsLPEyLeaJ0_c2y_Ug@mail.gmail.com>
To: Linus Lüssing <linus.luessing@c0d3.blue>
Cc: mcast-wifi@ietf.org, pim@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/8eUdzoopImOf0eD8CWx_-nzyWo8>
Subject: Re: [Mcast-wifi] [pim] Issues with MLD and Android powersaving / sleep mode...
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Mar 2020 04:36:16 -0000

Hi Linus,

On Wed, 25 Mar 2020 at 22:35, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> Hi Mark,
>
> > >From the above github link, it sounds like the real fault is that when
> > Android wakes up it isn't immediately issuing MLD joins for its
> > existing IPv6 addresses. I'll have to think about which IPv6 RFC
> > advice to do that is probably in, however I think it should be - every
> > time an interface comes up with existing IPv6 addresses, it should be
> > sending MLD Reports to join the Solicited Node Multicast groups for
> > its addresses.
>
> Yeah, that'd be one way of solving it. At least that specific issue.

So that's the specific issue you're asking about isn't it?

I think it is the correct solution. The MLD snooping state follows the
presence and existence of the device.

> Back then I couldn't find an RFC mandating that though (also
> see my mail from last December, section "Roaming" [0]).
>
>
> I'm not really familiar with either Android or it's powersaving, but
> wouldn't that approach still have issues with communications
> initiatiated not from but to the the Android device? For instance
> someone sends a text message to an app like Signal. You'd want to
> receive that timely and get a notification. And not just the next
> time you turn on the screen (and by that wake up the device).

That's a different problem.

The device needs to be in charge of its own battery and how its
battery's capacity is spent. The battery is the device's resource, not
the network's.

If a sleeping device wakes up every time the network sends it an
unsolicited message to it, such as your MLD queries, then the device
becomes vulnerable to a battery resource denial of service attack. An
attacker can send a lot of unsolicited traffic, keeping the device
permanently woken until the battery runs out, defeating the purpose of
the sleeping mechanism.

If a device wants to receive messages the instant they are sent, then
it can't go to sleep, because "sleeping" means ignoring events that
occur while asleep.

What sleeping devices commonly do is they periodically wake up to
collect buffered messages, with either with the messages buffered in
the network, or probably  more compliant with the Internet
architecture, buffered in the sending host.

Regards,
Mark.
>
> So ICMPv6-NS to the Android device must work and as it uses a
> multicast destination, MLD Queries/Reports would need have updated
> any MLD snooping bridges/switches before that. Even when the
> device is sleeping, right?
>
>
> Also ICMPv6-NS with its multicast destination is received just
> fine (with MLD snooping disabled), so it seems to me more like the
> wifi drivers are not setting up their multicast wake up filters
> properly.
>
> The Android ticket references the "Android Compatibility Definition
> Document" which allows some rate limiting or even filtering [1]. It
> mentions ICMPv6-RA, but does not mention MLD. That might be the
> reason why some vendors might have missed the necessity of MLD and
> are therefore overblocking ICMPv6.
>
>
> Anyways, as fixing every Android device out there would take
> several years or is even impossible due to vendors not providing
> updates (as noted by the Android dev in the ticket), pragmatically
> speaking I currently don't see any way around implementing a
> workaround on the router/switch side for the short term.
> But I'd love to be proven wrong.
>
> Regards, Linus
>
>
> [0]: https://mailarchive.ietf.org/arch/msg/pim/DWWYpnsZsbqHtafwYZ_swhDpbcQ/
> [1]: https://source.android.com/compatibility/7.1/android-7.1-cdd#7_4_5_minimum_network_capability
>
>
> On Wed, Mar 25, 2020 at 08:40:09AM +1100, Mark Smith wrote:
> > On Wed, 25 Mar 2020 at 07:54, Linus Lüssing <linus.luessing@c0d3.blue> wrote:
> > >
> > > 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:
> > >
> >
> > If the device is asleep, effectively offline, why should it respond to
> > MLD queries?
> >
> > When I'm asleep I have to wake up or be woken up before I respond to
> > queries too.
> >
> > Times by a billion devices, responding to MLD queries while the device
> > is asleep and not in use is going to be wasting a lot of electricity.
> >
> > > 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.
> >
> >
> >
> >
> > Regards,
> > Mark.
> >
> >
> >
> > > 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@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mcast-wifi
> >
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www.ietf.org/mailman/listinfo/pim