PDP Context Selection problems on Cinterion PHS8

[Aleksander Morgado]

On Tue, Mar 10, 2015 at 12:52 AM, Osborne, Paul
<Paul.Osborne at etherios.com> wrote:
> 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?

I don't think there is any reason to do that. Actually, the PDP
context with an empty APN is a valid PDP context.
Patches welcome :)

>   2. Would it be worthwhile to attempt a change to add support for
>      parsing CID range with the (a-b,x-y) format?

Yes. But one other thing; if CID 17 cannot be used when in AT mode,
the good fix would be to actually remove it from the list of supported
PDP contexts when the AT+CGDCONT=? response is parsed, in a
plugin-specific way.


-- 
Aleksander
https://aleksander.es