GNOME Bugzilla – Bug 701333
[MM 0.8] Default bearer connection logic for multimode devices
Last modified: 2013-06-05 16:59:39 UTC
Rules to connect bearers in multimode devices (context in bug 701223): 1) no APN given, modem registered with CDMA => CDMA bearer 2) no APN given, modem registered with 3GPP or LTE => error 3) APN given, modem registered with CDMA => 3GPP bearer, assume LTE could be used if the modem finds it? 4) APN given, modem registered with 3GPP or LTE => 3GPP bearer
Two notes: ------ Default subscription APN At some point we probably will have to support the "default subscription APN", which is basically the null/blank APN. But AFAIK there's no way to determine whether the operator *and* the modem firmware support it. Some devices do, simply by setting the APN to "" in AT+CGDCONT=... and then you connect and they use whatever magical default APN the operator has in their database for your IMSI or something. This would affect case #2 above, where instead of returning an error, we'd just try to connect with NULL APN and then if the modem/operator didn't support it, we'd fail I suppose. ------ CDMA-only modems with case #3 If the modem hardware doesn't support LTE, should we (a) error out, or (b) just ignore the APN and create a CDMA bearer? Technically that's a misconfiguration since CDMA-only modems don't use an APN at all, but I'd like to know what QMI on eg a Gobi 3000 does first. (and more technically, only modems that support eHRPD support APNs, and right now that's only devices that support LTE) The only problem with (a) is that if you use the same configuration with two different modems (one CDMA-only, and one CDMA/LTE) then you'll get an error for the CDMA one but not for the LTE one, but I don't think that's a big issue... (technical aside: it's possible that CDMA-only devices will eventually support eHRPD, which is the protocol suite that combines 3GPP and 3GPP networks. Then they'd have to accept an APN parameter since part of the IP address allocation process on eHRPD-capable networks involves sending the APN to the network.) ------ So maybe, slight update: 1) no APN given, modem registered with CDMA => CDMA bearer 2) no APN given, modem registered with 3GPP or LTE => error a) eventually we'll accept this and just use the default subscription APN 3) APN given, modem registered with CDMA => 3GPP bearer a) if modem does not support LTE => error 4) APN given, modem registered with 3GPP or LTE => 3GPP bearer
Created attachment 245997 [details] [review] Patch. Let me know what you think. Instead of looking at the current registered network, I just used the modem capabilities to decide which kind of connection logic to use. For the 3GPP-only or 3GPP2-only modems, the logic is clear, and it shouldn't matter whether we're registered or not. For the 3GPP+3GPP2 modems, we look at the APN setting given to see if we should launch the 3GPP or the 3GPP2 connection logic. Here, if we have such a modem, e.g. a CDMA+LTE modem, and we are registered only in the CDMA network, I believe we still should be launching the 3GPP connection logic if APN given, and otherwise fallback to the 3GPP2 connection logic. Therefore, there's no point in checking the current registered network, for what I can see... right?
Yeah, that logic looks right. Patch looks good to me too.
Review of attachment 245997 [details] [review]: Looks good to me.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.