Ubuntu
ofono package

  1. Bug #1324157
  2. Comment #1

Comment 1 for bug 1324157

Revision history for this message
Tony Espy (awe) wrote :

The cause of this bug is that our current GPRS/MMS provisioning strategy is over-ambitious in that it attempts to provision from both mobile-broadband-provider-info ( /usr/share/mobile-broadband-provider/serviceproviders.xml ) and apns-conf.xml ( located in /system/etc, and part of our android package ).

A couple of points...

1. Our provisioning plugin is part of the Ubuntu ofono package. It's called android-provision, it's source code can be found here:

https://github.com/rilmodem/ofono/blob/master/plugins/android-provision.c

It first queries apns-conf, then queries mbpi and will only add results from mbpi if their no collision with an already added APN from apns-conf that has the same value for "apn".

2. The second point is that provisioning works by grabbing all of the APNs that match a particular set of criteria pulled from the SIM card ( mobile-country-code, mobile-network-code, servic-provider-name, ... ). It's then NetworkManager's responsibility to try each in sequence and when it finds one that works, mark that APN/connection with a "last-connected-time".

3. Some operators define stand-alone APNs for MMS usage. These APNs are not affected by this problem. Unfortunately AT&T uses the mixed context type.

4. With our current logic, it's possible that more than one context is provisioned that is valid for Internet/GPRS usage by a particular subscriber. In your case, both "ATT Phone" and "Laptop Connect (data cards)" are valid. If "ATT Phone" had been the context activated, everything would have worked, but in this case NM chose "Laptop Connect (data cards)" which doesn't support MMS, so this is why MMS doesn't work.

5. The mbpi APN was used for one of two reasons.... a) there used to be a bug in NM where it didn't walk thru the APNs in sequence or b) NM tried to activate "ATT Phone", failed, and thus moved on to "Laptop Connect (data cards)". My guess is that the latter happened, but without the syslog, it's hard to tell. My guess though is that it's case (b), as I'm pretty sure (a) was fixed before image #51 was released.