On allowing bearer creation from PDP context ID.

[Aleksander Morgado]

Hey Jessy,

> I have been working on getting a product certified with Verizon, but failed because my first implementation did not handle their OTA-DM (Over the Air Device Management) behavior. This stage of certification relies heavily on creating bearers out of PDP context IDs (Verizon handles most of the messy bits in setting those contexts for you in the modem).
>
> My current solution is to manually read the PDP contexts off of the device with AT+CGDCONT=?, reading out the Verizon mandated PDP context, and then asking ModemManager to create a bearer out of that bearer configuration (which causes ModemManager to scan the list of contexts and find an exact match with the one we just read). This works, but it is cumbersome, and I hear that more networks are planning to move to a similar process in the future (Sprint already has, though I heard that is a little half baked).
>
> Because of this, I feel it would be worthwhile to allow bearers to be created by specifying only a PDP context (and perhaps even an API backed way to inspect them). This would make passing Verizon certification a lot less hackey than it currently is.
>

Eric already started drafting an API to expose the currently
configured contexts/bearers, and I believe he also provided an
implementation for QMI and MBIM modems:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/179
It hasn't been a priority, though, so nothing more has been done I believe.

The idea in mind is to allow exposing the context/bearer settings to
the user in a clean way, so that these settings can be not only
queried but also modified. And once that is done, yes, we could
definitely have an API to say "create bearer connection with the
settings in CID <N>".


> I am happy to do as much of the work as necessary, but I want to know the community's opinion of this base proposal, and make sure anything that is built actually solves a problem and will be accepted.
>

Maybe you could review what Eric has done until now, and see how that
fits your purpose? My last suggestion to Eric, IIRC, was to first try
to define all public APIs, to see how they would look like (i.e. not
only showing the list of profile settings, but also allow changing
them or using them for connection), and then go implement them one by
one.

-- 
Aleksander
https://aleksander.es