Closed Bug 815461 Opened 8 years ago Closed 8 years ago

wifi hotspot is not found after reboot

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

RESOLVED WONTFIX
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: ggrisco, Assigned: vchang)

Details

Attachments

(1 file, 1 obsolete file)

1. Turned on Wi-Fi hostpot from Internet Sharing page
2. Restarted the device

Expected result:  other device should be able to find the hotspot
Actual result:  device shows Wi-Fi hostpot still in On state, but other device can't connect to it.

3. turn Wi-Fi hostpot off
4. turn Wi-Fi hostpot back on

other device can now see the hotspot
Assignee: nobody → vchang
Status: UNCONFIRMED → NEW
blocking-basecamp: --- → ?
Ever confirmed: true
blocking-basecamp: ? → +
Priority: -- → P3
Vincent, you mentioned yesterday that we disable the hotspot if there's no active data connection.  Could it be that there's a race condition between enabling the hotspot and establishing a cellular data call, and if the data call loses we disable the hotspot?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #1)
> Vincent, you mentioned yesterday that we disable the hotspot if there's no
> active data connection.  Could it be that there's a race condition between
> enabling the hotspot and establishing a cellular data call, and if the data
> call loses we disable the hotspot?
The reason we can't enable Wifi tethering while no active data connection is because we need dns server ip and interface name of the data connection. Maybe we can hard code and update them when data connection is activated. Need to file the other bug to address this. After we turn on Wifi tethering successfully, we don't disable Wifi tethering even if data connection is done or disabled. It doesn't matter unless we need to bind new dns server and interface name.
Attached patch Patch v1.0 (obsolete) — Splinter Review
Hi Philikon, can you help to review this patch ?
Attachment #686497 - Flags: review?(philipp)
Comment on attachment 686497 [details] [diff] [review]
Patch v1.0

Review of attachment 686497 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the nits below fixed.

::: dom/system/gonk/NetworkManager.js
@@ +149,5 @@
>  
>    this.setAndConfigureActive();
> +
> +  let self = this;
> +  this.waitConnectionReadyCallback = null;

waitForConnectionReadyCallback

@@ +152,5 @@
> +  let self = this;
> +  this.waitConnectionReadyCallback = null;
> +  let initWifiTetheringEnabledCallback = {
> +    handle: function handle(aName, aResult) {
> +      if (aName !== "tethering.wifi.enabled" || !aResult) {

why is this necessary? why would aName ever be not this?

@@ +155,5 @@
> +    handle: function handle(aName, aResult) {
> +      if (aName !== "tethering.wifi.enabled" || !aResult) {
> +        return;
> +      }
> +      // Ture on WifiTethering when mobile data connection is established. 

Turn on wifi tethering when the mobile data connection is established. Please remove also training whitespace.

@@ +162,5 @@
> +        settingsLock.set("tethering.wifi.enabled", aResult, null);
> +      });
> +    },
> +    handleError: function handleError(aErrorMessage) {
> +      debug("Error reading the 'tethering.wifi.enabled' setting.");

also output aErrorMessage while you are at it

@@ +165,5 @@
> +    handleError: function handleError(aErrorMessage) {
> +      debug("Error reading the 'tethering.wifi.enabled' setting.");
> +    }
> +  };
> +  settingsLock.get(SETTINGS_WIFI_ENABLED, initWifiTetheringEnabledCallback);

just do this inline:

settingsLock.get(SETTINGS_WIFI_ENABLED, { handle: ... });

@@ +202,5 @@
>              // Remove pre-created default route and let setAndConfigureActive()
>              // to set default route only on preferred network
>              this.removeDefaultRoute(network.name);
>              this.setAndConfigureActive();
> +            // Turn on WifiTethering when we set the callback and mobile data 

trailing whitespace, please remove

@@ +671,5 @@
>    notifyError: function notifyError(resetSettings, callback, msg) {
>      if (resetSettings) {
>        let settingsLock = gSettingsService.createLock();
>        this.tetheringSettings[SETTINGS_WIFI_ENABLED] = false;
> +      // Disable WifiTethering with message. The message should be useful for application. 

Please watch out for trailing whitespace. You have that all over.

"Disable wifi tethering with a useful error message for the user."

@@ +700,5 @@
>      if (!mobile) {
>        this.notifyError(true, callback, "mobile interface is not registered");
>        return;
>      }
> +    // Clear this flag to prevent unexpected action. 

Trailing whitespace!
Attachment #686497 - Flags: review?(philipp) → review+
Priority: P3 → P1
Target Milestone: --- → B2G C2 (20nov-10dec)
Update the patch to address comment 4.
Attachment #686497 - Attachment is obsolete: true
Whiteboard: [has reviewed patch, check-in needed]
https://hg.mozilla.org/mozilla-central/rev/cd51ab1d33f5
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [has reviewed patch, check-in needed]
Looks like this hasn't landed in beta yet, do we have an ETA for this?
Flags: needinfo?(dietrich)
Component: Gaia::Settings → General
https://hg.mozilla.org/releases/mozilla-aurora/rev/70a785187d2d
https://hg.mozilla.org/releases/mozilla-beta/rev/deacea12e3d3

(FYI, I generally do daily uplifts of fixed bb+ bugs, but my queries don't look in the Gaia component since at least in theory Gaia patches go into github)
Flags: needinfo?(dietrich)
(In reply to Ryan VanderMeulen from comment #9)
> (FYI, I generally do daily uplifts of fixed bb+ bugs, but my queries don't
> look in the Gaia component since at least in theory Gaia patches go into
> github)

Can we change the queries?  We're missing patches :(
I had aplied this patch last week and it seemed to fix the problem.  Now that the patch has landed, I tested again and after reboot I could not see the soft AP from other device.  So I went to Internet sharing page, saw that Wi-Fi hotspot was enabled.  Then I turned Wi-Fi hotspot off, but the UI wouldn't let me turn hotspot back on.  Even after changing security settings, re-enabling data connection, and turning wifi on and off again, I could still not enable wifi hotspot.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to ggrisco from comment #11)
> I had aplied this patch last week and it seemed to fix the problem.  Now
> that the patch has landed, I tested again and after reboot I could not see
> the soft AP from other device.  So I went to Internet sharing page, saw that
> Wi-Fi hotspot was enabled.  Then I turned Wi-Fi hotspot off, but the UI
> wouldn't let me turn hotspot back on.  Even after changing security
> settings, re-enabling data connection, and turning wifi on and off again, I
> could still not enable wifi hotspot.

Is this a new bug?
ggrisco, please file a new bug for the issue with concrete steps to STR. Its difficult to track this bug if it already has a landed patch. Once filed please close this bug. Thanks!
Flags: needinfo?(ggrisco)
opened https://bugzilla.mozilla.org/show_bug.cgi?id=819488
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Flags: needinfo?(ggrisco)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.