PDP Context Selection problems on Cinterion PHS8

Osborne, Paul Paul.Osborne at etherios.com
Mon Mar 9 16:52:16 PDT 2015


Hello Again,

On the modem we are working with (Cinterion PHS8) in the configuration
we have, the modem starts up with the following PDP Context if slot 17
does have other values set:

    AT+CGDCONT?
    +CGDCONT: 17,"IP","","0.0.0.0",0,0
    OK

    AT+CGDCONT=?
    +CGDCONT: (1-17,101-116),"IP",,,(0),(0-4)
    OK

On the PHS8 (and possibly other modems), the documentation states that
slots 1..16 in the valid range for CIDs.  Presumably slot 17 is
reserved for other use (we believe slot 17 is reserved for use with
the QMI WWAN interface which we are not currently using).

We had assumed that when we create a bearer, ModemManager would use
one one of the 16 available slots prior to 17, but this does not
appear to be the case.  The current logic in mm-broadband-bearer.c for
selecting a PDP context will select a CID based on the following rules
executed in-order:

  1. If a context exists with same APN (case insensitive as of 1.4.2),
     use that context.
  2. If a context exists with an empty APN, use that context.
  3. If no context exists matching #1 or #2, pick CID based on the CID
     range.

In our case, MM fails to parse the CID range as it does not support
the response provided by this modem with the regex currently in
mm_3gpp_parse_cgdcont_test_response.

    \\+CGDCONT:\\s*\\((\\d+)-?(\\d+)?\\),\\(?\"(\\S+)\"

So, on the PHS8 we have two issues that prevent correct operation:

  1. By default, ModemManager select CID 17 which cannot be used as a
     valid context when connecting via serial.
  2. If Context 17 is modified or removed, CID 1 is always selected.

Case #2 turns out to work out OK in our case but it does not seem
ideal to be overwriting any previously configured context in slot
1 that happens to match.  Getting to case #2 requires us to either
fill slot 17 with a non-empty APN or remove it each time we start the
modem.

So, a few questions:

  1. What is the reason for choosing existing CIDs with empty APNs as
     valid candidates to be overwritten?  Is this behavior required
     for other modems?
  2. Would it be worthwhile to attempt a change to add support for
     parsing CID range with the (a-b,x-y) format?

Thanks for the help,
Paul Osborne


More information about the ModemManager-devel mailing list