Re: [RFC PATCH] gprs: add function to handle activated context
Hi Pekka. Pekka Pessi wrote: >> I'm not sure we have any problems with Network Initiated Connection in oFono, >> unless someone is planning to add support for Network Initiated >> Primary Contexts / PDN Connections. > > AFAIK the initial LTE default bearer context can be network-initiated, > and the CID 0 falls outside the range from +CGDCONT. If I am not mistaken the initial LTE default bearer is initiated by the ME in a combined attach procedure, and not by the Network. (but the Dedicated bearers / Secondary PDPs are activated by the Network). Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, 2011/1/17 Sjur Brændeland : >> The 27.007 for release 9 (from version 9.3.0 onwards) says: >> >> NOTE 1: The s for network-initiated PDP contexts will have values >> outside the ranges indicated for the >> in the test form of the commands +CGDCONT and +CGDSCONT. >> >> The change was proposed by STE last February. >> >> This has some ramifications on how we use the CIDs within driver/core. > > I'm not sure we have any problems with Network Initiated Connection in oFono, > unless someone is planning to add support for Network Initiated > Primary Contexts / PDN Connections. AFAIK the initial LTE default bearer context can be network-initiated, and the CID 0 falls outside the range from +CGDCONT. > If we need to expose information about the Network Initiated Dedicated > Bearers, > I don't think we should model this as separate Connection-Contexts (with CID), > but rather as a dictionary within the primary context object containing > the necessary information about the QoS available. > > I guess we need to hear from IMS-folks the minimum information they > need about the QoS, and provide just that information. Uh, on one hand, the IMS Signaling flag for signaling. For audio/video, we need QCI, a GBR rate, and TFT. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi, So far we have been discussing CID races, but if we solve the CID issue, we still might end up with two "identical" Connections activated with the same connection properties (APN, Username, Password), one initiated by the modem in the LTE Combined Attach procedure and the other being a "normal" Context Activation, right? How do we protect against establishing two contexts with the same properties? Also: what is the likelihood of not having information the initial PDN defined in the provisioning database, would this be an exceptional case only? Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi, Pekka Pessi wrote: > The 27.007 for release 9 (from version 9.3.0 onwards) says: > > NOTE 1: The s for network-initiated PDP contexts will have values > outside the ranges indicated for the > in the test form of the commands +CGDCONT and +CGDSCONT. > > The change was proposed by STE last February. > > This has some ramifications on how we use the CIDs within driver/core. I'm not sure we have any problems with Network Initiated Connection in oFono, unless someone is planning to add support for Network Initiated Primary Contexts / PDN Connections. Because the Network Initiated Contexts we are dealing with will be Secondary PDP Contexts / Dedicated Bearers. If we need to expose information about the Network Initiated Dedicated Bearers, I don't think we should model this as separate Connection-Contexts (with CID), but rather as a dictionary within the primary context object containing the necessary information about the QoS available. I guess we need to hear from IMS-folks the minimum information they need about the QoS, and provide just that information. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi all, 2011/1/7 Denis Kenzior : >> Considering that from a modem standpoint the CID race condition can be >> resolved, >> some modem implementation may not have reserved a range of CID for their own >> purpose, >> or may not provide a mechanism to reserve a range of CID. > > If the CGDCONT race is guaranteed to be solved by the modem > manufacturers, great. Unfortunately that is not the only race present. > Hint: The gatchat implementation uses non-blocking IO, select and a > command queue. So it is fully possible for oFono to reserve a CID, send > out a driver activation request, but receive a network initiated context > activation / default bearer activation before the CGDCONT was even sent. > > Having cid ranges that do not overlap seems the safest approach to me > right now. Unless someone has a better idea... The 27.007 for release 9 (from version 9.3.0 onwards) says: NOTE 1: The s for network-initiated PDP contexts will have values outside the ranges indicated for the in the test form of the commands +CGDCONT and +CGDSCONT. The change was proposed by STE last February. This has some ramifications on how we use the CIDs within driver/core. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
Hi Denis, > > Considering that from a modem standpoint the CID race condition can > be resolved, > > some modem implementation may not have reserved a range of CID for > their own purpose, > > or may not provide a mechanism to reserve a range of CID. > > > > If the CGDCONT race is guaranteed to be solved by the modem > manufacturers, great. Unfortunately that is not the only race present. > Hint: The gatchat implementation uses non-blocking IO, select and a > command queue. So it is fully possible for oFono to reserve a CID, > send out a driver activation request, but receive a network initiated > context activation / default bearer activation before the CGDCONT was > even sent. > > Having cid ranges that do not overlap seems the safest approach to me > right now. Unless someone has a better idea... > I think we have two cases : 1- CGDCONT=X,... is sent to the modem (ERROR response) before we get "+CGEV: ME PDN ACT X" 2- CGDCONT=X,... is sent to the modem (ERROR response) after we get "+CGEV: ME PDN ACT X" For the first case the CID will be released inside oFono core before we get "+CGEV" event : No problem For the second case the CID will be released inside oFono after we get "+CGEV" event , but we are sure it'll be released : No problem But regardless the solution we choose either the CID sent by the driver should be free or the CID sent by the driver should be outside the range, in both solutions the submitted patch should be ok. Could you confirm ? Regarding Context type maybe we can keep Internet today and see how far we can get ? Regards, - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Rémi, On 01/07/2011 02:52 AM, Rémi Denis-Courmont wrote: > On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote: If such context is not found create a new one with "Internet" type. >>> >>> I don't really agree that we should create a context if no match is >>> found. I think the better sensible strategy is to hold this information >>> internally and only map it to a context once the user or provisioning >>> creates it. >> >> From what I understood it should be quite safe to assume it is an >> internet context. All IMS contexts will have a well-known APN and the >> only other one that would make sense for the network to activate >> automatically would be the internet one. >> >> Perhaps this is the missing piece in the description? The fact that >> either the IMS or an Internet context is created. > > It could be MMS(/WAP) or it could be some private corporate VPN. Or it could > even be some other silliness from some operator(s). I have seen such thing, > but I am unsure I can talk freely about the details :-( > > I would definitely advise against marking unknown context as Internets. > So there might be two things going on here: - Default Bearer when attaching to LTE. From what I understood this is unlikely to ever be anything but an Internet context. Maybe an IMS default bearer, but then the APN should be well known. So the proposed approach should work well enough in my view. We might need some extra sanity checking here. E.g. we're in LTE domain, and this is the first context active. - Random Primary / Secondary PDN activation from the network. This context can indeed be just about anything. Fortunately this isn't really used all that often. So if we got one of these activated and we don't have any idea what this context is (e.g. no provisioning info), then about the only sane thing to do is to deactivate it. Exposing "unknown" contexts is the wrong approach in my view. Unless of course someone plans to ship a psychic with every phone.. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Fred, >>> The collision can only occur if the +CGDCONT (or +CGDSCONT) command from >>> Ofono is sent at the same time as PDP >>context activation URC from the >>> modem, and both use the same CID. >>> >>> But in that case, the modem should not reply "OK" to the PDP context >>> configuration command, but "ERROR". >>> And Ofono should not consider that the PDP configuration command as >>> successful. >>> Moreover, the "OK" for the context configuration and the context activation >>> URC are sent of the same control >>> channel so they cannot be sent in parallel but only in sequence. >>> >>> Sjur, is that a correct assumption? >> >> Yes, this sounds about right. >> But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs, >> , ) pretty much solves this issue, >> We can use this to reserve the CID used for Initial PDN, and void this >> race condition. > I have to admit that I'm not yet fully comfortable with the solution proposed > by Denis. > At least as long as we want to keep a on 1:1 mapping between the Ofono CID > and the AT CID. > If I have understood correctly, the Ofono Core is "chosing" a CID > and the modem plugin is trying to use the same CID on the AT interface. > The way to resolve the race condition as proposed by Denis is to "reserve" a > range of CIDs > for the modem and another range for ofono. > > My concern is that I don't know if this will work for all the modem > implementations. > My understanding is that an AT+CGDCONT=? should return you the list of > supported CID > and not the list of CID that the user/Ofono can use. It is up to the driver to set the ranges appropriately based upon its much more intimate knowledge of the modem firmware. The drivers that do not support LTE / network activated contexts can ignore this magic. > > Considering that from a modem standpoint the CID race condition can be > resolved, > some modem implementation may not have reserved a range of CID for their own > purpose, > or may not provide a mechanism to reserve a range of CID. > If the CGDCONT race is guaranteed to be solved by the modem manufacturers, great. Unfortunately that is not the only race present. Hint: The gatchat implementation uses non-blocking IO, select and a command queue. So it is fully possible for oFono to reserve a CID, send out a driver activation request, but receive a network initiated context activation / default bearer activation before the CGDCONT was even sent. Having cid ranges that do not overlap seems the safest approach to me right now. Unless someone has a better idea... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, >-Original Message- >From: Sjur Brændeland [mailto:sjurb...@gmail.com] >Sent: Friday, January 07, 2011 4:39 PM >To: ofono@ofono.org; Joly, Frederic >Subject: Re: [RFC PATCH] gprs: add function to handle activated context > >Hi Fred, > >Frederic wrote: >>The collision can only occur if the +CGDCONT (or +CGDSCONT) command from >>Ofono is sent at the same time as PDP >>context activation URC from the >>modem, and both use the same CID. >> >> But in that case, the modem should not reply "OK" to the PDP context >> configuration command, but "ERROR". >> And Ofono should not consider that the PDP configuration command as >> successful. >> Moreover, the "OK" for the context configuration and the context activation >> URC are sent of the same control >> channel so they cannot be sent in parallel but only in sequence. >> >> Sjur, is that a correct assumption? > >Yes, this sounds about right. >But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs, > , ) pretty much solves this issue, > We can use this to reserve the CID used for Initial PDN, and void this > race condition. I have to admit that I'm not yet fully comfortable with the solution proposed by Denis. At least as long as we want to keep a on 1:1 mapping between the Ofono CID and the AT CID. If I have understood correctly, the Ofono Core is "chosing" a CID and the modem plugin is trying to use the same CID on the AT interface. The way to resolve the race condition as proposed by Denis is to "reserve" a range of CIDs for the modem and another range for ofono. My concern is that I don't know if this will work for all the modem implementations. My understanding is that an AT+CGDCONT=? should return you the list of supported CID and not the list of CID that the user/Ofono can use. Considering that from a modem standpoint the CID race condition can be resolved, some modem implementation may not have reserved a range of CID for their own purpose, or may not provide a mechanism to reserve a range of CID. Maybe members of the list could comment on this? Thanks, Fred - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
-Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Rémi Denis-Courmont Sent: Friday, January 07, 2011 9:52 AM To: ofono@ofono.org Subject: Re: [RFC PATCH] gprs: add function to handle activated context On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote: >> >> If such context is not found create a new one with "Internet" type. >> > >> > I don't really agree that we should create a context if no match is >> > found. I think the better sensible strategy is to hold this information >> > internally and only map it to a context once the user or provisioning >> > creates it. >> >> From what I understood it should be quite safe to assume it is an >> internet context. All IMS contexts will have a well-known APN and the >> only other one that would make sense for the network to activate >> automatically would be the internet one. >> >> Perhaps this is the missing piece in the description? The fact that >> either the IMS or an Internet context is created. > >It could be MMS(/WAP) or it could be some private corporate VPN. Or it could >even be some other silliness from some operator(s). I have seen such thing, >but I am unsure I can talk freely about the details :-( > >I would definitely advise against marking unknown context as Internets. This makes sense. In the case this context is resulting from a PDN connectivity Request piggybacked on an Attach Request, should we assume that that this initial context could be an MMS or a private corporate VPN related context? My assumption would be that in this particular case that the context is an "internet" or an "IMS" context. The reception of an MMS "push" over SMS on the circuit switched domain could provoke the attach, but I would guess in this case that: a second context initiated by the UE is used specifically for the MMS or the PDN connectivity request includes a MMS APN with an ESM information transfer flag to transfer securely the "login and password" required to download the MMS. I can also hardly imagine that an initial bearer context being a "VPN" specific bearer. But, maybe I'm wrong. BR, Fred -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Fred, Frederic wrote: > The collision can only occur if the +CGDCONT (or +CGDSCONT) command from > Ofono is sent at the same time as PDP context activation URC from the modem, > and both use the same CID. > > But in that case, the modem should not reply "OK" to the PDP context > configuration command, but "ERROR". > And Ofono should not consider that the PDP configuration command as > successful. > Moreover, the "OK" for the context configuration and the context activation > URC are sent of the same control channel so they cannot be sent in parallel > but only in sequence. > > Sjur, is that a correct assumption? Yes, this sounds about right. But I think Denis' proposal for using ofono_gprs_set_cid_range(gprs, , ) pretty much solves this issue, We can use this to reserve the CID used for Initial PDN, and void this race condition. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
Hi, My two cents on context activation race: the collision between a network initiated context activation and UE initiated context activation. There is a potential issue if the modem and ofono try to assign the same CID at the same time Basically the sequence of AT commands looks like the following for the activation of PDP context: AT+CGDCONT=CID,X,Y,Z OK A+CGACT= CID,1 OK The collision can only occur if the +CGDCONT (or +CGDSCONT) command from Ofono is sent at the same time as PDP context activation URC from the modem, and both use the same CID. But in that case, the modem should not reply "OK" to the PDP context configuration command, but "ERROR". And Ofono should not consider that the PDP configuration command as successful. Moreover, the "OK" for the context configuration and the context activation URC are sent of the same control channel so they cannot be sent in parallel but only in sequence. Sjur, is that a correct assumption? Thanks, Fred - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi, 2011/1/7 Rémi Denis-Courmont : > On Thursday 06 January 2011 02:12:01 ext Marcel Holtmann, you wrote: >> > If such context is not found create a new one with "Internet" type. >> >> I don't really agree that we should create a context if no match is >> found. I think the better sensible strategy is to hold this information >> internally and only map it to a context once the user or provisioning >> creates it. > > Indeed. Alternatively, we could have a dedicated type, e.g. "Unknown". Using > the Internet type is only likely to confuse the connection manager. +1 Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
On Thursday 06 January 2011 02:17:09 ext Denis Kenzior, you wrote: > >> If such context is not found create a new one with "Internet" type. > > > > I don't really agree that we should create a context if no match is > > found. I think the better sensible strategy is to hold this information > > internally and only map it to a context once the user or provisioning > > creates it. > > From what I understood it should be quite safe to assume it is an > internet context. All IMS contexts will have a well-known APN and the > only other one that would make sense for the network to activate > automatically would be the internet one. > > Perhaps this is the missing piece in the description? The fact that > either the IMS or an Internet context is created. It could be MMS(/WAP) or it could be some private corporate VPN. Or it could even be some other silliness from some operator(s). I have seen such thing, but I am unsure I can talk freely about the details :-( I would definitely advise against marking unknown context as Internets. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
On Thursday 06 January 2011 02:12:01 ext Marcel Holtmann, you wrote: > > If such context is not found create a new one with "Internet" type. > > I don't really agree that we should create a context if no match is > found. I think the better sensible strategy is to hold this information > internally and only map it to a context once the user or provisioning > creates it. Indeed. Alternatively, we could have a dedicated type, e.g. "Unknown". Using the Internet type is only likely to confuse the connection manager. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, On 01/06/2011 11:45 AM, Sjur Brændeland wrote: > Hi Marcel and Denis. > >> I thought that we came to the conclusion that CID=0 is pretty much a >> really bad idea. So I would prefer that your modem is actually not using >> CID=0 ever. > Yea, I know you or Denis said so, but I'm not sure we understood your > concern... > The bottom line is that the network can ask for a context to be initiated at any time. Furthermore, any number of such contexts can be activated. You can't really treat LTE specially and CID=0 really doesn't help you anyway. e.g.: +CGEV: NW PDN ACT 1 ... +CGEV: NW PDN ACT 2 You need to allocate these cids properly. However, solving the cid allocation problem in the general case is basically impossible. The spec is just not setup to do so in its current form. e.g. ---> context1.SetActive(True); idmap_alloc(cid_map) -> cid == 1 [+CGDCONT=1,...] < +CGEV: ME PDN ACT 1 Bad things happen. The best you can do is allocate these cids from a different range than oFono. e.g.: AT+CGDCONT=? +CGDCONT: (0-25) ofono_gprs_set_cid_range(gprs, 12, 25) This way oFono will use the upper range for stack initiated contexts and you guys have the lower range to play in. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, > > I thought that we came to the conclusion that CID=0 is pretty much a > > really bad idea. So I would prefer that your modem is actually not using > > CID=0 ever. > Yea, I know you or Denis said so, but I'm not sure we understood your > concern... I really thought it became pretty much clear during the discussion that introducing a CID=0 that is just special on LTE is a pretty much bad idea. As long as CID=0 concept does not exist in GSM/UMTS, you should not make LTE a special case. It will not fit and just makes things utterly complex for the telephony stack to figure out when contexts are moved from LTE to GSM/UMTS. If CID=0 is not valid for GSM/UTMS then you are in big trouble to make this work properly. And if it is valid, then there is no difference between it being CID=0 or any other CID. So please step away from the CID=0 idea and just give the next free CID to the network activated context. And per specification the CID start with 1. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Marcel and Denis. > I thought that we came to the conclusion that CID=0 is pretty much a > really bad idea. So I would prefer that your modem is actually not using > CID=0 ever. Yea, I know you or Denis said so, but I'm not sure we understood your concern... Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, > > +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) > > +{ > > + idmap_take(gprs->cid_map, id); > > +} > > + > How do we assure that this CID is not already in use? > I think the M7400 is going to use CID=0 and M700 uses CID=1. > Perhaps we should make sure CID=0 is a legal value and reserve CID 0 > and 1 at start up. I thought that we came to the conclusion that CID=0 is pretty much a really bad idea. So I would prefer that your modem is actually not using CID=0 ever. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi, > From my understanding the ID in the core is an internal ID for oFono core, > even if today we usually have a mapping 1 to 1 between oFono core ID and > modems CID. > Denis, Marcel could you confirm ? Negative, to my understanding the CID is allocated in src/gprs.c and used when activating/deactivating PDP contexts (PDN Connections): static gboolean assign_context(struct pri_context *ctx) { ... ctx->context.cid = gprs_cid_alloc(ctx->gprs); static void ...gprs_activate_primary(struct ofono_gprs_context *gc, const struct ofono_gprs_primary_context *ctx, ofono_gprs_context_up_cb_t cb, void *data) { gcd->active_context = ctx->cid; > If we try to do something else oFono core will be modem dependent and it's > really not a good idea. It has been talk about standardizing the use of CID=0 for initial PDN.If this comes true this is no longer modem vendor dependent. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Redouane, On 01/06/2011 08:59 AM, Soum, RedouaneX wrote: > Hi Sjur, > > >>> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) >>> +{ >>> + idmap_take(gprs->cid_map, id); >>> +} >>> + >> How do we assure that this CID is not already in use? >> I think the M7400 is going to use CID=0 and M700 uses CID=1. >> Perhaps we should make sure CID=0 is a legal value and reserve CID 0 >> and 1 at start up. > > From my understanding the ID in the core is an internal ID for oFono core, > even if today we usually have a mapping 1 to 1 between oFono core ID and > modems CID. > Denis, Marcel could you confirm ? > Actually the intent was and still is to map it 1:1 to the modem cid to make life easier for the drivers. Since we follow 27.007 this makes sense. The modem driver can still do its own internal id mapping / management, e.g. isi drivers do this AFAIK. For AT modems I'd like to avoid doing so... oFono can be told the range of cids to use. There's nothing precluding the modem from giving oFono cids that are not in this range when a context is auto-activated. However, this gets into a real gray area whether you can have multiple (network|auto)-activated contexts and whether the cid picked for all of them is guaranteed to be outside this range. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, On 01/06/2011 06:02 AM, Sjur Brændeland wrote: > Hi Redouane, > ... >> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) >> +{ >> + idmap_take(gprs->cid_map, id); >> +} >> + > How do we assure that this CID is not already in use? > I think the M7400 is going to use CID=0 and M700 uses CID=1. > Perhaps we should make sure CID=0 is a legal value and reserve CID 0 > and 1 at start up. You already know how I feel about CID 0, I think you're trying to make it into something special when it really isn't. > > There is probably other ways of handling this as well, but I think any > other solution > would end up with race conditions, as context could be initiated from > two sources. The spec is essentially broken in this area. Barring a complete redesign of the spec (e.g. making the host stack activate the default context) reserving a particular range for such default contexts seems fine to me. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, > > +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) > > +{ > > + idmap_take(gprs->cid_map, id); > > +} > > + > How do we assure that this CID is not already in use? > I think the M7400 is going to use CID=0 and M700 uses CID=1. > Perhaps we should make sure CID=0 is a legal value and reserve CID 0 > and 1 at start up. From my understanding the ID in the core is an internal ID for oFono core, even if today we usually have a mapping 1 to 1 between oFono core ID and modems CID. Denis, Marcel could you confirm ? In this case the CID parameter in ofono_gprs_context_activated should be out parameter and renamed as ID. --- void ofono_gprs_context_activated(struct ofono_gprs_context *gc, int *id, const char *apn, const char *interface, ofono_bool_t static_ip, const char *address, const char *netmask, const char *gw, const char **dns) --- Also if we look to ofono_gprs_context_deactivated function the parameter used is ID and not CID, maybe it'll be beter if we rename cid in ofono_gprs_primary_context structure to avoid confusion : struct ofono_gprs_primary_context { unsigned int id; int direction; char apn[OFONO_GPRS_MAX_APN_LENGTH + 1]; char username[OFONO_GPRS_MAX_USERNAME_LENGTH + 1]; char password[OFONO_GPRS_MAX_PASSWORD_LENGTH + 1]; enum ofono_gprs_proto proto; }; If we try to do something else oFono core will be modem dependent and it's really not a good idea. Regards, - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH] gprs: add function to handle activated context
Hi Marcel, > > Behavior of the function : > > > > List all the context and try to find correct APN > > we have to be careful to only match against APN==APN and Username=="" + > Password=="". > > The username and password option is pretty much pointless, but it is > present and we do support it. So we need to make sure the APN matching > sensible. Or does the network provide us with additional information > about the username + password as well? Network doesn't provide login/password information, the UE shall provide it if needed. I'm not aware of any case where we can have network initiated connection with an APN usually used with authentication. If the connection requires a login/password then it's UE initiated procedure. If you think it's safer to check against Login/Password anyway, it's OK for me. > > > If such context is not found create a new one with "Internet" type. > > I don't really agree that we should create a context if no match is > found. I think the better sensible strategy is to hold this information > internally and only map it to a context once the user or provisioning > creates it. > > Also oFono will create at least one Internet context automatically. And > in the future that might be auto-provisioned. > > Another option would be to introduce the concept of temporary context > where the lifetime is mandated by the network. I agree with Denis, I think for now we can assume that it's either Internet or IMS (well-known APN). Later if we see operators doing something else we ll adapt. So I propose to keep this behavior for now, until we see a real need for something else. Regards, Redouane. - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Redouane, ... > +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) > +{ > + idmap_take(gprs->cid_map, id); > +} > + How do we assure that this CID is not already in use? I think the M7400 is going to use CID=0 and M700 uses CID=1. Perhaps we should make sure CID=0 is a legal value and reserve CID 0 and 1 at start up. There is probably other ways of handling this as well, but I think any other solution would end up with race conditions, as context could be initiated from two sources. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Marcel, > >> If such context is not found create a new one with "Internet" type. > > I don't really agree that we should create a context if no match is > found. I think the better sensible strategy is to hold this information > internally and only map it to a context once the user or provisioning > creates it. >From what I understood it should be quite safe to assume it is an internet context. All IMS contexts will have a well-known APN and the only other one that would make sense for the network to activate automatically would be the internet one. Perhaps this is the missing piece in the description? The fact that either the IMS or an Internet context is created. I also don't like the temporary approach, since if we roam off LTE we still need a way to deactivate this context. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Redouane, > gprs: add function to handle activated context > ofono_gprs_context_activated : this function is symetric to > ofono_gprs_context_deactivated. > This function must be call by any gprs-context driver when a context has been > activated without explicit request. > > Behavior of the function : > > List all the context and try to find correct APN we have to be careful to only match against APN==APN and Username=="" + Password=="". The username and password option is pretty much pointless, but it is present and we do support it. So we need to make sure the APN matching sensible. Or does the network provide us with additional information about the username + password as well? > If such context is not found create a new one with "Internet" type. I don't really agree that we should create a context if no match is found. I think the better sensible strategy is to hold this information internally and only map it to a context once the user or provisioning creates it. Also oFono will create at least one Internet context automatically. And in the future that might be auto-provisioned. Another option would be to introduce the concept of temporary context where the lifetime is mandated by the network. > For the context (found or created): > Update the settings > Set to active Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC PATCH] gprs: add function to handle activated context
gprs: add function to handle activated context ofono_gprs_context_activated : this function is symetric to ofono_gprs_context_deactivated. This function must be call by any gprs-context driver when a context has been activated without explicit request. Behavior of the function : List all the context and try to find correct APN If such context is not found create a new one with "Internet" type For the context (found or created): Update the settings Set to active --- include/gprs-context.h |6 +++ src/gprs.c | 105 2 files changed, 111 insertions(+), 0 deletions(-) diff --git a/include/gprs-context.h b/include/gprs-context.h index c29c0dc..57cd60b 100644 --- a/include/gprs-context.h +++ b/include/gprs-context.h @@ -76,6 +76,12 @@ struct ofono_gprs_context_driver { ofono_gprs_context_cb_t cb, void *data); }; +void ofono_gprs_context_activated(struct ofono_gprs_context *gc, + const int cid, const char *apn, + const char *interface, ofono_bool_t static_ip, + const char *address, const char *netmask, + const char *gw, const char **dns); + void ofono_gprs_context_deactivated(struct ofono_gprs_context *gc, unsigned int id); diff --git a/src/gprs.c b/src/gprs.c index 58166f8..b7a4768 100644 --- a/src/gprs.c +++ b/src/gprs.c @@ -212,6 +212,11 @@ static unsigned int gprs_cid_alloc(struct ofono_gprs *gprs) return idmap_alloc(gprs->cid_map); } +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id) +{ + idmap_take(gprs->cid_map, id); +} + static void gprs_cid_release(struct ofono_gprs *gprs, unsigned int id) { idmap_put(gprs->cid_map, id); @@ -1977,6 +1982,106 @@ void ofono_gprs_add_context(struct ofono_gprs *gprs, __ofono_atom_register(gc->atom, gprs_context_unregister); } +void ofono_gprs_context_activated(struct ofono_gprs_context *gc, + const int cid, const char *apn, + const char *interface, ofono_bool_t static_ip, + const char *address, const char *netmask, + const char *gw, const char **dns) +{ + DBusConnection *conn = ofono_dbus_get_connection(); + GSList *l; + dbus_bool_t value; + struct pri_context *context; + const char *path; + DBusMessage *signal; + GKeyFile *settings; + + if (gc->gprs == NULL) + return; + + for (l = gc->gprs->contexts; l; l = l->next) { + context = l->data; + + if (strcmp(context->context.apn, apn) == 0) + break; + } + + if (!l) { + context = add_context(gc->gprs, "Internet", + OFONO_GPRS_CONTEXT_TYPE_INTERNET); + + path = __ofono_atom_get_path(gc->gprs->atom); + signal = dbus_message_new_signal(path, + OFONO_CONNECTION_MANAGER_INTERFACE, + "ContextAdded"); + + if (signal) { + DBusMessageIter iter; + DBusMessageIter dict; + + dbus_message_iter_init_append(signal, &iter); + + path = context->path; + dbus_message_iter_append_basic(&iter, + DBUS_TYPE_OBJECT_PATH, + &path); + + dbus_message_iter_open_container(&iter, + DBUS_TYPE_ARRAY, + OFONO_PROPERTIES_ARRAY_SIGNATURE, + &dict); + + append_context_properties(context, &dict); + dbus_message_iter_close_container(&iter, &dict); + + g_dbus_send_message(conn, signal); + } + + strcpy(context->context.apn, apn); + settings = context->gprs->settings; + + if (settings) { + g_key_file_set_string(settings, context->key, + "AccessPointName", apn); + storage_sync(context->gprs->imsi, + SETTINGS_STORE, settings); + } + + ofono_dbus_signal_property_changed(conn, context->path, + OFONO_CONNECTION_CONTEXT_INTERFACE, + "AccessPointName", + DBUS_TYPE_STRING, &apn); + } + + gprs_cid_take(gc->gprs, cid); + context->context.cid = cid; + value = context->active = TRUE; + + if (interface != NULL) + pri_update_context_settings(context, interface, static_ip, +