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.
I suspect this is a blocking requirement given target market. bb? to clee.
blocking-basecamp: --- → ?
This needs to be rock solid. Blocking.
blocking-basecamp: ? → +
Vincent, how are things going here? I haven't noticed this myself and neither has Lawrence Mandel.
Flags: needinfo?(clee) → needinfo?(vchang)
I can still reproduce this, even though my unagi is now auto-reconnecting to wifi after suspend.
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.
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?
blocking-basecamp: + → ?
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.
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.
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.
blocking-basecamp: ? → +
Priority: -- → P2
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.
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.
(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?
> . . . without requiring a restart. Typo. Not a restart; a suspension (whether manual or automatic).
(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 ?
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.
Target Milestone: --- → B2G C3 (12dec-1jan)
Is this still a problem ? If yes, may I have the logcat log ?
Works now! :D
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(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.
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.
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!
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → WORKSFORME
Thank you, Henrik.
Removing QAwanted as for comment 21. I was not able to reproduce myself at this moment in time.
You need to log in before you can comment on or make changes to this bug.