GNOME Bugzilla – Bug 729665
[PATCH] Allow blank APN for GSM connections
Last modified: 2015-02-25 14:09:02 UTC
We have users in the field who don't know the correct APN for their mobile broadband device; they are expected to use the preprogrammed details in the dongle, which are controlled by central IT. Looking the APN up in a centralised database won't work for this use case - you need some way of knowing that "this dongle has been programmed by the customer to the customer-specific APN, and should not use the standard carrier APN, but should use the customer APN". There's not enough information available in the public sphere to handle this - the dongles and SIMs are (in at least one case) standard Vodafone UK supply, so cannot be distinguished from a normal Vodafone dongle, and the end user is not given the APN (as it changes charging rules - so if they had the APN details, the company could be made to pay for their personal data use). In older versions of NetworkManager, you could just omit the APN, and it would work fine; ModemManager still supports this (set APN to ""), but NetworkManager no longer supports it. The attached patch is a fix for this issue, in case my description of it isn't clear.
Created attachment 276011 [details] [review] Revert the behaviour change so that APN is optional again
Acked-by: Thomas Haller <thaller@redhat.com>
So there's quite a few issues to think about here. When you set the APN to "", that is the "default subscription APN". This must be supported by the operator, and many do not support it. If unsupported, the connection will simply fail without much error information, because we currently cannot easily detect whether the device/operator supports the default APN or not. Also, while your home network might support the default APN, a roaming operator might not support it. Second, the WWAN device must support a blank APN, and while many newer ones do, this is highly firmware and device dependent. Many older devices do not support it. Third, whatever default APN might be chosen by the device/operator may not actually be the APN you want to use, which could end up causing billing issues for the customer, especially if roaming. We moved to requiring an APN with more recent versions of NetworkManager, because many users would simply not enter an APN, and this caused quite a few bug reports where the connection completely failed, but entering the correct APN made them work (for obvious reasons). ---- So with that all said, I completely understand where you're coming from, and I wish all this could be "plug and play" right from the start, like CDMA is/was. The question is how to go about doing that, ensuring that the default APN can be used in some cases, and that users who cannot use the default APN due to lack of device or operator support don't get hit with errors when they forget to configure it (which used to happen a lot). If we could get better error information from the device -> ModemManager -> NetworkManager then I'd be much more inclined to just allow a blank APN. One thing you could help with there is to record (using ModemManager debug logs) what the modem error codes are for wrong APN, and if you have any older devices, what the error codes would be for a missing APN if they don't support the blank/default APN. That could be coupled with UI improvements to ask "hey, do you really want to leave the APN blank?" somewhat like we have for leaving the CA certificate blank. What do you think?
I have never encountered a situation where a blank APN does not work - every device I've ever had access to handles a blank APN just fine (oldest is from 2008). From my perspective, I'm trying to move from NM 0.8.1 to 0.9.9 on an embedded device, and finding that it regresses badly, breaking my setup. I have custom code driving NM, rather than one of the standard desktop UIs, so things don't quite work the way you're thinking (configuration is ahead-of-time, ready for the dongle to be plugged in, for a start, and errors from NM are handled purely by my code, no user interaction possible). I'm also not sure how to record the error codes you're on about. ModemManager is a bit of an underdocumented black box to me - it just appears when NetworkManager tries to use mobile broadband dongles, and logs to its own black hole somewhere. From my perspective, I want to be able to tell NetworkManager that I know there's no APN, but try it anyway - ModemManager can handle this, after all, and NetworkManager used to be just fine with this. I don't mind having to change my code to cope with this (e.g. to be explicit about not having an APN), but I do mind not being able to do this, when I have deployed units in the field where I cannot get the APN setting added after the fact.
So default subscription APN functionality appears to be operator dependent, not UE (device) dependent, at least for most recent devices as you've found. I tested a representative sample of devices from 2007 to 2013 and found they all support passing "" as the APN. It appears that both my operators now support this functionality, where in the past they did not. So I'm unable to test failure cases where the operator does not support the default subscription APN. Recent standards have defined new CME error codes (127) for "missing or invalid APN", which we could use in the future to provide better error messages to those users who's operator does not support this functionality. I also fixed one bug in ModemManager that caused assertions when attempting to start a data connection with QMI-based devices and no APN. --- So ACK on this patch. For the user interface side of things (which you probably don't care about much) we should implement a dropdown menu that has the following options: APN: [ Automatic ] [ <manually entered APN> ] [ Change APN... ] <manually entered APN> woudl contain whatever was previously selected from "Change APN...". "Change APN..." would run the current mobile broadband wizard to let the user find their APN, or enter it manually. Upon completion of the wizard, the APN value would be put into <manually entered APN>.
We'll also to update the corresponding nm-modem-old.c code, but don't worry about that, I've already done that locally.
(In reply to comment #5) > So default subscription APN functionality appears to be operator dependent, not > UE (device) dependent, at least for most recent devices as you've found. I > tested a representative sample of devices from 2007 to 2013 and found they all > support passing "" as the APN. > As usual, 3GPP isn't clear on how you choose a default APN. It appears from TS 23.060 V9.6.0 in table 5, section 13.1 that default APN comes from the HSS (what was the HLR in 2G systems), so it's tied to the SIM, not the UE or the network, but there's also hints that the default APN can be provided by the UE as well in UMTS-only networks (before E-UTRAN support). <snip> > > For the user interface side of things (which you probably don't care about > much) we should implement a dropdown menu that has the following options: > > APN: [ Automatic ] > [ <manually entered APN> ] > [ Change APN... ] > > <manually entered APN> woudl contain whatever was previously selected from > "Change APN...". "Change APN..." would run the current mobile broadband wizard > to let the user find their APN, or enter it manually. Upon completion of the > wizard, the APN value would be put into <manually entered APN>. FWIW, our UI is simple - it's two radio buttons and a text entry field: * No Access Point Name (APN) required: * Access Point Name (APN): [ ] By and large, our users seem to understand that because they've got to make the choice, there's a chance that it's wrong.
By the way: "The goal is to use the preprogrammed APNs in consumer dongles, rather than adding an appropriate one; we have users who have custom APNs programmed in, specifically for their application, so a database of default APNs is not applicable." This actually still won't be true after this patch, because the pre-programmed APNs are not used with the "default APN" functionality (where the UE is handed a blank APN). When given a blank APN, ModemManager will actually create a new PDP context without any APN at all, which is what triggers the network-side default APN behavior.
Created attachment 276178 [details] [review] 0001-wwan-allow-completing-new-GSM-connections-without-an.patch I've updated the commit description a bit to identify that this behavior only affects creating and completing new connections. Also, I removed the bits setting the apn to "" when sending to ModemManager, which aren't required. I also added the necessary bits for ModemManager 0.6. Does this look correct to you?
Created attachment 276179 [details] [review] 0001-editor-better-handling-of-default-APNs-bgo-729665.patch Implement better default APN behavior in nm-connection-editor.
(In reply to comment #8) > By the way: > > "The goal is to use the preprogrammed APNs in consumer dongles, rather than > adding an appropriate one; we have users who have custom APNs programmed in, > specifically for their application, so a database of default APNs is not > applicable." > > This actually still won't be true after this patch, because the pre-programmed > APNs are not used with the "default APN" functionality (where the UE is handed > a blank APN). When given a blank APN, ModemManager will actually create a new > PDP context without any APN at all, which is what triggers the network-side > default APN behavior. This is, however, what happened in 0.8.1, and our users were happy with this behaviour - they got iffy about giving out the APN, but using a blank APN got the right one. Might not be happening for the reasons the user thought it did, but it did work.
(In reply to comment #9) > Created an attachment (id=276178) [details] [review] > 0001-wwan-allow-completing-new-GSM-connections-without-an.patch > > I've updated the commit description a bit to identify that this behavior only > affects creating and completing new connections. > > Also, I removed the bits setting the apn to "" when sending to ModemManager, > which aren't required. > > I also added the necessary bits for ModemManager 0.6. > > Does this look correct to you? Looks right to me - as long as you've compiled tested it (that's all I can really do with git master right now), I'm happy to have my name put to it.
(In reply to comment #11) > (In reply to comment #8) > > By the way: > > > > "The goal is to use the preprogrammed APNs in consumer dongles, rather than > > adding an appropriate one; we have users who have custom APNs programmed in, > > specifically for their application, so a database of default APNs is not > > applicable." > > > > This actually still won't be true after this patch, because the pre-programmed > > APNs are not used with the "default APN" functionality (where the UE is handed > > a blank APN). When given a blank APN, ModemManager will actually create a new > > PDP context without any APN at all, which is what triggers the network-side > > default APN behavior. > > This is, however, what happened in 0.8.1, and our users were happy with this > behaviour - they got iffy about giving out the APN, but using a blank APN got > the right one. Were you using the default dialing number (*99#) and leaving the APN blank?
(In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #8) > > > By the way: > > > > > > "The goal is to use the preprogrammed APNs in consumer dongles, rather than > > > adding an appropriate one; we have users who have custom APNs programmed in, > > > specifically for their application, so a database of default APNs is not > > > applicable." > > > > > > This actually still won't be true after this patch, because the pre-programmed > > > APNs are not used with the "default APN" functionality (where the UE is handed > > > a blank APN). When given a blank APN, ModemManager will actually create a new > > > PDP context without any APN at all, which is what triggers the network-side > > > default APN behavior. > > > > This is, however, what happened in 0.8.1, and our users were happy with this > > behaviour - they got iffy about giving out the APN, but using a blank APN got > > the right one. > > Were you using the default dialing number (*99#) and leaving the APN blank? Exactly that, yes. The predecessor of NetworkManager in our product (a pile of shell and Python scripts) did ATDT*99# to get the PPP session up, and we kept that behaviour when we ported to NM 0.7 and 0.8.
(In reply to comment #9) > Created an attachment (id=276178) [details] [review] > 0001-wwan-allow-completing-new-GSM-connections-without-an.patch > > I've updated the commit description a bit to identify that this behavior only > affects creating and completing new connections. > > Also, I removed the bits setting the apn to "" when sending to ModemManager, > which aren't required. > > I also added the necessary bits for ModemManager 0.6. > > Does this look correct to you? Just tested this, and it doesn't work - ModemManager requires an APN of "" to work.
(In reply to comment #15) > (In reply to comment #9) > > Created an attachment (id=276178) [details] [review] [details] [review] > > 0001-wwan-allow-completing-new-GSM-connections-without-an.patch > > > > I've updated the commit description a bit to identify that this behavior only > > affects creating and completing new connections. > > > > Also, I removed the bits setting the apn to "" when sending to ModemManager, > > which aren't required. > > > > I also added the necessary bits for ModemManager 0.6. > > > > Does this look correct to you? > > Just tested this, and it doesn't work - ModemManager requires an APN of "" to > work. Which version of ModemManager do you have, and could you grab its debug logs for me?
I'm deep-diving now - there are other issues stopping dongles working at all. I have: ModemManager-glib-1.1.0-2.git20130913.fc20.x86_64 ModemManager-1.1.0-2.git20130913.fc20.x86_64 If I don't set the APN to "", I get: May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) starting connection '3G GSM' May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect started... May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (4/8): Wait to get fully enabled May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (5/8): Register May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (6/8): Bearer May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (7/8): Connect May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> registered) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2) modem state changed, 'registered' --> 'connecting' (reason: user-requested) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2) modem state changed, 'connecting' --> 'registered' (reason: user-requested) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <warn> (ttyUSB2) failed to connect modem: 3GPP connection logic requires APN setting May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): device state change: prepare -> failed (reason 'unknown') [40 120 1] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <warn> Activation (ttyUSB2) failed for connection '3G GSM' May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): device state change: failed -> disconnected (reason 'none') [120 30 0] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): deactivating device (reason 'none') [0] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) starting connection '3G GSM' May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): device state change: disconnected -> prepare (reason 'none') [30 40 0] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect started... May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (4/8): Wait to get fully enabled May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (5/8): Register May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (6/8): Bearer May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Simple connect state (7/8): Connect May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) May 09 11:22:27 localhost.localdomain ModemManager[634]: <info> Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> registered) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2) modem state changed, 'registered' --> 'connecting' (reason: user-requested) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2) modem state changed, 'connecting' --> 'registered' (reason: user-requested) May 09 11:22:27 localhost.localdomain NetworkManager[529]: <warn> (ttyUSB2) failed to connect modem: 3GPP connection logic requires APN setting May 09 11:22:27 localhost.localdomain NetworkManager[529]: <info> (ttyUSB2): device state change: prepare -> failed (reason 'unknown') [40 120 1] May 09 11:22:27 localhost.localdomain NetworkManager[529]: <warn> Activation (ttyUSB2) failed for connection '3G GSM' However, I'm also failing to connect if I set a valid APN - more digging required to see what's going on - clearly, the "3GPP connection logic requires APN setting" message is misleading in this context.
Dug deeper. The valid APN I was setting was wrong for my SIM; when I used the correct APN, it worked. So, remaining question for me is why it requires an APN when using NM 0.9.9, but not in 0.8.1.
Got it. This is messy, and I need guidance. My device has a PDP context with no APN: May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.357012] [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): --> 'AT+CGDCONT?<CR>' May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370196] [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): <-- '<CR><LF>+CGDCONT: 1,"IP","internet","",0,0<CR><LF>+CGDCONT: 2,"IP","wap.vodafone.co.uk","",0,0<CR><LF>+CGDCONT: 3,"IP","pp.vodafone.co.uk","",0,0<CR><LF>+CGDCONT: 4,"IP","","",0,0<CR><LF><CR><LF>OK<CR><LF>' May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370346] [mm-broadband-bearer.c:937] parse_pdp_list(): Found '4' PDP contexts May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370363] [mm-broadband-bearer.c:946] parse_pdp_list(): PDP context [cid=1] [type='ipv4'] [apn='internet'] May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370373] [mm-broadband-bearer.c:946] parse_pdp_list(): PDP context [cid=2] [type='ipv4'] [apn='wap.vodafone.co.uk'] May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370381] [mm-broadband-bearer.c:946] parse_pdp_list(): PDP context [cid=3] [type='ipv4'] [apn='pp.vodafone.co.uk'] May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370390] [mm-broadband-bearer.c:946] parse_pdp_list(): PDP context [cid=4] [type='ipv4'] [apn=''] May 12 17:35:48 localhost.localdomain ModemManager[623]: <debug> [1399912548.370399] [mm-broadband-bearer.c:958] parse_pdp_list(): Found PDP context with CID 4 and no APN This triggers ModemManager into dialling *99***4#, despite me setting gsm.number to *99#. On my older system, ModemManager 0.6 dials *99# as required for this setup. Thoughts?
Just confirmed - if I don't turn NetworkManager "no APN" into ModemManager "blank APN", I don't even get that far: May 12 18:04:56 localhost.localdomain ModemManager[623]: <info> [1399914296.142488] [mm-iface-modem-simple.c:583] connection_step(): Simple connect state (7/8): Connect May 12 18:04:56 localhost.localdomain ModemManager[623]: <debug> [1399914296.142953] [mm-bearer.c:586] mm_bearer_connect(): Connecting bearer '/org/freedesktop/ModemManager1/Bearer/4' May 12 18:04:56 localhost.localdomain ModemManager[623]: <info> [1399914296.143456] [mm-iface-modem.c:1203] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/3: state changed (registered -> connecting) May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> (ttyUSB2) modem state changed, 'registered' --> 'connecting' (reason: user-requested) May 12 18:04:56 localhost.localdomain ModemManager[623]: <debug> [1399914296.145192] [mm-bearer.c:461] connect_ready(): Couldn't connect bearer '/org/freedesktop/ModemManager1/Bearer/4': '3GPP connection logic requires APN setting' May 12 18:04:56 localhost.localdomain ModemManager[623]: <info> [1399914296.145249] [mm-iface-modem.c:1203] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/3: state changed (connecting -> registered) May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> (ttyUSB2) modem state changed, 'connecting' --> 'registered' (reason: user-requested) May 12 18:04:56 localhost.localdomain ModemManager[623]: <debug> [1399914296.146524] [mm-iface-modem-simple.c:221] connect_bearer_ready(): Couldn't connect bearer: '3GPP connection logic requires APN setting' May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <warn> (ttyUSB2) failed to connect modem: 3GPP connection logic requires APN setting May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> (ttyUSB2): device state change: prepare -> failed (reason 'unknown') [40 120 1] May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> NetworkManager state is now DISCONNECTED May 12 18:04:56 localhost.localdomain ModemManager[623]: <debug> [1399914296.147282] [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): --> 'AT+CIND?<CR>' May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <warn> Activation (ttyUSB2) failed for connection '3G GSM' May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> (ttyUSB2): device state change: failed -> disconnected (reason 'none') [120 30 0] May 12 18:04:56 localhost.localdomain NetworkManager[2080]: <info> (ttyUSB2): deactivating device (reason 'none') [0] May 12 18:04:56 localhost.localdomain ModemManager[623]: <debug> [1399914296.162462] [mm-at-serial-port.c:436] debug_log(): (ttyUSB2): <-- '<CR><LF>+CIND: 5,0,1,0,0,1,1,0<CR><LF><CR><LF>OK<CR><LF>' I'm not sure how best to proceed here - I want to be able to return to the ModemManager 0.6/NetworkManager 0.8.1 behaviour of "if gsm.number is *99# and gsm.apn is not set, just dial *99# and let the device and network work it out".
Review of attachment 276178 [details] [review]: Both patches remove the check for if (!s_gsm) Are we sure that s_gsm is always !NULL? Maybe just change: - if (!s_gsm || !nm_setting_gsm_get_apn (s_gsm)) { + if (!s_gsm) {
(In reply to comment #10) > Created an attachment (id=276179) [details] [review] > 0001-editor-better-handling-of-default-APNs-bgo-729665.patch > > Implement better default APN behavior in nm-connection-editor. Did not review the code, just tested it... not sure, but it seems wrong to me. For APN I only have a drop down menu "Automatic" and "Select APN"... but no way to enter the APN ... or did I miss something?
> > I'm not sure how best to proceed here - I want to be able to return to the > ModemManager 0.6/NetworkManager 0.8.1 behaviour of "if gsm.number is *99# and > gsm.apn is not set, just dial *99# and let the device and network work it out". MM 1.x fully ignores the "gsm.number" configuration from NM. Actually, it's NM not sending that info to MM because MM won't use it. We likely need to implement the 'no apn' setup ourselves in MM; i.e. if empty APN given, just dial *99#, without looking for a matching PDP context?
(In reply to comment #23) > > > > I'm not sure how best to proceed here - I want to be able to return to the > > ModemManager 0.6/NetworkManager 0.8.1 behaviour of "if gsm.number is *99# and > > gsm.apn is not set, just dial *99# and let the device and network work it out". > > MM 1.x fully ignores the "gsm.number" configuration from NM. Actually, it's NM > not sending that info to MM because MM won't use it. > > We likely need to implement the 'no apn' setup ourselves in MM; i.e. if empty > APN given, just dial *99#, without looking for a matching PDP context? That would work for me - I suspect, given that "" is a legitimate value for APN with matching PDP context, that MM needs to know that if no APN is given, the number is *99#; then, with the patches already on this bug, NM won't send MM an APN, and MM will use the *99# "just do the best you can" number.
(In reply to comment #23) > > > > I'm not sure how best to proceed here - I want to be able to return to the > > ModemManager 0.6/NetworkManager 0.8.1 behaviour of "if gsm.number is *99# and > > gsm.apn is not set, just dial *99# and let the device and network work it out". > > MM 1.x fully ignores the "gsm.number" configuration from NM. Actually, it's NM > not sending that info to MM because MM won't use it. > > We likely need to implement the 'no apn' setup ourselves in MM; i.e. if empty > APN given, just dial *99#, without looking for a matching PDP context? Not quite. There's two issues here: 1) using the default subscription APN, which means creating a blank ("") APN with +CGDCONT (or for QMI not passing any APN TLV when creating the connection), where the modem and the provider automatically determine the right APN to use from the provider's HLR data 2) using pre-configured PDP contexts in the device that new devices usually come with from the factory I believe that #1 would solve Simon's use-case, as long as the correct APN is configured with the provider in their HLR. However, if the provider has not configured the default subscription APN correctly in their network, the wrong APN could end up being used. What Simon was apparently doing with MM 0.6 and NM 0.8 (correct me if I'm wrong!) was #2, because passing a blank APN to ModemManager 0.6.x along with "*99#" would just straight dial "ATDT*99#" for PPP-based devices (see mm-generic-gsm.c::connect() around line 3880). Dialing that number is supposed to select PDP context #1. But this obviously did *not* work correctly for non-PPP devices like HSO, Ericsson, Sierra, etc because they don't use dial numbers. MM 1.0 should completely ignore dialing numbers, because they are only used on PPP-based devices, which are disappearing very quickly. Most devices out there these days, especially HSPA/LTE-capable ones, don't use PPP. So we shouldn't be talking about dialing numbers at all, we should be talking in terms of #1 and #2 above, which is the actual functionality. We can easily support #1 above. Supporting #2 above would require a bit of code in ModemManager, but the downside of having that support is that if you *don't* have a pre-configured device, or if you buy a used device, or if something has re-set the contexts, then things just simply fail and you don't have a great idea why. For example, people attempting to use Verizon LTE here in the US on Mac OS X before Verizon had an OS X connection manager often screwed up the PDP contexts, and then re-plugging those devices into a Windows machine failed to connect because the Verizon connection manager assumed PDP contexts were always configured correctly. They ended up modify the connection manager to rewrite the PDP contexts every single time the modem is inserted to fix that problem and reduce their support calls. Which is a big reason why I'm hoping that #1 above can solve Simon's use-case. IMHO better solution for #2 could be to expose pre-configured PDP/EPS contexts via the ModemManager D-Bus API, and then Simon's app (or anyone's) could read those contexts and just use the APN from context #1. Thoughts?
I'd just add that my major worry is regressions, for users in the field. If newer devices just don't work with ATDT*99#, and users have to fill in the APN or use the default subscription APN, that's fine for my use case. I do, however, need some way to take older configurations where I dial *99# without an APN configured, and make them do what they used to do.
I pushed Simon's patch (slightly modified) and a follow-on commit to NetworkManager: wwan: allow completing new GSM connections without an APN (bgo #729665) wwan: allow using the default subscription APN (bgo #729665) which should handle the NetworkManager side of things for the default subscription APN and connection completion without an APN.
Simon, can this be closed now or does anything else need to be done here? Thank you
(In reply to Lubomir Rintel from comment #28) > Simon, can this be closed now or does anything else need to be done here? > > Thank you I think it can safely be closed, but I'm not in a good position to test right now. If I've made a mistake, I'll reopen this bug or file a new one as appropriate.