Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
[Catching up on email] Benedikt, Note that https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00 is an attempt at addressing refresh without a multicast RA every 3 seconds, by only having the host do this refresh when it knows that the router doesn't default to multicasting solicited RAs. The key use case are hosts that sleep on a schedule i.e. that do not wake for any packets, but yet need to be able to quickly get connectivity when they do wake up. Whether RS refresh is useful vs. harmful for devices that wake up for packets is a source of discussion in the 6MAN WG. Regards, Erik On 6/13/15 10:25 AM, Benedikt Stockebrand wrote: Hi Lorenzo and list, Lorenzo Colitti lore...@google.com writes: On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand b...@stepladder-it.com wrote: they should at least send an RS when they wake up and ensure their configuration is still up to date. That sounds like a bad idea. If devices send an RS every time the user turns the screen on, and the router responds with a multicast RA, any medium-size network or larger will have multicast RAs flying around every 3 seconds and killing everyone's battery. not quite; as Eric pointed out, RAs may be sent unicast. While this was originally intended for underlying NBMA link layers, it does make kind of sense in this context, too. The downside with this however is that it makes monitoring for rogue routers more difficult again (using tools like ramond) at least in switched networks. But aside from that, my wording was imprecise. Make that send an RS when they wake up and they determine they have been offline long enough, for long enough being somewhat in the order of such that the router lifetime expired or similar. Figuring out the exact details is left as an excercise to the so inclined reader:-) Cheers, Benedikt
Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Hi Lorenzo and list, Lorenzo Colitti lore...@google.com writes: On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand b...@stepladder-it.com wrote: they should at least send an RS when they wake up and ensure their configuration is still up to date. That sounds like a bad idea. If devices send an RS every time the user turns the screen on, and the router responds with a multicast RA, any medium-size network or larger will have multicast RAs flying around every 3 seconds and killing everyone's battery. not quite; as Eric pointed out, RAs may be sent unicast. While this was originally intended for underlying NBMA link layers, it does make kind of sense in this context, too. The downside with this however is that it makes monitoring for rogue routers more difficult again (using tools like ramond) at least in switched networks. But aside from that, my wording was imprecise. Make that send an RS when they wake up and they determine they have been offline long enough, for long enough being somewhat in the order of such that the router lifetime expired or similar. Figuring out the exact details is left as an excercise to the so inclined reader:-) Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
On 6/12/15 1:11 AM, Lorenzo Colitti wrote: Ole said: do we agree that a host that wakes up and has expired its last default router should restart router discovery? In my mind this makes a lot of sense. That's not necessary. For things to work well a host needs to be able to maintain connectivity even when asleep. So it needs to be able to receive unicast packets, Agreed and it needs to process RAs The problem is that due to the design of the protocol processing RAs (Note, you did not specify unicast or multicast) is a known battery drainer. So it's awesome to say that wireless devices operating on a battery should simply stick to the protocol that was designed 15+ years ago when it was almost universally true that every networked device was connected to power and a LAN cable. But the world has moved on. (e.g., so it can know that it has lost connectivity when it receives an RA with a default lifetime of 0). The device should know if it loses connectivity if it actually, you know, loses connectivity. If the router hasn't expired yet it should be able to use it. The scenario you describe should be incredibly rare. Doug -- I am conducting an experiment in the efficacy of PGP/MIME signatures. This message should be signed. If it is not, or the signature does not validate, please let me know how you received this message (direct, or to a list) and the mail software you use. Thanks! signature.asc Description: OpenPGP digital signature
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
On 12 Jun 2015, at 5:31 , Lorenzo Colitti lore...@google.com wrote: On Thu, Jun 11, 2015 at 6:56 PM, Benedikt Stockebrand b...@stepladder-it.com wrote: they should at least send an RS when they wake up and ensure their configuration is still up to date. That sounds like a bad idea. If devices send an RS every time the user turns the screen on, and the router responds with a multicast RA, any medium-size network or larger will have multicast RAs flying around every 3 seconds and killing everyone's battery. then it turns into a silly race… the network is forced to send RAs at very high frequency, because hosts that wake up with expired routers, don’t RS… RFC4861: The host re-attaches to a link after being detached for some time.” I don’t see the purpose of a host re-soliciting unless the last default router is about to expire, NUD fails, strong indication that it has moved… do we agree that a host that wakes up and has expired its last default router should restart router discovery? (if I wrote the code on the host, I’d continue to use the expired router until I got a new one). cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Hi folks, I can't give you a decisive reference for where it's defined, but the default maximum interval is 600 seconds and the minimum interval is one third of that (200 seconds, not 180). The 1800s value may be a misinterpretation of the router lifetime field in the RAs, which has a default value of 1800. And yes, you can tweak these values at least on the implementations I tested about ten years ago. As far as tweaking these values to deal with some sleepy devices is concerned: I'd personally prefer to consider these devices broken; they should at least send an RS when they wake up and ensure their configuration is still up to date. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Hi Tore and list, Tore Anderson t...@fud.no writes: 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? ten years ago I've fooled around with various Unixen (FreeBSD, Debian, Solaris) with this. I don't remember off the head if this was using the router lifetime field from the RAs or NUD or both, but it did work quite reasonably. IIRC I managed to get the failover time down to around 5s, which is still a lot for VoIP, but pretty reasonable for a lot of other purposes---like TCP standard retransmit intervals, for example:-) Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Hi, On Thu, Jun 11, 2015 at 09:56:45AM +, Benedikt Stockebrand wrote: As far as tweaking these values to deal with some sleepy devices is concerned: I'd personally prefer to consider these devices broken; they should at least send an RS when they wake up and ensure their configuration is still up to date. What I thought exactly. -is
Re: SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Please read some IETF draft related to NDP/multicast/WiFi issues (Lorenzo is very active there). Multicast RA are not really needed anyway, some 'high market' (see my email address) AP have dozens of tricks to reply to RS with a UNIcast RA, and trying to reduce the amount of NDP mcast. If you want to measure by yourself: https://github.com/evyncke/mcast6 which will display basic summary of all your mcast IPv6 traffic. And bear in mind that every WiFi mcast frame wakes up ALL your WiFi device and is sent at the lowest rate (wasting bandwidth) ;-) On 10/06/15 02:20, erik.tarald...@telenor.com erik.tarald...@telenor.com 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
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
Lorenzo On 10 June 2015 at 18:23, Lorenzo Colitti lore...@google.com 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 john.m...@monash.edu 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=GeneralmessageId=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 intended because battery runs down rapidly due to increasing standby power. End-users can connect to networks continually by IPv4. Best
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
* Lorenzo Colitti lore...@google.com On Wed, Jun 10, 2015 at 9:45 PM, Tore Anderson t...@fud.no 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
SV: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
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
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
* 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
On 10 Jun 2015, at 10:33, erik.tarald...@telenor.com erik.tarald...@telenor.com 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
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
On 10 Jun 2015, at 06:33, John Mann john.m...@monash.edu 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
Re: Samsung phones block WiFi IPv6 when sleeping, delayed notifications
On 10 Jun 2015, at 10:20, erik.tarald...@telenor.com erik.tarald...@telenor.com 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
