[APN] giffgaff APNs don't have the proper 'mvno' fields

Some points:
" This means that a user's device when initially provisioned ends up with all five APNs."

Will this at least make it work for the user? Besides having extra APNs that are not needed.

"What should have happened is that we should've discussed the details of giffgaff's MVNO arrangement with O2 and added 'mvno_type' and 'mvno_data' based upon this information. If this had been done, then users with giffgaff SIMs would only get the giffgaff APNs provisioned."

Don't know how easy is to do that, but we can try, for sure.

"Furthermore, these new APNs were added to the end of the file, instead of being inserted inline with the other APNs that specify the same mcc/mnc."

This was on purpose, as it's then easier to merge back changes from AOSP (helps reducing the amount of conflicts).

"The change to apns-conf.xml was reviewed, but not actually tested..."

What would the test show up here? Would it at least connect to one of the APNs available in there?

Also, I also took this change because a similar one is also available in CyanogenMod:
<apn carrier="giffgaff" mcc="234" mnc="10" apn="giffgaff.com" user="giffgaff" password="password" mmsc="http://mmsc.mediamessaging.co.uk:8002" mmsproxy="82.132.254.1" mmsport="8080" type="default,supl,mms" />

This is a common issue on Android as well, and it all goes back to the point of being able to define or not the mvno_type/data.

In case this entry wasn't there, would just using the APN editor help reducing the amount of APNs selected? If so, I'd vote removing this from the database.

Changing to incomplete because it's not clear what is the side effect of having that entry in our database, and because we don't yet have the values for the mnvo fields (atm we can either leave it this way or remove it completely).

I think it is perfectly fine to add operators that use the same MCC/MNC code even if we cannot discriminate with the mvno_* fields. The list of APN choices will grow, but NetworkManager is supposed to handle that properly and eventually will get to the right one.

About the position in the file, although I understand that putting it at the end might resolve more easily conflicts, I think it is better to order by MCC/MNC, because that is the convention followed by all DBs. Note that when we merge operators from an updated DB, we might found that an operator we added at the end of the file might have already been added to the DB we are updating from, and in fact putting them in order would be the way to detect that and avoid duplicates. Besides, afaik we do not have a "master" upstream DB, instead we have merged from different DBs, so there will be always conflicts.

For the concrete case of giffgaff, I've found in my Moto G DB:

    <apn carrier="giffgaff"
         mcc="234"
         mnc="10"
         apn="giffgaff.com"
         authtype="1"
         user="giffgaff"
         password="password"
         mmsc="http://mmsc.mediamessaging.co.uk:8002"
         mmsproxy="193.113.200.195"
         mmsport="8080"
         mvno_type="spn"
         mvno_match_data="giffgaff"
         preloaded="true"
    />

We can take mvno_type and mvno_match_data from here.

However, this entry has a different MMS proxy to the one specified in http://community.giffgaff.com/t5/Settings-for-your-device/Internet-and-MMS-settings-APN-guide/ta-p/3489121#faq_no_6 . This is the problem with these DBs, none of them seem to be in a completely sane state :-/. After seeing that, can we trust the mvno_* values for giffgaff? Probably, but...

Another comment: it will be difficult to get somebody in an operator that can answer the question about how to detect if it is the owner of the SIM, unless the phone is sold directly by them.

One thing that should be pretty safe for MVNOs is to check the content of EF_SPN SIM file and set:

mvno_type="spn"
mvno_match_data="<content of EF_SPN>"

we can do that ourselves when we come across a non-supported SIM. Operators do not change the SIM profile often, and changing EF_SPN is probably never done unless there is a change in the operator name. The worst that can happen is that the users ends up having to use the APN editor.

On Thu, Mar 26, 2015 at 8:03 AM, Alfonso Sanchez-Beato
<email address hidden> wrote:
> I think it is perfectly fine to add operators that use the same MCC/MNC
> code even if we cannot discriminate with the mvno_* fields. The list of
> APN choices will grow, but NetworkManager is supposed to handle that
> properly and eventually will get to the right one.

Right.

> About the position in the file, although I understand that putting it at
> the end might resolve more easily conflicts, I think it is better to
> order by MCC/MNC, because that is the convention followed by all DBs.
> Note that when we merge operators from an updated DB, we might found
> that an operator we added at the end of the file might have already been
> added to the DB we are updating from, and in fact putting them in order
> would be the way to detect that and avoid duplicates. Besides, afaik we
> do not have a "master" upstream DB, instead we have merged from
> different DBs, so there will be always conflicts.

Our main database is actually from AOSP, with a few additions, but I
agree that it's better to have them all together, will change that.

The other question, should I also change adding the mvno_* values?

Alright, noticed AOSP had the same entry described by Alfonso here, so just did a pull request to get that in sync.

Please review https://code-review.phablet.ubuntu.com/#/c/361/

Would be nice if we could get someone to test this.

I think the right APN should be:

    <apn carrier="giffgaff"
         mcc="234"
         mnc="10"
         apn="giffgaff.com"
         authtype="1"
         user="giffgaff"
         password=""
         mmsc="http://mmsc.mediamessaging.co.uk:8002"
         mmsproxy="82.132.254.1"
         mmsport="8080"
         type="default,mms"
         mvno_type="spn"
         mvno_match_data="giffgaff"
    />

There are discrepancies between what we see in the DB and the settings provided by the operator (see link in comment #3):

* No password in the link
* Different MMS proxy

I have also added a line with the types supported by the APN. This is needed by our code, otherwise we won't use the entry. This behaviour is actually wrong, because in case there is no type the AOSP code considers the APN able to handle all types. I have opened bug #1437200 for ofono, but until that is fixed we need the type field.

I will ask joc to test this operator, I am pretty sure he has a giffgaff SIM.

@Ricardo, could you provide a link to that AOSP DB? I am confused, because the apns-conf.xml provided in the AOSP repos is really small, so I do not know which is our reference.

Finally, there is a

preloaded="true"

line in the giffgaff entry that I have no idea what is for. I have not seen any reference to it in the AOSP code. Qualcomm specific maybe?

Seems that the APN entry in comment #7 is fine, from joc's log:

Provisioning for MCC 234, MNC 10, SPN 'giffgaff',...

and he was able to start a data connection:

[ /ril_0/context1 ]
        Active = 1
        Name = giffgaff
        Type = internet
        MessageProxy = 82.132.254.1:8080
        Protocol = ip
        Username = giffgaff
        Settings = { DomainNameServers=82.132.254.2,82.132.254.3, Interface=ccmni0 Gateway=10.145.200.8 Netmask=255.255.255.0 Address=10.145.200.8 Method=static }
        AccessPointName = giffgaff.com
        MessageCenter = http://mmsc.mediamessaging.co.uk:8002
        Password =
        IPv6.Settings = { }

Change submitted to gerrit with the APN checked by joc:

https://code-review.phablet.ubuntu.com/#/c/362/

The AOSP apns file we used as reference: https://android.googlesource.com/device/sample/+/master/etc/apns-full-conf.xml

And as I talked on IRC, when updating the PR you can simply cherry-pick and push a new version (as long it has the same change-id, it will just create another patch revision).

Thanks for validating this with joc, will merge the change.

Adding the mvno_* fields is certainly recommended if possible, as I have seen instances where there were multiple APNs that were provisioned that could be used to provide a mobile data connection, but had differing MMS attributes, which left MMS broken if the wrong was activated by NM.

Also, it's interesting that APN mentioned in comment #3 works, as it specifies a 'Password', whereas the official settings from giffgaff specify that the password should be blank. See the related bug #1435776 which describes a NM regression in Vivid where APNs that specify a 'Username' without a corresponding 'Password' cause NM to throw a 'no-secrets' error and fail to be activated.

Changed both android tasks to FixCommited, as it's still not clear that this fix was released a new android package for the vivid overlay PPA or wily.

Testing Status visibility changes... please ignore.

Can we confirm if this has landed?

No, it hasn't landed in RTM due to bug #1481456.

That said, it did land in wily, so I've updated the Ubuntu task to FixReleased.