Closed Bug 710493 (b2g-3g) Opened 13 years ago Closed 11 years ago

[meta] B2G 3G connectivity

Categories

(Core :: DOM: Device Interfaces, defect)

Product:
Core
Component:
DOM: Device Interfaces
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp -

People

(Reporter: philikon, Unassigned)

References

Details

Attachments

(2 files, 4 obsolete files)

boundary check for atoi() in bionic/libc
582 bytes, patch
Details | Diff | Splinter Review
extract nvram_net.txt_murata for galaxy S2 ZSKI3 firmware
608 bytes, patch
Details | Diff | Splinter Review
thinker is working on adding 3G capabilities. This will involve managing data calls in the radio RIL and adding the necessary glue for a network management DOM API. And of course that DOM API itself. Those are pretty big chunks individually, so I'm creating this as a tracking bug that we can use to track these things.
Alias: b2g-3g
Jose Antonio and Fernando have looked into this.
Jose Antonio / Fernando, how far did you get in implementing this? Where does your latest code live? Thinker is going to post a summary of how far he got soon. We should combine our code and get it landed on upstream mozilla-central, and make sure we don't duplicate work.
We were working on it but did not get anything working. We sent RIL_REQUEST_SETUP_DATA_CALL parcels with a python script that qDot made for figuring out how to make calls but it did not work. We did not save those modifications anywhere because they were trivial. After that Fernando started working with philikon on SMS stuff. Let's wait Thinker to post how far he got and I can help and go ahead together.
There are also some notes related to this at https://github.com/mozilla-b2g/rilproxy/issues/19
I also make a data call with the Python script from qDot. I have successfully made data calls. rild extracted from S2 is buggy. It crashes for passing a null pointer to atoi() of bionic. You should patch atoi() of bionic to do boundary checking for null pointer, and return a zero for a null pointer. Or, you can hack it with gdb by setting a break point on atoi() and return a zero for null pointer. With this change, I can make data calls. You should also make sure that extract-files.sh for galaxy s2 extracts correct nvram_net.txt for you. For example, in Taiwan, you should copy nvram_net.txt_murata from firmware. This file is determined when rild was compiled. The name will be changed according where to ship devices. It defines spectrum and other configuration for modem. So, with a minor change for atoi() and extract-files.sh, I can make a data call by sending RIL_REQUEST_SETUP_DATA_CALL parcels. My current code is a Python script. it is in 3g-data-connect branch of https://github.com/ThinkerYzu/b2g-js-ril. I also have a partial implementation, in JS, based on dom/telephony of B2G Gecko.
thinker, do you want to attach the atoi() & extract-files.sh changes? Also, can we determine the modem profile name in extract-files.sh automatically?
I think the simplest way is to copy all profile 'nvram_net.txt*' from galaxy s2.
(In reply to Thinker Li from comment #7) > Created attachment 581614 [details] [diff] [review] > boundary check for atoi() in bionic/libc (In reply to Thinker Li from comment #8) > Created attachment 581616 [details] [diff] [review] > extract nvram_net.txt_murata for galaxy S2 ZSKI3 firmware Thanks for those. If this is stuff that should go into Gecko (mozilla-central), can you please file a bug blocking this bug and attach these there? If not, we should probably deal with these in Git & pull requests.
These two patches are not for Gecko. I like to send a pull request. But, B2G has no its owned repository. I have created a new issue on github. (https://github.com/andreasgal/B2G/issues/90) The pull request for second patch will be sent later.
We should patch atoi() to follow spec, but why is it getting passed a null ptr in our usage? Apparently this doesn't happen in android's usage ...
I am wondering that bionic following the device is not the same as our one, or variances of other libraries or environment avoid this potential bug. We can set a breakpoint on atoi() with original firmware to figure out if it also passes null pointer. But, event that, we still not know who make it happen since it is optimized and stripped. Does C-M use libc extracted from a device or build it by it-self?
Custom libc is a possibility, good point. CM uses its own bionic build. It would be interesting to see whether your change is already in the CM fork.
Component: DOM → DOM: Device Interfaces
QA Contact: general → device-interfaces
I had add a simple DOM API for PDP. And a simple UI in settings to setup a data call. If you enable a 3G data connection successful in settings, logcat will show following messages. I/Gecko ( 2639): -*- TelephonyWorker component: post connect I/Gecko ( 2639): RIL Worker: RIL Worker onmessage {"type":"connect","cdma":1," apn":"internet","user":"","passwd":"","chappap":0,"pdptype":"IP"} I/Gecko ( 2639): RIL Worker: Received DOM message {"type":"connect","cdma":1," apn":"internet","user":"","passwd":"","chappap":0,"pdptype":"IP"} I/Gecko ( 2639): RIL Worker: connect: {"type":"connect","cdma":1,"apn":"intern et","user":"","passwd":"","chappap":0,"pdptype":"IP"} I/Gecko ( 2639): RIL Worker: Outgoing parcel: 0,0,0,80,27,0,0,0,42,0,0,0,7,0,0 ,0,1,0,0,0,49,0,0,0,1,0,0,0,48,0,0,0,8,0,0,0,105,0,110,0,116,0,101,0,114,0,110,0 ,101,0,116,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,48,0,0,0,255,255,25 5,255 I/Gecko ( 2639): RIL Worker: Received 4 bytes. I/Gecko ( 2639): RIL Worker: Already read 0 I/Gecko ( 2639): RIL Worker: New incoming parcel of size 72 I/Gecko ( 2639): RIL Worker: Read 0, but parcel size is 72. Going to sleep. I/Gecko ( 2639): RIL Worker: Received 72 bytes. I/Gecko ( 2639): RIL Worker: Already read 0 I/Gecko ( 2639): RIL Worker: Parcel (size 72): 0,0,0,0,42,0,0,0,0,0,0,0,3,0,0, 0,1,0,0,0,49,0,0,0,4,0,0,0,112,0,100,0,112,0,48,0,0,0,0,0,13,0,0,0,49,0,49,0,49, 0,46,0,56,0,50,0,46,0,49,0,52,0,46,0,50,0,52,0,53,0,0,0 I/Gecko ( 2639): RIL Worker: We have at least one complete parcel. I/Gecko ( 2639): RIL Worker: Solicited response for request type 27, token 42 I/Gecko ( 2639): RIL Worker: Handling parcel as REQUEST_SETUP_DATA_CALL I/Gecko ( 2639): -*- TelephonyWorker component: Received message: {"type":"dat acall","cid":"1","ifname":"pdp0","ipaddr":"111.82.14.245","dns":"","gateway":""} The last line of messages tell us a PDP was set successfully. pdp0 is the interface for communication. Its IP address is 111.82.14.245 (you can ping it). After following command, you can ping to Internet. route add default dev pdp0 The relative code can be found at following repository - data-call branch of https://github.com/ThinkerYzu/gaia - data-call branch of https://github.com/ThinkerYzu/mozilla-central
Component: DOM: Device Interfaces → DOM
Component: DOM → DOM: Device Interfaces
After testing the work done by Thinker I would like to give you some feedback. The patch for atoi() of bionic is not correct, is it? It drops to check for null pointer and to return a zero for a null pointer and it is exactly what we want to do. Regarding data calls it works -through the python script- but if you configure different APN settings It doesn't work. req_cmd = CommandParcel.REQUEST_TYPES["RIL_REQUEST_SETUP_DATA_CALL"] req_parcel = CommandParcel(req_cmd) req_parcel.writeInt(7) req_parcel.writeString("1") # 0 for CDMA, 1 for GSM/UMTS req_parcel.writeString("0") # 0 for Default req_parcel.writeString("telefonica.es") # APN req_parcel.writeString("telefonica") # username req_parcel.writeString("telefonica") # passwd req_parcel.writeString("3") # 0 for PAP and CHAP is never performed req_parcel.writeString("IP") # PDP type I noticed data sent through RIL_REQUEST_SETUP_DATA_CALL parcel are not correctly received by the RIL because it shows the following message: E/RIL ( 2584): Requesting data connection to APN 'telefonica.es', (user: telefonica, passwd:(null), auth: 0) I'll try to figure out what's the problem. Keep you updated.
More feedback. There was a problem in the python script because the writeString function doesn't add correctly a null to the end. Now it works. E/RIL ( 2585): Requesting data connection to APN 'telefonica.es', (user: telefonica, passwd:telefonica, auth: 3) I have also tried to request that data connection through the JS RIL stack and it also works. I/Gecko ( 2587): RIL Worker: Received DOM message {"type":"connect","cdma":1,"apn":"telefonica.es","user":"telefonica","passwd":"telefonica","chappap":3,"pdptype":"IP"} … I/Gecko ( 2587): -*- TelephonyWorker component: Received message: {"type":"datacall","cid":"1","ifname":"pdp0","ipaddr":"10.173.179.92","dns":"","gateway":""} While testing it I noticed there is something more to be committed and pushed. The UI in settings is not connected to the telephony API, is it?
I had tried to send a pull request this week. But, gaia was changed dramatically. The code can not be merged. I will try another request in following days.
Target Milestone: --- → mozilla11
Version: Trunk → Other Branch
(In reply to jaoo from comment #16) > The patch for atoi() of bionic is not correct, is it? It drops to check for > null pointer and to return a zero for a null pointer and it is exactly what > we want to do. You are right. It is my fault to generate a reversing patch.
Target Milestone: mozilla11 → ---
Version: Other Branch → Trunk
(In reply to Thinker Li from comment #18) > I had tried to send a pull request this week. But, gaia was changed > dramatically. The code can not be merged. I will try another request in > following days. There are a few more pieces than just gaia here, right? There is the RIL worker stuff which should be pretty mechanical. Then there's the main thread handling and how it ties into (a) settings and (b) network management. Here we should discuss the design a bit. We should have individual bugs for at least these two things, blocking this one. Can you file those? If you already have patches for those, please also attach them and I'll be happy to review them.
We should start landing the individual pieces. The bionic patch can land right away for example.
I've been figuring out how DNS works on Android. Bionic uses a NetBSD-derived resolver library. This resolver reads the DNS server address form system properties such as |net.dns1,|net.dns2| and resolves the name. I've been playing around it because my operator returns DNS server addresses. Once the data call is up dhcpcd has assigned value to system properties such as |net.pdp0.dns1,net.pdp0.dns2| with the DNS server addresses delivered by the operator. In that situation you can resolve any name by running the following commands: ~ # setprop net.dns1 `getprop net.pdp0.dns1` ~ # setprop net.dns2 `getprop net.pdp0.dns2` ~ # route add default dev pdp0 ~ # ping google.es PING google.es (74.125.230.81) 56(84) bytes of data. 64 bytes from par03s01-in-f17.1e100.net (74.125.230.81): icmp_seq=1 ttl=51 time=445 ms So now we have to figure out how Android manages things such to establish a default route and to assign the DNS server addresses delivered by the operator to the system properties |net.dns1,|net.dns2|. Once we learn that we could integrate this functionality as a part of the Network API within the gonk backend or wherever.
(In reply to jaoo from comment #16) > > req_parcel.writeString("telefonica.es") # APN > > req_parcel.writeString("telefonica") # username > > req_parcel.writeString("telefonica") # passwd > > req_parcel.writeString("3") # 0 for PAP and CHAP is never performed I use only default APN (internet) without username and passwd. Is there any one who known where to find the information (username, password, and auth method)?
Assignee: tlee → nobody
I think most networks ignore those settings these days. There is probably a database of this stuff somewhere on the web or in android. The settings definitely can vary across carriers.
Assignee: nobody → tlee
Above patches are about ril_worker and WEB APIs. It is also with async model, likes what rild is. They only deal with requests for making connections and deactivating connections. But, response messages of requests are not dispatched.
Comment on attachment 584054 [details] [diff] [review] part 2: Support PDP data call in ril_worker Great stuff! There's a lot of comments below. Please don't be discouraged. :) > classID: TELEPHONYWORKER_CID, > classInfo: XPCOMUtils.generateCI({classID: TELEPHONYWORKER_CID, > contractID: TELEPHONYWORKER_CONTRACTID, > classDescription: "TelephonyWorker", > interfaces: [Ci.nsIRadioWorker, >- Ci.nsITelephone]}), >+ Ci.nsITelephone, >+ Ci.nsIPDP]}), > > QueryInterface: XPCOMUtils.generateQI([Ci.nsIRadioWorker, >- Ci.nsITelephone]), >+ Ci.nsITelephone, >+ Ci.nsIPDP]), Please add the data call functionality to nsITelephone. It represents everything the RIL can do (for instance, we're adding SMS capabilities to it, too). In fact, we are going to rename it to nsIRadioInterfaceLayer soon (bug 711671). >@@ -133,16 +135,22 @@ nsTelephonyWorker.prototype = { > * (1) Update the current state. This way any component that hasn't > * been listening for callbacks can easily catch up by looking at > * this.currentState. > * (2) Update state in related systems such as the audio. > * (3) Multiplex the message to telephone callbacks. > */ > onmessage: function onmessage(event) { > let message = event.data; >+ >+ if(message.type == "dump") { >+ dump(message.msg); >+ return; >+ } >+ Please get rid of this. You can dump() directly from the worker if you must. But you really want to use the "if (DEBUG) debug()" idiom. >+ connect: function connect(cdma, apn, user, passwd, chappap, pdptype) { Please call this method "setupDataCall" or something similar. >+ this.worker.postMessage({type: "connect", >+ cdma: cdma, >+ apn: apn, >+ user: user, >+ passwd: passwd, >+ chappap: chappap, >+ pdptype: pdptype}); >+ }, Nit: No tabs! Please always indent with spaces. Align all properties and parameters. >+ decative: function deactivate(cid, reason) { You misspelled "deactivate". Also, please call this method "deactivateDataCall". >+ getDataCallList: function getDataCallList() { >+ this.worker.postMessage({type: "getDataCallList"}); >+ }, >+ >+ getFailCauseCode: function getFailCauseCode() { >+ this.worker.postMessage({type: "getFailCauseCode"}); >+ }, I'm not sure this functionality should be exposed like this here. Have you seenhow we're dealing with regular phone calls by any chance?. ril_worker.js listens to, polls, and manages call state and then notifies the main thread (nsITelephonyWorker) of changes. Ben has even improved this further in his patch in bug 674726 (it's rather large, just look for the pieces that touch ril_worker.js). Unless there are compelling reasons to expose the raw RIL interface here, I think we should follow the same model foherer data calls. >diff --git a/dom/telephony/ril_worker.js b/dom/telephony/ril_worker.js >--- a/dom/telephony/ril_worker.js >+++ b/dom/telephony/ril_worker.js ... > /** >+ * Setup a data call. >+ * >+ * @param cdma >+ * Integer to indicate if use CDMA radio technology. The naming of this parameter is very misleading, because according to ril.h, it should be 0 for CDMA and 1 for GSM. I suggest calling it 'radioTechnology' or similar and then we should const those values in ril_consts.js, e.g. const DATACALL_RADIOTECHNOLOGY_CDMA = 0; const DATACALL_RADIOTECHNOLOGY_GSM = 1; Please refer to these (e.g. DATACALL_RADIOTECHNOLOGY_*) in the explanation for the 'radioTechnology' parameter. >+ * @param apn >+ * String containing the name of APN to connect to. >+ * @param user >+ * String containing the username for APN. >+ * @param passwd >+ * String containing the password for APN. Grammar: s/APN/the APN/g >+ * @param chappap >+ * Integer containing CHAP/PAP auth type. The possible values should be const'ed in ril_consts, e.g. const DATACALL_AUTH_NONE = 0; const DATACALL_AUTH_PAP = 1; const DATACALL_AUTH_CHAP = 2; const DATACALL_AUTH_PAP_OR_CHAP = 3; Please refer to them in the comment. >+ * @param pdptype >+ * String containing PDP type to request. ("IP", "IPV6", ...) >+ */ >+ connect: function connect(cdma, apn, user, passwd, chappap, pdptype) { >+ let token = Buf.newParcel(REQUEST_SETUP_DATA_CALL); Same as above: please call this method "setupDataCall" >+ Buf.writeUint32(7); >+ Buf.writeString("" + cdma); >+ Buf.writeString("0"); // profile (default) Seems like this should be a parameter, with const'ed values: const DATACALL_PROFILE_DEFAULT = 0; const DATACALL_PROFILE_TETHERED = 1; const DATACALL_PROFILE_OEM_BASE = 1000; // for OEM-provided profiles >+ /** >+ * Deactivate a data call. >+ * >+ * @param cid >+ * String containing CID. >+ * @param reason >+ * 0 => no reason, >+ * 1 => radio shutdown. Same drill as with the other methods: please const these values and refer to them in the comment. >+ */ >+ decative: function deactivate(cid, reason) { >+ let token = Buf.newParcel(REQUEST_DEACTIVATE_DATA_CALL); Same as above: You misspelled "deactivate" and please call this method "deactivateDataCall". >+ /** >+ * Get a list of data calls. >+ */ >+ getDataCallList: function getDataCallList() { >+ let token = Buf.newParcel(REQUEST_DATA_CALL_LIST); >+ Buf.sendParcel(); These two lines can be replaced with Buf.simpleRequest(REQUEST_DATA_CALL_LIST); >+ /** >+ * Get failure casue code for the most recently failed PDP context. >+ */ >+ getFailCauseCode: function getFailCauseCode() { >+ let token = Buf.newParcel(REQUEST_LAST_CALL_FAIL_CAUSE); >+ Buf.sendParcel(); Ditto. >+RIL[REQUEST_SETUP_DATA_CALL] = function REQUEST_SETUP_DATA_CALL() { >+ let strs = Buf.readStringList(); >+ let cid = strs[0]; >+ let ifname = strs[1]; >+ let ipaddr = strs[2]; >+ let dns = strs.length >= 4? strs[3]: ""; >+ let gw = strs.length >= 5? str[4]: ""; Nit: spaces around all operators on both sides. But, due to JavaScript's nature, you don't need to be this defensive. You can just do this: let [cid, ifname, ipaddr, dns, gw] = Buf.readStringList(); 'dns' and 'gw' will be 'undefined' if the string list was not long enough. That's fine, it's a better value than an empty string IMHO. >+ onSetupDataCall: function onSetupDataCall(cid, ifname, ipaddr, dns, gw) { >+ this.sendDOMMessage({type: "datacall", I suggest using a more descriptive name, such as "dataCallSetUp". >+ cid: cid, >+ ifname: ifname, >+ ipaddr: ipaddr, >+ dns: dns, >+ gateway: gw}); Same as above: use spaces instead of tabs, align properties. > /** >+ * Setup a data call (PDP). >+ */ >+ connect: function connect(options) { Same as above: please call this method "setupDataCall" >+ if(DEBUG) debug("connect: " + JSON.stringify(options)); Please get rid of this in the final patch. >+ RIL.connect(options.cdma, options.apn, options.user, options.passwd, >+ options.chappap, options.reason); Nit: tabs, alignment. >+ /** >+ * Deactivate a data call (PDP). >+ */ >+ deactivate: function deactivate(options) { >+ RIL.deactivate(options.cid, options.reason); >+ }, Same as above: please call this method "deactivateDataCall". (I see that here you didn't misspell "deactivate", which makes me suspicious. Did you test this code at all? It's easy to test interactively using our testbed extension at https://github.com/philikon/b2g-js-ril) >+ /** >+ * Get the list of data calls. >+ */ >+ getDataCallList: function getDataCallList(options) { >+ RIL.getDataCallList(); >+ }, >+ >+ /** >+ * Get failure cause code for the last failed PDP context. >+ */ >+ getFailCauseCode: function getFailCauseCode(options) { >+ RIL.getFailCauseCode(); >+ }, As I said above, I don't think these methods make much sense as a "public" API. The Phone object should manage call state and notify the main thread accordingly. To that end, it probably also should listen to UNSOLICITED_DATA_CALL_LIST_CHANGED, no? > if (!this.debug) { > // Debugging stub that goes nowhere. > this.debug = function debug(message) { >- dump("RIL Worker: " + message + "\n"); >+ postMessage({type: "dump", msg: "RIL Worker: " + message + "\n"}); >+ //dump("RIL Worker: " + message + "\n"); Please get rid of these changes. If you have a problem with seeing debug output from the worker, we need to fix that rather than this hack... Please file bugs for any problems you're seeing. > onmessage = function onmessage(event) { >+ debug("RIL Worker onmessage " + JSON.stringify(event.data)); Please get rid of this in the final patch.
Comment on attachment 584055 [details] [diff] [review] part 3: Define WEB API interface for data call I'm pretty sure we don't want to add this functionality to the WebTelephony API. In any case, this interface and the implementation in Telephony.js are going away very soon with bug 674726.
Attachment #584055 - Flags: feedback-
(In reply to Philipp von Weitershausen [:philikon] from comment #30) > >@@ -133,16 +135,22 @@ nsTelephonyWorker.prototype = { > > * (1) Update the current state. This way any component that hasn't > > * been listening for callbacks can easily catch up by looking at > > * this.currentState. > > * (2) Update state in related systems such as the audio. > > * (3) Multiplex the message to telephone callbacks. > > */ > > onmessage: function onmessage(event) { > > let message = event.data; > >+ > >+ if(message.type == "dump") { > >+ dump(message.msg); > >+ return; > >+ } > >+ > > Please get rid of this. You can dump() directly from the worker if you must. > But you really want to use the "if (DEBUG) debug()" idiom. > It is not work for me to call dump() directly from the worker. That is why I do this. I will try it later.
(In reply to Philipp von Weitershausen [:philikon] from comment #31) > Comment on attachment 584055 [details] [diff] [review] > part 3: Define WEB API interface for data call > > I'm pretty sure we don't want to add this functionality to the WebTelephony > API. In any case, this interface and the implementation in Telephony.js are > going away very soon with bug 674726. Should I postpone this part of work until bug 674726 being landed?
(In reply to Thinker Li from comment #33) > Should I postpone this part of work until bug 674726 being landed? Well, bug 674726 has nothing to do this work because we don't want this to go into the telephony API. The APIs added to nsITelephone should really talk to the network manager that we're devising in bug 713199. It should use nsITelephone (later nsIRadioInterfaceLayer) to manage the 3G connection. You could prototype this network manager now and then later we can revise it in bug 713199.
Comment on attachment 584055 [details] [diff] [review] part 3: Define WEB API interface for data call rework it later.
Attachment #584055 - Attachment is obsolete: true
Comment on attachment 584056 [details] [diff] [review] part 4: Implement WEB APIs for data call Find a better place to land it.
Attachment #584056 - Attachment is obsolete: true
(In reply to Thinker Li from comment #32) > (In reply to Philipp von Weitershausen [:philikon] from comment #30) > > >@@ -133,16 +135,22 @@ nsTelephonyWorker.prototype = { > > > * (1) Update the current state. This way any component that hasn't > > > * been listening for callbacks can easily catch up by looking at > > > * this.currentState. > > > * (2) Update state in related systems such as the audio. > > > * (3) Multiplex the message to telephone callbacks. > > > */ > > > onmessage: function onmessage(event) { > > > let message = event.data; > > >+ > > >+ if(message.type == "dump") { > > >+ dump(message.msg); > > >+ return; > > >+ } > > >+ > > > > Please get rid of this. You can dump() directly from the worker if you must. > > But you really want to use the "if (DEBUG) debug()" idiom. > > > > It is not work for me to call dump() directly from the worker. > That is why I do this. I will try it later. I had it again earlier today. dump() is not work from the worker.
(In reply to Thinker Li from comment #37) > I had it again earlier today. dump() is not work from the worker. Hmm yes it doesn't work for me either. I could swear it used to work, but maybe I'm wrong. Anyway, we should file this as a bug. Probably the dump() function in (Chrome)Workers doesn't do the right thing for logcat yet. We should definitely not leave this hack in the final patch.
Depends on: 713426
Comment on attachment 584053 [details] [diff] [review] part 1: Define interface for PDP Move to Bug 713426
Attachment #584053 - Attachment is obsolete: true
Comment on attachment 584054 [details] [diff] [review] part 2: Support PDP data call in ril_worker Move to bug 713426
Attachment #584054 - Attachment is obsolete: true
http://live.gnome.org/NetworkManager/MobileBroadband/ServiceProviders Gnome owns a project to maintain a database of service providers. It provides information about APN, username, and password. We need this database to find APN, username, and password to establish connections. This database is PD licensed.
What's the current status here?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #42) > What's the current status here? There's a patch for the RIL in bug 713426. Not sure if it's review-ready yet. Thinker? Main-thread plumbing awaiting details on network manager component.
Group: mozilla-confidential
I had rebased the patch on Ben's patches for bug 674726 one week ago. I will rebase the patch again for latest update from Ben. Is is a good time to review bug 713426 before bug 674726 being landed?
(In reply to Thinker Li from comment #44) > I had rebased the patch on Ben's patches for bug 674726 one week ago. I > will rebase the patch again for latest update from Ben. Is is a good time > to review bug 713426 before bug 674726 being landed? Sure. We can review now and then land as soon as bent has landed his stuff. Feel free to throw a review request at me.
Philipp, is there any reason why you put this bug as mozilla confidential?
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #46) > Philipp, is there any reason why you put this bug as mozilla confidential? Uh, nope. Must've been an accident. Thanks for catching that!
Group: mozilla-confidential
Blocks: 717122
There are still two patches to apply regarding data calls such as to patch bionic/libc and extract-files.sh. The latter is for extracting particular blobs needed to establish data calls through the ril daemon (see comment #5). Thinker created an issue on github (https://github.com/andreasgal/B2G/issues/90) but there is not much activity on that discussion so let's continue it in order to end tasks in this bug. I will be happy to help here -with the Thinker's permission- and provide both patches. I guess the best way to do that is to deal with these in github and pull requests, right?
jaoo: You are free to do both of them.
Depends on: 725901
Depends on: 729440
Depends on: 734299
Assignee: tlee → nobody
Depends on: 735492
Depends on: 740640
We still need to fill in the gap between the navigator.settings API and the data connection setting. The navigator.settings API is already landed so we could start working on that issue. AFAIK there is no any bug tracking that issue yet. Could I file a new bug and start working on it?
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #50) Hi, jaoo For data connection settings, you mean apn, username, password settings, right? That's covered in Bug 729440, and I think that will mostly be done in RadioInterfaceLayer. For Settings API to negotiate with RadioInterfaceLayer I think it will be covered in Bug 717122. I am not sure where the code is now, But I think the delegation will be SettingsAPI --- NetworkManager --- NetworkInterface --- RadioInterfaceLayer
AFAIK the Bug 729440 is for doing it automatically but IMHO we should let the user to set the APN settings, user name and password through the setting application. The flow would be Settings application > Settings API > RIL plumbing. Right now RadioLayerInterface takes the APN settings from the B2G preference file and the idea is to change this as is commented in [1]. That is what I meant in comment #50. [1] http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#476
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #50) > We still need to fill in the gap between the navigator.settings API and the > data connection setting. The navigator.settings API is already landed so we > could start working on that issue. AFAIK there is no any bug tracking that > issue yet. Could I file a new bug and start working on it? Yes please! (In reply to Yoshi Huang[:yoshi] from comment #51) > For data connection settings, you mean apn, username, password settings, > right? Correct. > That's covered in Bug 729440, and I think that will mostly be done in > RadioInterfaceLayer. It's not necessarily covered by bug 729440. I think we should definitely do bug 729440, but (a) it will not obsolete the need for a settings API hookup and (b) the settings API hookup will almost certainly be quicker solution. > For Settings API to negotiate with RadioInterfaceLayer > I think it will be covered in Bug 717122. Not really. > I am not sure where the code is now, > But I think the delegation will be > SettingsAPI --- NetworkManager --- NetworkInterface --- RadioInterfaceLayer Nope. Network Manager just manages switch over. It doesn't manage whether and how interfaces are configured.
No longer blocks: 717122
Depends on: 717122
Depends on: 744453
Depends on: 744700
Depends on: 754152
Depends on: 762425
Meta, but blocks a blocker.
blocking-basecamp: --- → ?
Depends on: 766895
All deps nommed or +ed now.
blocking-basecamp: ? → -
Depends on: 775359
Depends on: 775375
Depends on: 775814
Depends on: 777284
Depends on: 794342
Depends on: 794336
Depends on: 804500
Depends on: 804531
No longer depends on: 794336
Close for no more things to do on this bug itself.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: