u-blox plugin, questions while implementing support for TOBY-L210

[Ulrich Mohr]

Hey,

>> I am using ModemManager with u-blox TOBY-L210 for a while now with older versions of ModemManager (1.7.x). I did some patches and home-brew code to make that combination work.
>> I now want to switch to newer versions of MM (1.18), benefit from the good work on MM, and do it "the right way" this time, so I can contribute to MM :-)
>>
>> I tested the new version without modifications and found two "problems":
>>
>> The default bearer interface is not implemented for ublox modems
>> The device does only sometimes get a LTE connection, sometimes it doesn't.
>>
>> While the reason for the first problem is quite obvious ;-), I did some analysis on the second one and found the reason why it does not work:
>> Whenever there is a PDP context matching the APN, besides the context with CID 4 -- which is used by the modem to automatically create a connected bearer when it can connect using the default EPS bearer -- MM selects that PDP context and tries to establish a connection using it. But since there is already a connected context with CID 4, connecting a secondary context to the same APN may fail (depending on the SIM card, due to MNO restrictions I guess, see https://www.u-blox.com/sites/default/files/LTE-initial-default-bearer_AppNote_%28UBX-20015573%29.pdf).
>> Now the question is why there is a second PDP context when trying to connect. The answer is that this context has been created by MM when it tries to connect while the default bearer is not connected: CID 4 is unused when the initial bearer is not connected, so MM creates a second one that gets in the way when we later on try to connect a connection and the initial bearer is there again
>>
> What operator is this? Is it Verizon in the US? Or does the TOBY-L2
> really always use CID 4 for the initial default bearer?

Toby-L2 always uses CID 4 for the initial default bearer: As soon the 
device registers to an LTE network, PDP context with CID 4 is set and 
connected. When not connected (e.g. 3G network), this PDP context is 
unused and not set (as any other unused empty PDP context).

The restriction, that no second context can't get connected while the 
default bearer is already connected applies to the German Vodafone 
network (seen this with Vodafone SIM cards, but also with SIM cards from 
other providers that use the Vodafone network)

>> [...]
>> I implemented the profile list interface (functions list_profiles*) to prefer CID 4 when MM tries to reuse a PDP context for connecting
>>
> I'd like to see how that's done :)

Quite simple: I implement the list_profiles in the ublox plugin, call 
the parents function first and after that order the list returned, so 
that the context with CID 4 is on top of the list. This way, MM select 
this context whenever it is available and matches the requested APN.

>> I got it up and running. But I want to push that changes into MM, so there are some open questions regarding the implementation I want to discuss.
>>
>> The Toby L210 does not allow to read back the username to use for the initial bearer. Therefore, comparing the username after writing the initial bearer fails. I omitted comparing the username for now when comparing the previous EPS bearer settings with the new ones. This change is not in the ublox plugin, so I doubt this is a good idea. How to handle this properly?
> I think you can subclass the modem_3gpp_profile_manager_check_format()
> in the profile manager interface, and return a custom
> MM3gppProfileCmpFlags that includes MM_3GPP_PROFILE_CMP_FLAGS_NO_AUTH.
> But for that I think you may need to implement the initial bearer
> setup using the profile manager API somehow. E.g. if updating a
> profile associated to the initial lte bearer, use UCGDFLT, otherwise,
> use the standard CGDCONT operations. What I'm not sure is if there's
> currently some way to say "CMP_FLAGS_NO_AUTH only for the initial
> bearer".
Thank you for pointing me to that function. I will look into it whether 
it can be done the way you suggest.
>> The ucgdflt command is not available for other ublox modems, so the implementation I did only applies to Toby-L2 and MPCI-L2. This information must be gathered somehow. I see two possibilities: using the at+ucfgdlt=? to test the availability of the command (when would I do that?), or introduce a flag similar to the ubandsel flag inside the band configuration struct. What would be the method to prefer?
> A query always, e.g. AT+UCFGDLT=?. The udev flags are only for when
> there is no other way to query. Depending on how you structure the
> logic, if you make the changes using the new profile manager API, you
> could subclass modem_3gpp_profile_manager_check_format() and in
> addition to running the parent method (that will do the generic check
> for AT+CGDCONT=? by itself) you could also do the custom check for
> AT+UCFGDLT=?
That was the missing link I needed :-) I will implement the query there.
>> Is implementing the profile list interface the right approach? The fact that MM selects an already activated PDP context (cid 4), tries to deactivate it (which fails, but is ignored), tries to activate it again (which fails, but is ignored as well) and then uses it "smells" and indicates to me that this might not be the right solution. A better approach might be that MM accepts using an already activated PDP right away without trying to disconnect and connect again, but this would mean that there are massive changes required in MM to support that. What is your opinion on that?
>>
> So, this one's tricky. For this very specific case of the TOBY
> modules, we may see that we can go on and assume the context is
> already connected and don't attempt to reconnect. The problem is
> really the settings; if we can confirm the settings that we request
> match the settings of the connected context, I think it should be
> fine.

At least, it works at the moment.

In general, I think that the way that ublox intended to use the Toby-L2 
does not really match the way that MM works: In its application notes, 
ublox suggest to set the default bearer setting and then just to use the 
already connected context.
If I map that to MM / NM, that would mean that MM exports the already 
connected default bearer (it already does, but who is using it?) and NM 
uses this bearer to show the device as connected. But that is not the 
way MM and NM work at the moment, right?

This brings me to another question: What is the intention to export the 
initial bearer in ModemManager, as bearer object? Who will use this 
bearer object?

>> I found other small issues during work (build warnings, const issues etc), but I guess this email is long enough already, so I postpone that .... ;-)
>>
> If those issues are unrelated to big changes, please go on and suggest
> them in https://gitlab.freedesktop.org/mobile-broadband/ModemManager
> as merge requests. Actually, for the big changes also, if you want to
> split them in separate proper patches and send them as a merge request
> that would also be fine.
I will do that.
>> I really look forward for any answers and ideas.
>>
>> I hope I managed to describe the problem and my solution so that one can understand it, otherwise just ask. I can also provide the code with changes I did....)
>>
> One last question here; are the changes you're suggesting all
> applicable and working in both bridge and router mode in the TOBY-L2?
At the moment, I use the modem in router mode and I didn't test in 
bridge mode (yet). From the manuals, I don't see why it shouldn't work 
in bridge mode as well.

When I think the the implementation works properly in router mode, I 
will do some tests in bridge mode, too.....

Thank you for your comments and suggestions!

-- 

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.mohr at semex-engcon.com
___________________________________________
Executive board: A. Stiegler, H.-J. Nitzpon
Commercial register: Mannheim, HRB 718881
Company domicile: Ettlingen