Nm-applet sometimes gives wrong apn for ambiguous network-id (mcc+mnc)
SUMMARY
When the file /usr/share/mobile-broadband-provider-info/serviceproviders.xml contains multiple entries with the same network-id (mcc and mnc), nm-applet guesses the apn value, but does not warn the user of possible error or provide hints for a solution if the apn value is wrong.
EXPECTED BEHAVIOUR
The gui (nm-applet) should either make the correct guess of the apn value, or give the user a warning and hint to solutions.
OBSERVED BEHAVIOUR
The gui (nm-applet) guessed an apn value that corresponded to the correct mcc and mnc, but a different provider name. (The follow-on effect was that nmcli d showed that my internet-over-sim connection was not working, ip route did not show a route for internet-over-sim, and actions such as ping to external IPs didn't work.)
SPECIFIC AREA OR PACKAGE AFFECTED
$ dpkg -l |egrep "network-manager|mobile-broadband"
ii mobile-broadband-provider-info 20201225-1 all database of mobile broadband service providers
ii network-manager 1.30.0-2 arm64 network management framework (daemon and userspace tools)
ii network-manager-gnome 1.20.0-3 arm64 network management framework (GNOME frontend)
HOW REPRODUCIBLE IS THE BUG?
It happened several times, until I discovered the existence of the file /usr/share/mobile-broadband-provider-info/serviceproviders.xml
STEPS TO REPRODUCE THE BUG
grep -B3 -A10 --color 'network-id mcc="260" mnc="02"' /usr/share/mobile-broadband-provider-info/serviceproviders.xml
This shows that <network-id mcc="260" mnc="02"/> is shared by three distinct provider.name's: T-mobile, Heyah, and Virgin Mobile. (Virgin Mobile also has a second mcc,mnc pair.) This is unsurprising in terms of the company structures/ownership, so it is quite credible that the multiplicity is correct.
However, the apn values (and other parameters) are somewhat different among the three providers. Specifically, the apn values are, respectively, "internet", "heyah.pl", and "virgin-internet".
WHAT DEVICE ARE YOU USING?
Pinephone v1.2b
WHICH MOBIAN REPOSITORY ARE YOU USING?
https://images.mobian-project.org/pinephone/installer/
HOW DID YOU GET YOUR MOBIAN IMAGE?
https://images.mobian-project.org
SOLUTIONS YOU HAVE TRIED
After grepping/reading /usr/share/mobile-broadband-provider-info/serviceproviders.xml, I changed from the wrong apn to the right apn (assuming that serviceproviders.xml is correct) in the nm-applet. Now nmcli c and nmcli d work as expected, giving me full internet use through my mobile provider.
This solved the problem for me, but will not solve it for users unaware of /usr/share/mobile-broadband-provider-info/serviceproviders.xml, and future 2023? gui-only users will not wish to search a long text file (or even know how to access and read the file).
RELATED NON-DUPLICATE ISSUES
- possibly related: #680 (closed)
- This issue was originally posted at the Mobian bug forum: https://gitlab.com/mobian1/issues/-/issues/362 ; posting upstream here to NetworkManager was recommended.
ADDITIONAL INFORMATION
Possible solutions when multiple providers have the same mcc,mnc pair could include:
(1) in the nm-applet widget displaying the apn value that has been guessed from the mcc,mnc pair, add a drop-down menu with the list of candidate providers, with the currently guessed provider highlighted, and allow the user to switch the menu selection to the provider that s/he believes is correct; on switching the provider, update the apn value
(2) add a red text warning in the nm-applet that s/he should check the file /usr/share/mobile-broadband-provider-info/serviceproviders.xml in case the provider has been wrongly selected
** problem: the full file path may be too long to read properly
(3) run a minimal internet test, e.g. a ping, for each of the possible providers, until one is successful
** problem: many providers have "internet" as their apn, so this might still be ambiguous, and other provider-based errors may follow
** problem: users may not wish or expect network-manager to send out any packets on the internet;
** problem: hardwiring a choice of domain name(s)/IP(s) to ping could require updating sooner or later; and would violate the user's right to control internet usage (overlaps previous objection).