<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hey, <br>
    </p>
    <p>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.<br>
      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 :-)<br>
    </p>
    <p>I tested the new version without modifications and found two
      "problems":</p>
    <ul>
      <li>The default bearer interface is not implemented for ublox
        modems</li>
      <li>The device does only sometimes get a LTE connection, sometimes
        it doesn't. <br>
      </li>
    </ul>
    <p>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: <br>
      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
<a class="moz-txt-link-freetext" href="https://www.u-blox.com/sites/default/files/LTE-initial-default-bearer_AppNote_%28UBX-20015573%29.pdf">https://www.u-blox.com/sites/default/files/LTE-initial-default-bearer_AppNote_%28UBX-20015573%29.pdf</a>).
      <br>
      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<br>
    </p>
    <p>Therefore I did some modification in MM to make the Toby work:<br>
    </p>
    <p></p>
    <ul>
      <li>I implemented the the initial EPS bearer setting interface
        (functions  set_initial_eps_bearer_settings*,
        load_initial_eps_bearer_settings*) similar to the icera plugin.
        I used the at+ucgdflt command for reading and writing the
        initial EPS bearer setting (this command is available on Toby-L2
        and MPCI-L2 only).</li>
      <li>I implemented the profile list interface (functions
        list_profiles*) to prefer CID 4 when MM tries to reuse a PDP
        context for connecting<br>
      </li>
    </ul>
    <p>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.</p>
    <ul>
      <li>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?</li>
      <li>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?</li>
      <li>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?</li>
    </ul>
    <p>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 .... ;-)</p>
    <p>I really look forward for any answers and ideas.</p>
    <p>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....)</p>
    <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
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>