Closed
Bug 860411
Opened 11 years ago
Closed 11 years ago
Roaming Broker or Double IMSI SIM card: APN changes with the REFRESH command
Categories
(Firefox OS Graveyard :: Gaia, defect, P1)
Tracking
(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.1 fixed)
People
(Reporter: dpalomino, Assigned: jaoo)
References
Details
(Whiteboard: [madrid], IOT)
Attachments
(3 files)
Buildid "20130321070205", device: ikura gecko commit: b5183c99228bdc5be33340e359efd1b4f0859e92 gaia commit: 577d13088ebdbd353d13910d3317e713a140415b This issue has been reported with a roaming broker STK application. When STK REFRESH command is executed, in order to change the IMSI, the APN is changed also and it shouldn't. Steps to reproduce: 1. Insert Roaming Broker STK SIM card and switch on the device 2. Wait until device is attached to the network 3. Via STK menu, execute REFRESH command (change of IMSI) Current: 4. Device remains attached to home network 5. APN changes to the one corresponding to the backup network Expected: 4. Device should be attached to the backup (new) network 5. APN should be maintained Adding certification dep (for Spain), and nominating for tef? This issue has not been reported by LatAm yet, but it is also blocking for Colombia. Additional info: When the attach process is completed the following sequence shall take place: 1. The subscriber requests the establishment of a PDP context. For example the APN can be “internet.operator”. 2. The VPMN identifies the subscriber as a TELEFONICA subscriber and therefore requests the resolution of the APN to a higher level DNS. The APN queried is internet.operator.mnc07.mcc214.gprs 3. The query reaches TELEFONICA DNS, which answers providing an IP address from TELEFONICA to the VPMN SGSN. The given address belongs to the pool of IP addresses that are assigned to the Dual IMSI Service GPRS system. 4. A PDP context establishment request is sent from the VPMN SGSN to the Dual IMSI GPRS system. 5. The Dual IMSI GPRS system will extract the correct original APN, compose a new query and send it to the HPMN original DNS to obtain a valid IP address of the HPMN GGSN where the requested service can be provided. 6. The HPMN DNS receives the query for the APN internet.operator.MNCYYY.MCCXXX.gprs and answers with the IP address of the HPMN GGSN. 7. The Dual IMSI GPRS system receives the IP address and request the establishment of a context using: a. The HPMN IMSI everywhere where it appears (tunnel identifiers…). b. A specific TELEFONICA IP address is inserted in the SSGN address. This address maps the original one of the VPMN, and thus provides information for VPMN identification which can be used for charging purposes. Even though the IP address shown to the HPMN belongs to TELEFONICA, TELEFONICA will provide a table indicating which IP addresses are assigned to each VPMN. By using this table, the HPMN can perfectly identify where the subscriber is roaming. The table is static and will be updated with each new GPRS Roaming agreement. 8. The HPMN accepts the context establishment. A tunnel is established between the HPMN and the Dual IMSI GPRS system. 9. The Dual IMSI GPRS system accepts the context establishment requested by the VPMN. Another tunnel is established between the Dual IMSI GPRS system and the HPMN 10. The Dual IMSI GPRS system links both tunnels. User data arriving from one tunnel is mapped to the other one. No one notices that the Dual IMSI GPRS system is acting in the middle. We have used the "Red de respaldo" SIM to do this test case using an IMSI of O2. Anyway, the APN shall be the same for Home and Broker suscription and it will be Telefonica.es. Solution: The APN should be fixed to Telefonica.es for any case, regardless of whether the user is placed in the Home NW or Visited NW and DuT must be attached to another network different from Movistar.
Updated•11 years ago
|
blocking-b2g: tef? → tef+
Assignee | ||
Comment 1•11 years ago
|
||
At a very high level of details the APN settings rely on mcc and mnc codes. Basically we set the ones corresponding to the MCC and MNC codes on boot. If the user changes the profile in the STK panel and the APN settings change is because the SIM is reporting a different values for MCC and MNC codes. That's it. Could you provide the MCC and MNC codes reported by the RIL before changing the profile and after doing it please? BTW, are you observing this issue with shipping RIL? Thanks.
Assignee | ||
Comment 2•11 years ago
|
||
Well, got them. On boot MCC and MNC codes are 214 and 7 respectively. After changing the profile the RIL reports 234 and 10 for MCC and MNC codes respectively. The APN change seems correct to me but maybe I'm not understanding what's going on. Why should the APN settings be maintained? Do you want to BTW, It seems this test was run with shipping RIL.
Comment 3•11 years ago
|
||
Talked with Ken, RIL team manager, and he will provide some technical comments here. Thanks, Ken.
Comment 4•11 years ago
|
||
Could you please share the following information to ms? 1. When the mcc and mnc are 214 and 7, what is the APN setting? 2. When the mcc and mnc are 234 and 10, what is the APN setting? Suppose that we should provide the different APM settings for different PLMN.
Flags: needinfo?(dpv)
Comment 5•11 years ago
|
||
(In reply to Ken Chang from comment #4) > Could you please share the following information to ms? > 1. When the mcc and mnc are 214 and 7, what is the APN setting? > 2. When the mcc and mnc are 234 and 10, what is the APN setting? > Suppose that we should provide the different APM settings for different PLMN. I got the information what I need form comment #0. (In reply to David Palomino [:dpv] from comment #0) > > Anyway, the APN shall be the same for Home and Broker suscription and it will > be Telefonica.es. > > > Solution: The APN should be fixed to Telefonica.es for any case, regardless > of > whether the user is placed in the Home NW or Visited NW and DuT must be > attached to another network different from Movistar. Tim, can you please help to assign someone to take this issue? What we have to do is that we don't change the APN setting when the SIM PLMN is 21007 and then SIM PLMN is changed from 21407 to 23410.
Assignee: nobody → timdream
Flags: needinfo?(dpv)
Comment 6•11 years ago
|
||
(In reply to Ken Chang from comment #5) > (In reply to Ken Chang from comment #4) > > Could you please share the following information to ms? > > 1. When the mcc and mnc are 214 and 7, what is the APN setting? > > 2. When the mcc and mnc are 234 and 10, what is the APN setting? > > Suppose that we should provide the different APM settings for different PLMN. > I got the information what I need form comment #0. > > (In reply to David Palomino [:dpv] from comment #0) > > > > Anyway, the APN shall be the same for Home and Broker suscription and it will > > be Telefonica.es. > > > > > > Solution: The APN should be fixed to Telefonica.es for any case, regardless > > of > > whether the user is placed in the Home NW or Visited NW and DuT must be > > attached to another network different from Movistar. > > Tim, can you please help to assign someone to take this issue? > What we have to do is that we don't change the APN setting when the SIM PLMN > is 21007 and then SIM PLMN is changed from 21407 to 23410. I'd suggest we hold on any work until we really know what the issue is and how should it be fixed. Hardcoding something does not seem the best solution. If this has to do with Operator Variant or STK I'd suggest :jaoo or :frsela take this bug as they have been working in both topics.
Comment 7•11 years ago
|
||
David, in the logs I didn't see the STK_CMD_REFRESH. When is it used? Why? or you mean another "REFRESH" command.
Flags: needinfo?(dpv)
Comment 8•11 years ago
|
||
(In reply to Daniel Coloma:dcoloma from comment #6) > > I'd suggest we hold on any work until we really know what the issue is and > how should it be fixed. Hardcoding something does not seem the best > solution. If this has to do with Operator Variant or STK I'd suggest :jaoo > or :frsela take this bug as they have been working in both topics. We need to break boundary here if :jaoo and :frsela on other stuff. If they could formulate a solution in written description, Taipei and others could gladly implement the solution. That being said, I agree with you that we should hold off until there is a better solution.
Assignee: timdream → nobody
Reporter | ||
Comment 9•11 years ago
|
||
Hi Fernando, Maybe we can meet with the testhouse next week in Madrid to take proper logs and study this issue insitu... Thks! David
Flags: needinfo?(dpv)
Comment 10•11 years ago
|
||
If we don't have enough info here to move forward we won't block on this at this point. Back to tef?.
blocking-b2g: tef+ → tef?
CCing Anshul, as I think it should be ril/modem bug. And from the log, David is using Commercial RIL. But I didn't see the log for REFRESH in both logs, either.
Comment 12•11 years ago
|
||
Just ran a test with Fernando using Commerical RIL. Saw the REFRESH command come as well as mcc/mnc change between refreshes. In particular, I'm seeing two different sets of mcc/mnc: 04-16 16:39:38.619 471 471 I Gecko : -*- RILContentHelper: Received message 'RIL:IccInfoChanged': {"iccid":"8934071300000000125","mcc":214,"mnc":7,"msisdn":null,"spn":null,"isDisplayNetworkNameRequired":true,"isDisplaySpnRequired":false} 04-16 16:39:58.269 471 471 I Gecko : -*- RILContentHelper: Received message 'RIL:IccInfoChanged': {"iccid":"8934071300000000125","mcc":262,"mnc":55,"msisdn":null,"spn":null,"isDisplayNetworkNameRequired":true,"isDisplaySpnRequired":false}
Updated•11 years ago
|
Assignee: anshulj → nobody
Comment 13•11 years ago
|
||
Jose Antonio, please take care of The Gaia part
Assignee: nobody → josea.olivera
blocking-b2g: tef? → tef+
Updated•11 years ago
|
Whiteboard: [madrid]
Updated•11 years ago
|
Whiteboard: [madrid] → [madrid], IOT
Assignee | ||
Comment 14•11 years ago
|
||
WIP
Assignee | ||
Comment 15•11 years ago
|
||
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #14) > Created attachment 738570 [details] > Pointer to Github PR: https://github.com/mozilla-b2g/gaia/pull/9245 > > WIP PR updated and patch tested on a device with a double IMSI SIM card (same conditions that the ones during certification tests). This patch seems to fix the issue. I'll request review at kaze and try to explain better why this fix is needed.
Assignee | ||
Comment 16•11 years ago
|
||
Comment on attachment 738570 [details] Pointer to Github PR: https://github.com/mozilla-b2g/gaia/pull/9245 Some carriers enable the ICC cards for their subscribers with a SIM tool known as Roaming Broker. Moreover the carrier enables these ICC cards with two different profiles (different mcc, mnc and MSISDN). The Roaming Broker tool is mainly used for being able to route network traffic while roaming when there is no agreement between the home carrier and the ones in foreign countries. The use case would be something like that, let me try to explain it. The subscriber travels to from the home network to a country where there is not roaming agreement between the subscriber's carrier and the ones in that foreign country. The Roaming Broker will detect that the subscriber is in roaming and perform a change between the two profiles in the SIM card. The trick somehow is that with this new profile the subscriber has changed which its carrier is. For this new carrier there is an agreement for roaming in the foreign country and the subscriber can get network connection. During the certification tests the team reported this issue because we perform a change in the APN setting when the MCC and MNC code changes. Apparently this is wrong and we must to keep the ones originally configured for the home network. This patch fix the issue. Basically it avoid reconfigure the APN settings if the MCC and MNC codes change. Kaze, I hope you understand the issue and the fix. This is quite tricky IMHO. Could you take a look please? Thanks. I'll be happy to reproduce the issue and request more information from the certification team if needed.
Attachment #738570 -
Flags: review?(kaze)
Reporter | ||
Comment 17•11 years ago
|
||
Many thanks jaoo! Just giving an example about how this feature works. Imagine three operators: a. Peru-mobile b. Columbia-mobile c. Spain-mobile Peru-mobile has roaming agreements with Spain-mobile, but not with Columbia mobile. 1. Imagine one guy from Peru, with a SIM from carrier "Peru-mobile" 2. This guy goes to Colombia with that SIM, being in roaming with "Colombia-mobile" 3. Device detects is on roaming, roaming broker application is fired 4. SIMs pretends to be a SIM from "Spain-mobile" (identifying with different fake IMSI, modifying MCC/MNC to match with "Spain-mobile"). Then device is attached to "Columbia-mobile" in roaming 5. APN should be maintained from the original settings (from "Peru-mobile"), not changed to the APN used for "Spain-mobile" I hope this clarifies a bit. Many thanks again! David
Comment 18•11 years ago
|
||
José-Antonio, I’m afraid we just changed the MCC/MNC type to be strings instead of integers, see bug 845629. Would you update your patch, please?
Updated•11 years ago
|
Target Milestone: --- → Madrid (19apr)
Comment 19•11 years ago
|
||
Comment on attachment 738570 [details] Pointer to Github PR: https://github.com/mozilla-b2g/gaia/pull/9245 Looks good to me, merged on master: https://github.com/mozilla-b2g/gaia/commit/08f2547c34b02fb7920efc4e31e22023ce638873 Warning: do not uplift without bug 845629.
Attachment #738570 -
Flags: review?(kaze) → review+
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 20•11 years ago
|
||
bug 845629 needs approval before we can uplift this one
Flags: needinfo?(kaze)
Assignee | ||
Comment 21•11 years ago
|
||
In order to avoid conflicts please uplift this bug in following this sequence: 1.- Uplift bug 845629. 2.- Uplift bug 863125. 3.- Uplift bug 860411 (current one). Thanks! Kaze is PTO, clearing needinfo. Do not hesitate contact me if help is needed.
Flags: needinfo?(kaze)
Comment 22•11 years ago
|
||
Blocked on approvals... Will uplift once other bugs approved/uplifted.
Flags: needinfo?(dcoloma)
Comment 23•11 years ago
|
||
This bug was partially uplifted. Uplifted 08f2547c34b02fb7920efc4e31e22023ce638873 to: v1-train: df75da550af7e279d86ca2e8046df184d9d33f1d Commit 08f2547c34b02fb7920efc4e31e22023ce638873 didn't uplift to branch v1.0.1
status-b2g18:
--- → fixed
Updated•11 years ago
|
Flags: needinfo?(josea.olivera)
Updated•11 years ago
|
Flags: needinfo?(dcoloma)
Assignee | ||
Comment 24•11 years ago
|
||
(In reply to James Lal [:lightsofapollo] from comment #23) > This bug was partially uplifted. > > Uplifted 08f2547c34b02fb7920efc4e31e22023ce638873 to: > v1-train: df75da550af7e279d86ca2e8046df184d9d33f1d > > Commit 08f2547c34b02fb7920efc4e31e22023ce638873 didn't uplift to branch > v1.0.1 See https://bugzilla.mozilla.org/show_bug.cgi?id=845629#c15 please. Thanks!
Flags: needinfo?(josea.olivera)
Assignee | ||
Comment 25•11 years ago
|
||
James, I'll do the uplift to v1.0.1 branch once we get a response from https://bugzilla.mozilla.org/show_bug.cgi?id=828307#c50. Thanks.
Updated•11 years ago
|
status-b2g18-v1.0.1:
--- → affected
Assignee | ||
Comment 26•11 years ago
|
||
v1.0.1: aa307a6a46879ee100a867df42f5d1b17a226095
Comment 27•9 years ago
|
||
Just wondering, when the Donor network (Telefonica) receives the apn:internet.operator.mnc07.mcc214.gprs and reply with the IP address assigned to the dual IMSI, how Telefonica differentiate between the APN sent by their bilateral roaming users & dual IMSI users since the apn/mnc/mcc still the same. one additional points, what will be the solution if the user is using multi-imsi services (several donors). Thanks,
You need to log in
before you can comment on or make changes to this bug.
Description
•