<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <blockquote type="cite" cite="mid:CAAP7ucKQpMdubu8AUSL=W=Ch55p7PwQDfcUsaw01epcUcAEJwA@mail.gmail.com"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations">https://docs.microsoft.com/en-us/windows-hardware/drivers/network/mb-lte-attach-operations</a> </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> That is exactly what I see. <blockquote type="cite" cite="mid:CAAP7ucKQpMdubu8AUSL=W=Ch55p7PwQDfcUsaw01epcUcAEJwA@mail.gmail.com"> <pre wrap="">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. </pre> </blockquote> 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: <ol> <li>The UBlox manual explicitely requests not to change the default route.</li> <li>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) </li> </ol> 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.... -- <pre class="moz-signature" cols="72">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: <a class="moz-txt-link-abbreviated" href="mailto:u.mohr@semex-engcon.com">u.mohr@semex-engcon.com</a> ___________________________________________ Executive board: A. Stiegler, H.-J. Nitzpon Commercial register: Mannheim, HRB 718881 Company domicile: Ettlingen</pre> </body> </html>