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)

x86_64
Windows 7
defect

Tracking

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.1 fixed)

RESOLVED FIXED
1.0.1 Madrid (19apr)
blocking-b2g tef+
Tracking Status
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.
blocking-b2g: tef? → tef+
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.
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.
Talked with Ken, RIL team manager, and he will provide some technical comments here. Thanks, Ken.
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)
(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)
(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.
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)
(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
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)
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.
Assignee: nobody → anshulj
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}
Assignee: anshulj → nobody
Jose Antonio, please take care of The Gaia part
Assignee: nobody → josea.olivera
blocking-b2g: tef? → tef+
Whiteboard: [madrid]
Whiteboard: [madrid] → [madrid], IOT
(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.
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)
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
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?
Target Milestone: --- → Madrid (19apr)
Depends on: 845629
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+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
bug 845629 needs approval before we can uplift this one
Flags: needinfo?(kaze)
Blocks: 863126
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)
Blocked on approvals... Will uplift once other bugs approved/uplifted.
Flags: needinfo?(dcoloma)
This bug was partially uplifted.

Uplifted 08f2547c34b02fb7920efc4e31e22023ce638873 to:
v1-train: df75da550af7e279d86ca2e8046df184d9d33f1d

Commit 08f2547c34b02fb7920efc4e31e22023ce638873 didn't uplift to branch v1.0.1
Flags: needinfo?(josea.olivera)
Flags: needinfo?(dcoloma)
(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)
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.
v1.0.1: aa307a6a46879ee100a867df42f5d1b17a226095
Blocks: 915113
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.

Attachment

General

Created:
Updated:
Size: