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

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.

Hi Philikon, can you help to review this patch ?

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!

Update the patch to address comment 4.

Looks like this hasn't landed in beta yet, do we have an ETA for this?

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)

(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.

(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!

opened https://bugzilla.mozilla.org/show_bug.cgi?id=819488