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

Dino Farinacci <> Wed, 25 March 2020 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85BFD3A0404; Wed, 25 Mar 2020 13:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dbS8ghTAV_qH; Wed, 25 Mar 2020 13:40:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E140E3A0437; Wed, 25 Mar 2020 13:40:35 -0700 (PDT)
Received: by with SMTP id g2so1274807plo.3; Wed, 25 Mar 2020 13:40:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ypRHPQyl5J9pzRujmmS5/clioDTSbPPzvz4kTF0qkLs=; b=vM/qZWHx4ngxmUxVRae+IhRSEipGWRBWoEM8XZWMjWQTrEm1Dq8LMeAH3iBl6T5fD+ uT2LUvunXilFPK8Uuy/ArkyPaz2/92U4bfWNSWo66Q9u4kcCP/u9TYVkxut7dg7VYayB pL8awfbmlij86K8q6FP8gxoMvtJ+axxghKJUR3eCn1i1L3TN813lhPXu1hkG8Wt/H02G fSo1cepanY8MQnAonc9EyMnfri0TKUM7koLh8liOFzmvlXmdB+EVqlntd9flffg35x44 JERuHf6dCa2hgoCEKxheBxY8eN1Sfw2sCYvVhEd7cIApwPKNqF+XeI28OtW62LSDthBJ 25Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ypRHPQyl5J9pzRujmmS5/clioDTSbPPzvz4kTF0qkLs=; b=Wy1qUMybQeYTpvdHyO5uQl/CvCv8IQZDRVMv+6ixN66FDjYGpj3Wg2bteCVTee6qWi +jFJPlvo6n/AZ30V3XnZmLAbFrrpS4XqVQUhgf/VrK6WTLKrZjEYARVxGrQIEWksZj5W 6M/iQrZNgTIxoBdMEn2WV8FYSzntYhbIf1bljZOLAwx4vOOCMRHMu6OcnjOLKAUCm7AS yz4aIPx/hX2UV7JfQk2h6JfK9Tdtana7MK0n7uCqXKKpOLD+4PQRncAt7oVNff29VCaY nijkYh/z4se1FXPAMQGrIVKgW0uV7xqBZZQ3BNHYsv9mGsKgNuyVTaOvj2//NDwMSu8v +xiw==
X-Gm-Message-State: ANhLgQ2TBal0+k0MzuVDHoseBRfU/q03lg9W8IlZ3rPKXCKsvVV0tksC FeehkCuCnrgbqiN7BUiysaQ=
X-Google-Smtp-Source: ADFU+vvK3IjMJGwKzMluSmW852J4lwVDgfz5ug+CJPJ0mx8kXH3ccvhxEF4fCttkoaHfWu2xlteWRA==
X-Received: by 2002:a17:902:a601:: with SMTP id u1mr4921923plq.300.1585168835001; Wed, 25 Mar 2020 13:40:35 -0700 (PDT)
Received: from ?IPv6:2601:646:9600:af10:3508:b9aa:3885:8eff? ([2601:646:9600:af10:3508:b9aa:3885:8eff]) by with ESMTPSA id d188sm32059pfa.7.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2020 13:40:34 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Dino Farinacci <>
In-Reply-To: <20200325113540.GF2357@otheros>
Date: Wed, 25 Mar 2020 13:40:33 -0700
Cc: Mark Smith <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20200324205402.GD2357@otheros> <> <20200325113540.GF2357@otheros>
To: Linus Lüssing <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [pim] [Mcast-wifi] Issues with MLD and Android powersaving / sleep mode...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Mar 2020 20:40:40 -0000

Another way to solve the problem on the head-end side could use this algorithm:

(1) Queries (using this term “query" to apply to both IGMP and MLD) are sent periodically to the well-known group. That means queries get to phones that are not sleeping. This is what is done today.

(2) If the querier sees reports (using this term “report" to apply to both IGMP and MLD) it obviously knows the phone is up and what groups it is interested in. That sets a keep-alive timer for the phone.

(3) When keep-alive timer expires, the querier doesn’t know if the phone is down, asleep, or not joined to any groups. But (this is a new addition) it sends a unicast query to the phone.

(4) If a report is received from the phone, you know the phone is not down and is interested in at least one group. Do normal report processing.

(5) Note the query wakes up the phone when asleep.

This is a simple solution which can be made more robust with complexity, but does get the job done.



> On Mar 25, 2020, at 4:35 AM, Linus Lüssing <> 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.
> 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).
> 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]:
> [1]:
> On Wed, Mar 25, 2020 at 08:40:09AM +1100, Mark Smith wrote:
>> On Wed, 25 Mar 2020 at 07:54, Linus Lüssing <> 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.
>>> 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]:
>>> _______________________________________________
>>> Mcast-wifi mailing list
>> _______________________________________________
>> pim mailing list
> _______________________________________________
> Mcast-wifi mailing list