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[54016]: <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[54016]: <debug> [1596924966.230756] Found '2' PDP contexts
ModemManager[54016]: <debug> [1596924966.230767] PDP context [cid=0] [type='ipv4'] [apn='globaldata']
ModemManager[54016]: <debug> [1596924966.230774] PDP context [cid=1] [type='ipv4'] [apn='globaldata']
When 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.
Workaround: use AT+CGDCONT=0,"IP","dummy"
to set cid=0 to an APN which is not used by any real configuration.