Hey Aleksander,
Thank you for the clarifiction, this helps a lot. There is one point
open though, that I did not fully get, see comments below.
Am 05.11.2018 um 09:54 schrieb Aleksander Morgado:
On 11/5/18 9:02 AM, Ulrich Mohr wrote:
I am facing this problem, too (see
https://lists.freedesktop.org/archives/modemmanager-devel/2018-August/006633.html).
I addressed that problem by changing the modem manager logic to set the default
bearer using the UCGDFLT command whenever a the bearer changes. This seems to
work reasonably (with the drawback as described in the thread linked above). I
am still testing this, since I am not yet sure that this really does the job.
@Aleksander, concerning your planned implementation. You wrote in the thread
above:
This should be some API that is totally independent from the connection process
I think.
It is not clear to me how this will work: I don't get any connection not using
the UCGDFLT command, so if a bearer is set, this needs to be result somehow in
the UCGDFLT command. So how can this be independent from the connection
process? If someone sets the APN, e.g. via the Network Manager, the UCGDFLT
command must be issued, otherwise it will not work...
Yes, I'm planning to add this as a new API, a new way to be able to manage the
initial default LTE attach bearer. The user will be able to use this API when
the module is in low-power mode only (e.g. CFUN=4) and the idea is that it will
setup the bearer details as we currently do during connection (e.g. APN, user,
pass...). I'm probably going to suggest that we automatically create a bearer
object upon boot if the module allows to manage the initial default LTE attach
bearer settings (e.g. u-blox and MBIM at least).
Sounds good. I think that automatically creating a bearer object is the
right approach, because that reflects what the modem (at least the TOBY)
acutally does.
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?
BTW: Since I did an implementation that works for me, I could provide
that source code somehow, if your are interested. I don't think it is
perfect and will need changes to work the way you plan, but perhaps it
might help nevertheless? If interested, let me know which works best for
you how to provide the source code ...
--
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
