Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Jukka,
> Makefile.am |3 +
> examples/provision.c | 198
> ++
> 2 files changed, 201 insertions(+), 0 deletions(-)
> create mode 100644 examples/provision.c
>
> diff --git a/Makefile.am b/Makefile.am
> index 0f330a7..d57509d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -305,6 +305,9 @@ builtin_sources += examples/history.c
>
> builtin_modules += example_nettime
> builtin_sources += examples/nettime.c
> +
> +builtin_modules += example_gprs_provision
> +builtin_sources += examples/provision.c
> endif
I like to have these match. So just call it example_provision.
> +struct provisioning_request {
> + struct ofono_modem *modem;
> + ofono_gprs_provision_cb_t cb;
> + void *userdata;
Same as I mentioned in the other patch. Please use user_data.
> +};
> +
> +static void sim_spn_read_cb(int ok, int length, int record,
> + const unsigned char *data,
> + int record_length, void *userdata)
> +{
> + struct provisioning_request *req = userdata;
> + char *spn = NULL;
> +
> + struct ofono_atom *sim_atom;
> + struct ofono_sim *sim;
> + const char *imsi;
> +
> + unsigned char mnc_length;
> + char mcc[OFONO_MAX_MCC_LENGTH + 1];
> + char mnc[OFONO_MAX_MNC_LENGTH + 1];
> +
> + GSList *settings = NULL;
> + struct ofono_gprs_provisioning_data *entry;
> +
> + sim_atom = __ofono_modem_find_atom(req->modem, OFONO_ATOM_TYPE_SIM);
> +
> + if (sim_atom == NULL) {
> + ofono_debug("No SIM atom");
> + goto finish;
> + }
> +
> + sim = __ofono_atom_get_data(sim_atom);
> + imsi = ofono_sim_get_imsi(sim);
> + if (imsi == NULL) {
> + ofono_debug("No IMSI available");
> + goto finish;
> + }
> +
> + mnc_length = ofono_sim_get_mnc_length(sim);
> + if (mnc_length == 0) {
> + ofono_debug("No MNC length available");
> + goto finish;
> + }
> +
> + strncpy(mcc, imsi, OFONO_MAX_MCC_LENGTH);
> + mcc[OFONO_MAX_MCC_LENGTH] = '\0';
> + strncpy(mnc, imsi + OFONO_MAX_MCC_LENGTH, mnc_length);
> + mnc[mnc_length] = '\0';
> +
> + if (ok)
> + spn = sim_string_to_utf8(data + 1, length - 1);
> +
> + ofono_debug("Finding settings for MCC %s, MNC %s, SPN '%s'",
> + mcc, mnc, spn);
> +
> + if (spn == NULL || strcmp(spn, "oFono") != 0)
> + goto finish;
I think we need to also take some MCC and MNC into account. People will
be by accident compiling this plugin and I wanna make sure nothing bad
gets provisioned ;)
> +static void example_gprs_provision_get_settings(
> + struct ofono_modem *modem,
> + ofono_gprs_provision_cb_t cb,
> + void *userdata)
> +{
> + struct provisioning_request *req;
> + struct ofono_atom *sim_atom;
> + struct ofono_sim *sim = NULL;
> +
> + ofono_debug("Provisioning...");
> +
> + req = g_try_new0(struct provisioning_request, 1);
> + if (req == NULL)
> + goto error;
> +
> + req->modem = modem;
> + req->cb = cb;
> + req->userdata = userdata;
> +
> + /* Start SPN query from SIM */
> + sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
> +
> + if (sim_atom != NULL)
> + sim = __ofono_atom_get_data(sim_atom);
> +
> + if (sim != NULL) {
> + ofono_sim_read(sim, SIM_EFSPN_FILEID,
> + OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
> + sim_spn_read_cb, req);
> + return;
> + }
Should this not be provided somehow by the SIM atom?
Denis, any idea why we are not keeping this information available?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hello
On Tue, 2011-01-11 at 22:48 -0800, ext Marcel Holtmann wrote:
> > + if (sim != NULL) {
> > + ofono_sim_read(sim, SIM_EFSPN_FILEID,
> > + OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
> > + sim_spn_read_cb, req);
> > + return;
> > + }
>
> Should this not be provided somehow by the SIM atom?
>
> Denis, any idea why we are not keeping this information available?
>
I would guess there was no need for it, since netreg was the only user
for EFSPN data.
I though of patching the SIM atom to read this during some phase of SIM
initialization, but was not sure exactly when, and what kind of
interface (syncronous, asyncronous?) to provide.
--Jukka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Jukka,
On 01/12/2011 01:41 AM, Jukka Saunamaki wrote:
> Hello
>
> On Tue, 2011-01-11 at 22:48 -0800, ext Marcel Holtmann wrote:
>>> + if (sim != NULL) {
>>> + ofono_sim_read(sim, SIM_EFSPN_FILEID,
>>> + OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
>>> + sim_spn_read_cb, req);
>>> + return;
>>> + }
>>
>> Should this not be provided somehow by the SIM atom?
>>
>> Denis, any idea why we are not keeping this information available?
>>
>
> I would guess there was no need for it, since netreg was the only user
> for EFSPN data.
>
> I though of patching the SIM atom to read this during some phase of SIM
> initialization, but was not sure exactly when, and what kind of
> interface (syncronous, asyncronous?) to provide.
>
You're correct that netreg is the only consumer. There was no need for
anyone else to see this information. However, this begs the question,
why do you need the SPN data?
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hello On Wed, 2011-01-12 at 10:46 -0600, Denis Kenzior wrote: > > ...SIM EF-SPN... > > You're correct that netreg is the only consumer. There was no need for > anyone else to see this information. However, this begs the question, > why do you need the SPN data? Some virtual operators are using the same MCC/MNC as their host, or some operators have several different trade names, and these can have different access settings (at least different UI visible name). SPN in SIM typically tells these cases apart. This is why I included reading SPN to that example provisioning. All provisioning plugins might not care about SPN (e.g. the previously discussed one using mobile-broadband-provider-info?), so I would suggest not creating specific SIM API yet. Of cause it can be added later, if so wished. --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Jukka, On 01/13/2011 12:36 AM, Jukka Saunamaki wrote: > Hello > > On Wed, 2011-01-12 at 10:46 -0600, Denis Kenzior wrote: >>> ...SIM EF-SPN... >> >> You're correct that netreg is the only consumer. There was no need for >> anyone else to see this information. However, this begs the question, >> why do you need the SPN data? > > Some virtual operators are using the same MCC/MNC as their host, or some > operators have several different trade names, and these can have > different access settings (at least different UI visible name). > SPN in SIM typically tells these cases apart. This is why I included > reading SPN to that example provisioning. Do you have specific examples? To my knowledge the MVNOs should be provisioning the SIM with a different MNC from the host but the network used (and thus the network's MCC/MNC) are their host's. > > All provisioning plugins might not care about SPN (e.g. the previously > discussed one using mobile-broadband-provider-info?), so I would suggest > not creating specific SIM API yet. Of cause it can be added later, if so > wished. You might be able to get away with reading of EFspn just because it is cached nicely on disk. But you will have to carefully consider your plugin design if you wish to do so to avoid any race conditions and be able to properly clean up. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hello Denis, On Thu, 2011-01-13 at 09:57 -0600, Denis Kenzior wrote: > > Some virtual operators are using the same MCC/MNC as their host, or some > > operators have several different trade names, and these can have > > different access settings (at least different UI visible name). > > SPN in SIM typically tells these cases apart. This is why I included > > reading SPN to that example provisioning. > > Do you have specific examples? To my knowledge the MVNOs should be > provisioning the SIM with a different MNC from the host but the network > used (and thus the network's MCC/MNC) are their host's. I was not sure if all MVNOs have their own MNC, but in any case some operators use different trade names. Off the top of my hat I know our local Finnish operators Elisa and Sonera use trade names like Kolumbus and TeleFinland, and their name shown in UI needs to be correct. > > All provisioning plugins might not care about SPN (e.g. the previously > > discussed one using mobile-broadband-provider-info?), so I would suggest > > not creating specific SIM API yet. Of cause it can be added later, if so > > wished. > > You might be able to get away with reading of EFspn just because it is > cached nicely on disk. But you will have to carefully consider your > plugin design if you wish to do so to avoid any race conditions and be > able to properly clean up. You mean that if plugin gets removed/unregistered before SPN-reading callback comes in? That is a good point, and I also have to check how to handle this in GPRS atom, since calling provisioning is asynchronous, and GPRS might get removed while provisioning is running... I might need some help figuring out solution to that. Alternative is of cause to make provisioning synchronous, but that would limit what plugin can do (like asking SPN with ofono_sim_read()) --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
On Friday 14 January 2011 08:53:03 ext Jukka Saunamaki, you wrote: > Alternative is of cause to make provisioning synchronous, but that would > limit what plugin can do (like asking SPN with ofono_sim_read()) Just because the plugin would be synchronous won't magically fix the "physical" race conditions. The user can still take the SIM out, and the network can still fail. -- 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 4/4] Dummy example GPRS context provisioning driver
Hi Jukka, > > > Some virtual operators are using the same MCC/MNC as their host, or some > > > operators have several different trade names, and these can have > > > different access settings (at least different UI visible name). > > > SPN in SIM typically tells these cases apart. This is why I included > > > reading SPN to that example provisioning. > > > > Do you have specific examples? To my knowledge the MVNOs should be > > provisioning the SIM with a different MNC from the host but the network > > used (and thus the network's MCC/MNC) are their host's. > > I was not sure if all MVNOs have their own MNC, but in any case some > operators use different trade names. Off the top of my hat I know our > local Finnish operators Elisa and Sonera use trade names like Kolumbus > and TeleFinland, and their name shown in UI needs to be correct. what does the name showing in the UI has to do with the provision data for the GPRS contexts? I am missing your point here. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi , > > I was not sure if all MVNOs have their own MNC, but in any case some > > operators use different trade names. Off the top of my hat I know our > > local Finnish operators Elisa and Sonera use trade names like Kolumbus > > and TeleFinland, and their name shown in UI needs to be correct. > > what does the name showing in the UI has to do with the provision data > for the GPRS contexts? I am missing your point here. Isn't the 'name' property of a context shown in some UI (when user selects connection to open)? And there might be cases where other context settings like APN is different with different trade names. --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Jukka, > > > I was not sure if all MVNOs have their own MNC, but in any case some > > > operators use different trade names. Off the top of my hat I know our > > > local Finnish operators Elisa and Sonera use trade names like Kolumbus > > > and TeleFinland, and their name shown in UI needs to be correct. > > > > what does the name showing in the UI has to do with the provision data > > for the GPRS contexts? I am missing your point here. > > Isn't the 'name' property of a context shown in some UI (when user > selects connection to open)? so you wanna use the SPN to set the nice friendly name of the Context. So far we just defaulted to "Internet" and "MMS" and did not bother any further. For example ConnMan actually takes that information from the network registration and not from the context. > And there might be cases where other context settings like APN is > different with different trade names. Is that really the case? Can this be used reliably? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi On Fri, 2011-01-14 at 14:44 +0100, ext Marcel Holtmann wrote: > Hi Jukka, > > > > > I was not sure if all MVNOs have their own MNC, but in any case some > > > > operators use different trade names. Off the top of my hat I know our > > > > local Finnish operators Elisa and Sonera use trade names like Kolumbus > > > > and TeleFinland, and their name shown in UI needs to be correct. > > > > > > what does the name showing in the UI has to do with the provision data > > > for the GPRS contexts? I am missing your point here. > > > > Isn't the 'name' property of a context shown in some UI (when user > > selects connection to open)? > > so you wanna use the SPN to set the nice friendly name of the Context. > So far we just defaulted to "Internet" and "MMS" and did not bother any > further. Yes, that is how our previous UIs have done it, and I guess our UX designers like it in the future too. > For example ConnMan actually takes that information from the network > registration and not from the context. > > > And there might be cases where other context settings like APN is > > different with different trade names. > > Is that really the case? Can this be used reliably? Quick look at our operator database does indeed confirm that, there are cases where different SPN maps to different APN. --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Jukka, > > > > > I was not sure if all MVNOs have their own MNC, but in any case some > > > > > operators use different trade names. Off the top of my hat I know our > > > > > local Finnish operators Elisa and Sonera use trade names like Kolumbus > > > > > and TeleFinland, and their name shown in UI needs to be correct. > > > > > > > > what does the name showing in the UI has to do with the provision data > > > > for the GPRS contexts? I am missing your point here. > > > > > > Isn't the 'name' property of a context shown in some UI (when user > > > selects connection to open)? > > > > so you wanna use the SPN to set the nice friendly name of the Context. > > So far we just defaulted to "Internet" and "MMS" and did not bother any > > further. > > Yes, that is how our previous UIs have done it, and I guess our UX > designers like it in the future too. I would advise the UI against using the name from the context information and better using the one from the network registration instead. The context gets only provisioned once. So any update of the network name can not be reflected later on by provisioning. It would have to be a manual step. And operators are known to changing their names. When using network registration this would just work fine. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
On Friday 14 January 2011 16:10:27 ext Marcel Holtmann, you wrote: > > Yes, that is how our previous UIs have done it, and I guess our UX > > designers like it in the future too. > > I would advise the UI against using the name from the context > information and better using the one from the network registration > instead. Well that would make sense... Therefore the operators don't do it ;-) For instance my provider shows as "Elisa" in the network registration but the access points are expected to be shown as "Elisa Internet" and "Elisa MMS WAP" if I recall correctly. It only makes sense to have this data in the provisioning plugin. It would be silly to have to provision just the names in a different component. -- 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 4/4] Dummy example GPRS context provisioning driver
Hi Jukka, On 01/14/2011 12:53 AM, Jukka Saunamaki wrote: > Hello Denis, > > On Thu, 2011-01-13 at 09:57 -0600, Denis Kenzior wrote: >>> Some virtual operators are using the same MCC/MNC as their host, or some >>> operators have several different trade names, and these can have >>> different access settings (at least different UI visible name). >>> SPN in SIM typically tells these cases apart. This is why I included >>> reading SPN to that example provisioning. >> >> Do you have specific examples? To my knowledge the MVNOs should be >> provisioning the SIM with a different MNC from the host but the network >> used (and thus the network's MCC/MNC) are their host's. > > I was not sure if all MVNOs have their own MNC, but in any case some > operators use different trade names. Off the top of my hat I know our > local Finnish operators Elisa and Sonera use trade names like Kolumbus > and TeleFinland, and their name shown in UI needs to be correct. > Being shown on the UI is a bit different from needing this information to provision. oFono already takes care of reading EFspn in the netreg atom and figuring out the proper display name. If you can rely on just the MCC/MNC of the SIM/IMSI for provisioning information, that would greatly simplify your database and your plugin implementation. So I suggest you double check the need of EFspn first. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hi Remi, > > > Yes, that is how our previous UIs have done it, and I guess our UX > > > designers like it in the future too. > > > > I would advise the UI against using the name from the context > > information and better using the one from the network registration > > instead. > > Well that would make sense... Therefore the operators don't do it ;-) > > For instance my provider shows as "Elisa" in the network registration but the > access points are expected to be shown as "Elisa Internet" and "Elisa MMS > WAP" > if I recall correctly. > > It only makes sense to have this data in the provisioning plugin. It would be > silly to have to provision just the names in a different component. just to make this clear, oFono takes care of potential operator renames and displays them accordingly, but the provision names would stay the same. So if Elisa renames themselves into "Gwendula", the context names would still say "Elisa Internet" etc. Has anybody thought about this part? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 4/4] Dummy example GPRS context provisioning driver
Hello On Sat, 2011-01-15 at 02:30 +0100, Marcel Holtmann wrote: > > > I would advise the UI against using the name from the context > > > information and better using the one from the network registration > > > instead. > > > > Well that would make sense... Therefore the operators don't do it ;-) > > > > For instance my provider shows as "Elisa" in the network registration but > > the > > access points are expected to be shown as "Elisa Internet" and "Elisa MMS > > WAP" > > if I recall correctly. > > > > It only makes sense to have this data in the provisioning plugin. It would > > be > > silly to have to provision just the names in a different component. > > just to make this clear, oFono takes care of potential operator renames > and displays them accordingly, but the provision names would stay the > same. > > So if Elisa renames themselves into "Gwendula", the context names would > still say "Elisa Internet" etc. Has anybody thought about this part? Well, there is always OMA Client Provisioning for that purpose. However, I would leave this question to UX designers and someone that actually knows operator requirements regarding which name (network provided or provisioning/gprs-context name) to show for Internet access selection. Also, by the way, when roaming, network name is different from normal home name, and this may or may not be desirable for internet access name... In any case, regarding the original issue if reading SPN is really needed for provisioning, the answer is still yes. There are cases where different SPN means different gprs context settings (other than 'Name' too). --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
