mm_3gpp_select_best_cid breaks if APN matches PDP context with cid=0
I have a device which has a non-removable PDP context with cid=0 as shown below:
ModemManager: <debug> [1596924966.230667] (ttyACM0): <-- '<CR><LF>+CGDCONT: 0,"IP","globaldata","0.0.0.0",0,0,0,0,0,0,0<CR><LF><CR><LF>+CGDCONT: 1,"IP","globaldata","172.17.191.111",0,0,0,0,0,0,0<CR><LF><CR><LF>OK<CR><LF>' ModemManager: <debug> [1596924966.230756] Found '2' PDP contexts ModemManager: <debug> [1596924966.230767] PDP context [cid=0] [type='ipv4'] [apn='globaldata'] ModemManager: <debug> [1596924966.230774] PDP context [cid=1] [type='ipv4'] [apn='globaldata']
mm_3gpp_select_best_cid searches for an existing context when connecting to APN
globaldata, it will immediately match the first context, set
exact_cid to 0 and break out of the loop. But the
if (exact_cid) condition will not match because 0 is also used for "not found", and the
max_cid check will also be bogus for the same reason.
The result is that the cid=1 fallback will always be used. The nice fix would be to use something like UINT_MAX as the placeholder for "not found". But since it looks like 0 is used for "missing cid" in other places too, the easiest fix here might be to just always ignore the +CGDCONT entry with cid=0 in
mm_3gpp_parse_cgdcont_read_response and hope that other slots are available.
I'm testing this on 1.12.8 but the master source looks like the issue is still present in the latest version. In practice this leads to a situation where the connection can only be established once without manual AT command intervention: cid=1 will be in attached state (looks like the device has an unrelated deactivation issue), ModemManager tries to re-set the APN which is in use even though there's already the right APN in the slot and fails.
AT+CGDCONT=0,"IP","dummy" to set cid=0 to an APN which is not used by any real configuration.