Closed Bug 754152 Opened 13 years ago Closed 12 years ago

[b2g] if 3G is enabled at startup, it should be registered by the NetworkManager

Categories

(Firefox OS Graveyard :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

RESOLVED WORKSFORME
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: kaze, Assigned: vliu)

References

Details

Attachments

(2 obsolete files)

When 3G-data and wifi are enabled in the settings they are both activated when the device is restarted, but the 3G connection is not registered by NetworkManager (wifi is). Because of that, when the wifi is disabled the default route is not set to 3G until it’s manually disabled/enabled.
Blocks: b2g-3g
Kaze, can you clarify what this means? Maybe point to a line of code or submit a quick'n'dirty patch that outlines the problem? Thanks!
3G is not enabled on startup, but the settings says it is. The problem is 'ril.data.enabled' is only observing changes, not starting value: https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#648 ['ril.data.enabled', 'ril.data.roaming.enabled'].forEach(function(key) { SettingsListener.observe(key, false, function(value) { Services.prefs.setBoolPref(key, value); }); });
Component: DOM: Device Interfaces → General
Product: Core → Boot2Gecko
QA Contact: device-interfaces → general
Version: Trunk → unspecified
Right now there is not default value for 'ril.data.enabled'. We should set a default value for 'ril.data.enabled' (to false) in the setting data base like we do with some other settings (see https://github.com/mozilla-b2g/gaia/blob/master/build/settings.js#L17). So in the first run we won't set up the data call and will let the user to set up it by configuring the APN settings. Another thing that we have to take into account is how to use these data call settings. Please read http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#764.
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
blocking-kilimanjaro: --- → +
vliu, can you please take a look at this? Thanks!
Assignee: nobody → vliu
Hi Philipp, I will spend time to take a look at this.
Hi Philipp, I want to clarify issues in this bug. 1. The default value of ril.data.enabled should set to false. It is easily to understand and I will do that modification. 2. I am not clear about the following statements below. > Another thing that we have to take into account is how to use these data call settings. > Please read http://mxr.mozilla.org/mozilla-central/source/dom/system >/gonk/RadioInterfaceLayer.js#764. Is there any issue in it or what I should take in it? Thanks.
(In reply to vliu from comment #6) I would like to comment here with philikon's permission. > Hi Philipp, > > I want to clarify issues in this bug. > > 1. The default value of ril.data.enabled should set to false. It is easily > to understand and I will do that modification. There is a way to set default value to settings. The code lives in gaia. You have to have a clone of gaia on your machine. You can install a setting data base with default values by typing |make install-settingsdb|. For configuring default values for data calls, I mean the setting you are looking for, you have to change [1] to false. > > 2. I am not clear about the following statements below. > > Another thing that we have to take into account is how to use these > data call settings. > Please read > http://mxr.mozilla.org/mozilla-central/source/dom/system > >/gonk/RadioInterfaceLayer.js#764. > > Is there any issue in it or what I should take in it? Thanks. I would like to comment also that I have not seen this bug anymore. I am on otoro-ICS and I am not able to test it but running otoro-GB the data call set up properly at boot which means everything was fine including the registration of the RILNetworkInterface by the NetworkManager. The question is: Is still anyone seeing this bug? I can't confirm it since I am on otoro-ICS as mentioned but maybe anyone else could double confirm it.
Attachment #642946 - Flags: review?
(In reply to vliu from comment #8) > Created attachment 642946 [details] [diff] [review] > patch file to set false for ril.data.enabled That code lives in gaia so please do a pull request with that change there.
Sorry to press the key too fast. Hi Philikon, Can you please review the patch? If you no any comment, I will pull request this patch into gaia git hub
Attachment #642946 - Attachment is obsolete: true
Attachment #642946 - Flags: review?
Attachment #642949 - Flags: review?(philipp)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #7) > I would like to comment also that I have not seen this bug anymore. I am on > otoro-ICS and I am not able to test it but running otoro-GB the data call > set up properly at boot which means everything was fine including the > registration of the RILNetworkInterface by the NetworkManager. > > The question is: Is still anyone seeing this bug? I can't confirm it since I > am on otoro-ICS as mentioned but maybe anyone else could double confirm it. vliu, can you confirm this? If so, let's resolve this bug as WORKSFORME and add the ril.data.enabled = false default setting in Gaia (please submit a pull request for that). Thanks!
Comment on attachment 642949 [details] [diff] [review] patch file to set false for ril.data.enabled Clearing this, should be a pull request.
Attachment #642949 - Attachment is obsolete: true
Attachment #642949 - Flags: review?(philipp)
Hi Philikon, Pull request is done! I tried synced to latest and let the build environment set to FIRMWARE=GB in extract-files.sh. When I boot up the device, the device alway keep in searching state. Checked the Data Connection in Settings and it didn't click on. When I tried to set APN name and click on, I couldn't see any registeration of RILNetworkInterface by NetworkManger.
In GB, 3g function doesn't work is normal because the mis-matching issue. Please forget my comment 13.
With my patch for bug 775359 applied and 3G enabled in settings DB, I get a data call set up and routed once the device registers on the network. Resolving \o/
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: