Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tore Anderson]

* Lorenzo Colitti 

> On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson  wrote:
> 
> > > are *all* IPv6 packets blocked, or just multicast packets? I know
> > > that a number of devices will drop multicast IPv6 packets. This
> > > eventually blackholes connections because the device stops receiving
> > > RAs and thus loses its default route, but that can be worked around
> > > by setting long timers in the RA. I wasn't aware of devices dropping
> > > all inbound IPv6 packets, that really seems like a bad bug.
> >
> > AIUI, the maximum RA Lifetime is 9000 seconds. RFC 4861, section 6.2.1.
> 
> Except that 65535 works fine. :-)

Right.

There was another thing I thought of, though. We have a wireless
network with two redundant upstream routers that are not running a FHRP
like VRRP. Active/passive, since they do stateful inspection of
traffic. My solution to facilitate reasonably speedy failover from the
active to the passive router was to have a quite low RA lifetime, so
that the clients would quickly stop using a router that went offline.

Maybe I could instead leave the RA lifetime high, but set the reachable
time low, and depend on the client doing NUD. Would that work? In this
situation the clients would after a failover have two default routes,
where one has a next-hop that fails NUD. Do you know if clients in
general Do The Right Thing here and ignore the route that fails NUD?

In any case I get a problem when the primary router comes back online,
because then the clients end up with two default routes that both pass
NUD fine. I guess having the backup router send an few RAs with
lifetime=0 when it enters passive mode ought to handle that...

Also, lowering the reachable time isn't ideal on network with on-link
prefixes either as it'll impact client-client traffic too, not only
client-router. But that's probably not an issue on most WiFi
deployments I guess.

Tore

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[John Mann]

Lorenzo

On 10 June 2015 at 18:23, Lorenzo Colitti  wrote:

> John,
>
> are *all* IPv6 packets blocked, or just multicast packets? I know that a
> number of devices will drop multicast IPv6 packets. This eventually
> blackholes connections because the device stops receiving RAs and thus
> loses its default route, but that can be worked around by setting long
> timers in the RA. I wasn't aware of devices dropping all inbound IPv6
> packets, that really seems like a bad bug.
>

Probably *all* IPv6 packets. The phone drops IPv6 ICMP pings, and IPv6
TCP/IP packets (at least)

How I tested:
- Install "Network Info II", "JuicsSSH" and "Netstat Plus" apps.
- Connect the phone and a test PC/server to a dual-stack IPv4/IPv6 network
- use "Network Info II" to find out the phone's global unique IPv6 "wlan0"
WiFi addresses (they begin 2xxx: )
  and wlan0 IPv4 address (nnn.nnn.nnn.nnn)

Test 1: ping
- From a PC command prompt do a continuous ping to a phone IPv6 address,
  and from another command prompt do a continuous ping to the phone's IPv4
address
- Turn phone screen off, IPv6 pings stop, turn phone screen on, IPv6 pings
re-start, ...

Test 2: TCP/IP
- Run JuicsSSH on phone
- ssh to IPv6 host(name)
- on the IPv6 host start a tcpdump or wireshark looking for the phone's
privacy address (doesn't have ..ff:fe..in it)
- run a command like "vmstat 5 60" to generate a low rate of TCP/IP traffic
over IPv6.
- turn phone screen off
- packet capture shows host re-sends the next line of output multiple times
...
- turn phone screen on
- packet capture shows output catching up

I tried using Netstat Plus to try and work out what connections the phone
had open,
and what they were used for, but it wasn't obvious.
- Google Play services connecting to a IPv4 server on port 5228, and IPv6
server on port 443
- Samsung Push Service connecting to a IPv4 server on port 5223


FWIW, if you need an existence proof that it's possible to make this work,
> recent Nexus device should not have either problem. Feel free to ask
> Samsung to get in touch with me if they want to know how it works on Nexus.
>
> A network that is configured to send RAs every 15 seconds will have a
> devastating effect on battery life, and such networks are part of the
> reason that manufacturers drop all multicast packets during sleep. Please
> don't do that. Nexus devices rate-limit RAs in firmware in order to survive
> on such aggressive networks, but that's not perfect.
>
> Cheers,
> Lorenzo
>

Thanks,
John

On Wed, Jun 10, 2015 at 2:33 PM, John Mann  wrote:
>
>> Hi,
>>
>> We have noticed that Samsung Android phones and tablets on dual-stack
>> IPv4/IPv6 WiFi experience delayed Google notifications when the screen is
>> off.
>> This issue is blocking the enabling of IPv6 across our large campus WiFi
>> network.
>>
>> Has anyone else experienced this behaviour and escalated this to Samsung,
>> or found a fix?
>>
>> Our Samsung liaison person today said
>> ===
>>
>> ---
>>
>> IPv6 packets are getting filtered due to the current consumption issue
>> while device is in sleep mode.
>>
>>
>>
>> *IPv6 Concept of Samsung models:*
>>
>>
>>
>> When device enters the sleep mode, current implementation is that all the
>> IPv6 packets from AP are getting blocked. All IPv4 and IPv6 packets are
>> received while the LCD is on, however LCD off will be in blocked mode.
>>
>> This is because some of the current AP in markets introduces unnecessary
>> IPv6 Multicast packets, which in turn wake up the devices which are in
>> sleep mode, causing the issue of increase in the current consumption.
>>
>> Therefore a feature is applied on WiFi driver to filter off all IPv6 packets
>> while in sleep mode.
>>
>> ---
>>
>>
>>
>> I have requested , How to activate that filter on for all IPv6 packets
>> even when device at sleep mode. So far, it seems like it’s a permanent
>> implementation and filter is not customizable for configuration.
>> ===
>>
>>
>> This problem has been raised before.  See
>> http://commandline.ninja/2014/01/02/samsung-galaxy-s4-ipv6-borked/
>>
>>
>> http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=239890
>> ---
>> Hi, this is a serious bug in the WIFI driver of several Samsung Android
>> phones, which prevents IPv6 enabled WLAN networks to work correctly. The
>> phone is almost unuseable (while in standby mode) if it is part of a IPv6
>> enabled wireless, because the lower level link protocol misses to update
>> routing information and neighbourhood discovery.
>> ...
>>
>> *This is really a serious IPv6 problem on the broadcom-wifi samsung
>> phones that should be solved by a coming firmware update for the wifi radio
>> firmware or kernel driver. In the current state, Samsung phones with that
>> problem cannot be used in IPv6 enabled wifi networks - and you have no
>> chance to disable IPv6 on the phone!!!*
>> ---
>> developers.samsung , Jul 31, 2013 08:46
>> Hello,
>>
>> Blocking packets of IPv6 when screen is off is intend

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tim Chown]

> On 10 Jun 2015, at 13:42, Jeremy Visser  wrote:
> 
> On 10/06/15 18:23, Lorenzo Colitti wrote:
>> are *all* IPv6 packets blocked, or just multicast packets? I know
>> that a number of devices will drop multicast IPv6 packets.
> 
> On that note, some wireless access points have the ability to convert 
> multicast packets into unicast packets.  Both the Cisco and HP systems I have 
> access to support this.
> 
> Believe it or not, it’s actually billed as an optimisation, as unicast 
> packets generally use a faster modulation than multicast.  Makes sense, 
> because if you send only one copy of a packet wirelessly, all devices (even 
> the ones with the crappiest signals) need to be able to receive it reasonably 
> reliably.
> 
> If that option is available to you, and if this is specific to multicast, 
> this may be an interesting hack.

That reminds me, we had an interesting ‘feature’ here where we were seeing 
triple copies of RAs and also Bonjour messages. The discussion about that led 
to this info:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_0100110.html
 


which I assume is aimed at those doing multicast video streaming of IP TV or 
similar (as we do here). That may have some impact on multicast for IPv6.

Tim

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tore Anderson]

* Lorenzo Colitti

> are *all* IPv6 packets blocked, or just multicast packets? I know
> that a number of devices will drop multicast IPv6 packets. This
> eventually blackholes connections because the device stops receiving
> RAs and thus loses its default route, but that can be worked around
> by setting long timers in the RA. I wasn't aware of devices dropping
> all inbound IPv6 packets, that really seems like a bad bug.

AIUI, the maximum RA Lifetime is 9000 seconds. RFC 4861, section 6.2.1.

So unless you're a polyphasic sleeper, the handset will loose
connectivity overnight no matter what...

> A network that is configured to send RAs every 15 seconds will have a
> devastating effect on battery life, and such networks are part of the
> reason that manufacturers drop all multicast packets during sleep.
> Please don't do that. Nexus devices rate-limit RAs in firmware in
> order to survive on such aggressive networks, but that's not perfect.

Frequent unsolicited RAs was how I worked around the above problem.
While my phone would loose connectivity while on my nightstand, at
least with frequent RAs the IPv6 connectivity would recover quickly
once I started using my phone again in the morning. With infrequent
RAs, it would stay broken for a very long time.

But this was a few years ago, so maybe the situation has improved since
then? I imagine the handset could get away with not listening to RAs
while in sleep mode if it did send an RS some time before any of the
information learned from RAs was about to expire, for example.

Tore

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Jeremy Visser]

On 10/06/15 18:23, Lorenzo Colitti wrote:
> are *all* IPv6 packets blocked, or just multicast packets? I know
> that a number of devices will drop multicast IPv6 packets.

On that note, some wireless access points have the ability to convert multicast 
packets into unicast packets.  Both the Cisco and HP systems I have access to 
support this.

Believe it or not, it’s actually billed as an optimisation, as unicast packets 
generally use a faster modulation than multicast.  Makes sense, because if you 
send only one copy of a packet wirelessly, all devices (even the ones with the 
crappiest signals) need to be able to receive it reasonably reliably.

If that option is available to you, and if this is specific to multicast, this 
may be an interesting hack.

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Ross Chandler]

> On 10 Jun 2015, at 10:20,  
>  wrote:
> 
>> I see that. I don’t think the problem is confined to Samsung or that it can 
>> be completed solved in isolation from fixing wireless AP router behaviour.
>> At the edge of the WiFi network I also see the IPv6 connectivity dropping 
>> while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 
>> 15 seconds
>> and a Huawei home router that sends them every 1800 seconds.
> 
> Any opinions on what a sane default value for what the RA interval should be? 
>  I have not conserned myself with that interval before, but I see that the 
> residential devices we ship are on a very low interval.
> 
> 
> --
> Erik Taraldsen

I think tweaking the periodic RA interval time is an inadequate hack made in an 
attempt to keep IPv6 connectivity up. 
It seems to me the correct approach is to have an RFC or otherwise clear 
guidelines for developers documenting how to optimise this for connectivity 
parity with IPv4 and device battery life on both the wireless AP router and 
wireless client.

Ross

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tim Chown]

On 10 Jun 2015, at 10:33,  
 wrote:
> 
> 
>> I believe our Cisco equipment defaults to 10 minutes (600 seconds). There 
>> will also be RAs in response
>> to RS messages.
> 
> From the googeling I've done it seems that the defaults span from 180 to 600 
> seconds.  Have not 
> yet found any reccomandation.  Either as a sane dafult value or a calculation 
> from the life time.

And there’s the RAs in response to RS messages, which is why some stats from a 
live network might be interesting to see. Though we did run for a while with 
unicast RAs to work around some bug we had with our WLC.

Tim

SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[erik.taraldsen]

> I believe our Cisco equipment defaults to 10 minutes (600 seconds). There 
> will also be RAs in response
> to RS messages.

>From the googeling I've done it seems that the defaults span from 180 to 600 
>seconds.  Have not 
yet found any reccomandation.  Either as a sane dafult value or a calculation 
from the life time.


--
Erik Taraldsen

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Tim Chown]

> On 10 Jun 2015, at 10:20,  
>  wrote:
> 
>> I see that. I don’t think the problem is confined to Samsung or that it can 
>> be completed solved in isolation from fixing wireless AP router behaviour.
>> At the edge of the WiFi network I also see the IPv6 connectivity dropping 
>> while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 
>> 15 seconds
>> and a Huawei home router that sends them every 1800 seconds.
> 
> Any opinions on what a sane default value for what the RA interval should be? 
>  I have not conserned myself with that interval before, but I see that the 
> residential devices we ship are on a very low interval.

I believe our Cisco equipment defaults to 10 minutes (600 seconds). There will 
also be RAs in response to RS messages.

I’ll try to grab some stats on observed RAs from our campus eduroam network, 
where we have IPv6 deployed to a few thousand users with BYODs every day. I 
would guess such stats have been reported elsewhere already, but a few more 
observations might be useful/interesting.

Tim

SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[erik.taraldsen]

 > I see that. I don’t think the problem is confined to Samsung or that it can 
 > be completed solved in isolation from fixing wireless AP router behaviour.
> At the edge of the WiFi network I also see the IPv6 connectivity dropping 
> while IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 
> 15 seconds
> and a Huawei home router that sends them every 1800 seconds.

Any opinions on what a sane default value for what the RA interval should be?  
I have not conserned myself with that interval before, but I see that the 
residential devices we ship are on a very low interval.


--
Erik Taraldsen

Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications

[Ross Chandler]

> On 10 Jun 2015, at 06:33, John Mann  wrote:
> 
> Hi,
> 
> We have noticed that Samsung Android phones and tablets on dual-stack 
> IPv4/IPv6 WiFi experience delayed Google notifications when the screen is off.
> This issue is blocking the enabling of IPv6 across our large campus WiFi 
> network.
> 
> Has anyone else experienced this behaviour and escalated this to Samsung, or 
> found a fix?


I see that. I don’t think the problem is confined to Samsung or that it can be 
completed solved in isolation from fixing wireless AP router behaviour. 
At the edge of the WiFi network I also see the IPv6 connectivity dropping while 
IPv4 stays up. I’ve a ZyXEL home router that sends periodic RAs every 15 
seconds 
and a Huawei home router that sends them every 1800 seconds. 

It isn’t production ready yet.

Ross