> >>> 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. 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. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
