Upon connection from e.g. NM, MM will check whether the requested settings
(APN, ip-type...) match the ones from the default LTE attach bearer, and if
they do, MM will report that the modem is connected right away without trying
to create and connect a different context. This is already more or less what
the u-blox plugin does. And when disconnecting the connection, if it was the
initial default LTE bearer, we'll just report disconnection without touching
the actual bearer in the modem (as that would probably return an error). This
procedure is IIRC what Microsoft suggests in the MBIM extensions that allow
this kind of management, see:
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations
Ok, that approach more or less matches the implementation I test at the
moment, except that I set the default bearer upon first connection
establishment with that APN (lacking other possibilities to do so).
That leads me directly to the one open point: How will the use case
works when using Network Manger with your new API?
The user will enter the APN information to set up the connection
information (in my case, that will be a device configuration UI). That
will result in a new (or changed) Network manager connection
configuration. Now, the Network manager will have to bring the modem to
low power and set the default LTE bearer and then bring the modem back
to full power. How will this be done?
I am actually not expecting NetworkManager changes at this point. The
fact that someone needs to change the initial default LTE bearer
manually is not a common use case. If the device doesn't have an
explicit config for the SIM card in use, the network provides some
default values (if I'm not mistaken), and that is usually more than
enough in most cases.
I suspect you are wrong here: Without the default LTE bearer, there is
no LTE connection possible at all using TOBY with specific providers
(Telekom.de, Telekom.cz), since the network provides default values, but
these values are not suitable to get a functional LTE connection.
Instead you get routed to a non-functional APN ('nodata.telekom.de'). (I
am not sure why the do it that way, it seems they want to force the user
to specify the APN settings explicitely, e.g. to provide several APNs
with different services using the same SIM card? Just guessing ...)
These cards are not special SIM cards, these are the normal LTE SIM
cards every customer gets (and the they are the biggest provider in
Germany). None of these cards can be used with ModemManager at the
moment with the TOBY modem.
So your provider falls back to an APN that doesn't allow data
connection when no explicit initial default LTE bearer settings are
given, that is not wrong. But then you say that if an additional
primary bearer is connected e.g. with the correct data-capable APN,
you can't yet have data connectivity.
That is exactly what I see.
I can see in your original logs
how the second bearer is successfully connected, it gets a new IP
address, but no traffic goes through.
Could you retest that setup (the one with the original MM new context
creation without UCGDFLT) with MM running in debug mode and run this
command at the same time the pings are failing?
$ mmcli -m 0 --command="AT+UIPROUTE?"
Maybe the TOBY configured the default route over the internal network
interface associated to the initial default bearer instead of the new
one that was added by MM.
Your analysis is correct, the route is not set to the new context but
remains on the default bearer (which is also documented in the UBlox
manual).
This was my second approach to make it work: I implemented to set the
default route after context activation using the uiproute command.
This works for the telekom SIM cards.
But then I discarderd this approach for two reasons:
1. The UBlox manual explicitely requests not to change the default route.
2. This approach does not work for other SIM cards. If I remember
correctly, the problem comes from providers that do not allow the
creation of a secondary PDP context (e.g. Vodafone Germany, which
are heavily used as M2M cards in embedded market here). Since the
default APN as provided by the network is already connected, setting
up the secondary context fails. I tried to detect the existance of
the default connection, but that did not work out since the name of
the default APN does not match the offical APN name. In addition,
Modemmanager as of today tries to disconnect the default connection,
which is prohibited by the ublox firmware (for that reason,
disconnecting the default EPS and setting up a new one is as well
not an option)
Nevertheless, I will try to retest both approaches the next days and
provide logs for the different approaches using differnet SIM cards (but
I don't know when I will get the time to do it...).
BTW: The ublox documentation requests to set the default bearer using
the UCGDFLT command when the network provided bearer does not provide
internet connectivity. So they seem to be aware of this problem....
--
Best regards / Mit freundlichen Grüßen / Salutations distinguées
Ulrich Mohr
SEMEX-EngCon GmbH
Carl-Merz-Strass 26
76275 Ettlingen
Phone: +49 (0) 7243 5143596
email: u.m...@semex-engcon.com
___________________________________________
Executive board: A. Stiegler, H.-J. Nitzpon
Commercial register: Mannheim, HRB 718881
Company domicile: Ettlingen
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
