803932 - Unagi does not switch from cellular network to wifi when known wifi network is available

Status: RESOLVED WORKSFORME

(Core :: DOM: Device Interfaces, defect, P2)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Go outside the range of any saved wifi networks
 (2) Enable cellular data connection (in case, EDGE.  grumble grumble)
 (3) Go back into the range of a saved wifi network

My unagi doesn't reconnect to my wifi network.  It should.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I suspect this is a blocking requirement given target market.  bb? to clee.

Comment 2

[Andreas Gal :gal]

This needs to be rock solid. Blocking.

Comment 3

[Andrew Overholt [:overholt]]

Vincent, how are things going here?  I haven't noticed this myself and neither has Lawrence Mandel.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I can still reproduce this, even though my unagi is now auto-reconnecting to wifi after suspend.

Comment 5

[Vincent Chang[:vchang][changyihsin]]

I tried it several times, but can't reproduce it today. Maybe I should go outside and back the range of saved wifi network to double check. 

STR today 
   1. connect to 3G -> check default route is rmnet0  
   2. connect to wifi -> check default route is wlan0 
   3. turn off AP -> check default route is rmnet0 
   4. turn on AP -> check default route is wlan0 

repeat step 3 and 4.

Comment 6

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm going to renom. It sounds like the issue here is that the device doesn't switch to wifi while a network connection is in use. Or it may be while the phone in on (not suspended). (Chris, I would appreciate your STR.) The device does switch to wifi after suspend as noted in comment 4 - i.e. we have a simple work around. Should this still block?

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Has anyone tried the STR in comment 0?

I nom'd for bb+ because of considerations in target market.  Paging clee to make the call on acceptability of workaround.

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

I was able to reproduce this issue. While the phone is on it will not transition from data connection to wifi regardless of whether the network is in use. As soon as the phone is suspended, either automatically or by clicking the power button, and then resumed, wifi successfully connects.

Comment 9

[Peter Dolanjski [:pdol]]

While there may be a work around, it is important for cost control that known WiFi is used as soon as it is available.  Users will make the assumption that they are on WiFi when in range and many will set a longer timeout, so the automatic suspension may not happen often enough to handle this for the user.

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm not sure that I agree with blocking on this. What percentage of users do we expect will actively be using their phones (where the phone is not suspended) when walking in and out of wifi range? In addition, I have been reminded repeatedly that wifi access is very limited in the target launch locale. We need to be very deliberate about what we decide is basecamp+ at this point in the schedule. To me this doesn't pass the test.

I don't want to have a flag war so I'll leave this as basecamp+ for now.

Comment 11

[Peter Dolanjski [:pdol]]

I think the big problem with this one is that the workaround is not obvious.  Josh, what are your thoughts on this from a UX perspective?

I think the WiFi conditions in Brazil are changing rapidly.  Broadband consumers (29% of Brazilian households) cite seamless mobile-to-wifi handoff as extremely important: http://www.cisco.com/web/about/ac79/docs/sp/Wi-Fi_Customer-Research_Brazil.pdf (Cisco study, so take with somewhat of a grain of salt)

The only question is that specific use case of moving from mobile to WiFi while using the device.  Unfortunately the prevalence of it will be very hard to determine.

Comment 12

[Josh Carpenter [:jcarpenter]]

(In reply to Lawrence Mandel [:lmandel] from comment #10)
> I'm not sure that I agree with blocking on this. What percentage of users do
> we expect will actively be using their phones (where the phone is not
> suspended) when walking in and out of wifi range? In addition, I have been
> reminded repeatedly that wifi access is very limited in the target launch
> locale. We need to be very deliberate about what we decide is basecamp+ at
> this point in the schedule. To me this doesn't pass the test.

I think we need to fix this. The User Research team has reported that target market users "dowse" for WiFi (my bad metaphor), by walking the streets or malls looking for connections. We should help them with that by automatically switching to known networks right away, without requiring a restart.

If we make this switch, what happens to an active download (eg: 60% through a system update)? Does it fail, or can we bridge the connection type change seamlessly?

Comment 13

[Josh Carpenter [:jcarpenter]]

> . . . without requiring a restart.

Typo. Not a restart; a suspension (whether manual or automatic).

Comment 14

[Vincent Chang[:vchang][changyihsin]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> I can still reproduce this, even though my unagi is now auto-reconnecting to
> wifi after suspend.

Is it easy to reproduce this bug in your environment ? If it's easy to reproduce, can you help to provide the logcat which set "DEBUG = true" in NetworkManager.js and  also turn on debug log for wifi in settings/Device information/More information/Developer/Wi-Fi output in adb before turn on wifi ?

Comment 15

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 16

[Vincent Chang[:vchang][changyihsin]]

Is this still a problem ? If yes, may I have the logcat log ?

Comment 17

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Works now! :D

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This is not fixed for the build 2012-12-17 on my Unagi device. When I leave the range of my network and come back, the device tries to re-connect to my network but fails constantly. After I think 2 or 3 tries Wifi gets disabled permanently and I can't even enable it again until I reboot my device.

Comment 19

[Vincent Chang[:vchang][changyihsin]]

(In reply to Henrik Skupin (:whimboo) [away 12/21 - 01/01] from comment #18)
> This is not fixed for the build 2012-12-17 on my Unagi device. When I leave
> the range of my network and come back, the device tries to re-connect to my
> network but fails constantly. After I think 2 or 3 tries Wifi gets disabled
> permanently and I can't even enable it again until I reboot my device.

You may hit the Bug 809663. The wifi driver may get stuck and never comes back unless you reboot the device, disable wifi doesn't help because the wifi driver doesn't have a chance to reload.

Comment 20

[Kai-Chih Hu [:khu]]

Vincent can't reproduce. But, it looks like bug 809663 is the same issue. 

We focus on bug 809663 that Gonk is involved. Hi, Henrik, could you make sure if this one is the same case as bug 809663? 

Thanks.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

In my case it sounds to be similar or the same, yes. Given that the reporter of this bug marked it as WFM a while back, I'm going to close this bug again as WFM and will continue to watch the other bug. Thanks!

Comment 22

[Kai-Chih Hu [:khu]]

Thank you, Henrik.

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Removing QAwanted as for comment 21.

I was not able to reproduce myself at this moment in time.