unexpected pdp ctx deactivation

[Aleksander Morgado]

Hey Alexey,


> I'm implementing ecm support in telit plugin (baseline: latest main).
> Somehow modem goes in connect-disconnect loop with a few seconds in between.
> I'm trying to identify a reason for disconnect and related issues in MM debug log.
>
> Q1. Is a negative value in profile_id (and eventually in index_field_value_str) a legal one?
> Does a negative value mean uninitialized data in profile context? Coz CGACT output has always positive ctx index:
> AT+CGACT?
> +CGACT: 1,1
> +CGACT: 3,0
>
> ModemManager[]: <debug> [1661944714.481355] [modem0] set profile state (3/8): select profile (best)
> ModemManager[]: <debug> [1661944714.481370] [modem0] found exact context at profile 1
> ModemManager[]: <debug> [1661944714.481375] [modem0] reusing profile '1'
> ModemManager[]: <debug> [1661944714.481379] [modem0] set profile state (4/8): check activated profile
> ModemManager[]: <debug> [1661944714.481390] [modem0] checking if profile with id '1' is already activated...
> ModemManager[]: <debug> [1661944714.481402] [ttyUSB1/at] device open count is 4 (open)
> ModemManager[]: <debug> [1661944714.481418] [ttyUSB1/at] device open count is 3 (close)
> ModemManager[]: <debug> [1661944714.481436] [ttyUSB1/at] --> 'AT+CGACT?<CR>'
> ModemManager[]: <debug> [1661944714.518369] [ttyUSB1/at] <-- '<CR><LF>+CGACT: 1,1<CR><LF>+CGACT: 3,0<CR><LF><CR><LF>OK<CR><LF>'
> ModemManager[]: <debug> [1661944714.518463] [modem0] profile '-1' is activated
> ModemManager[]: <debug> [1661944714.518479] [modem0] set profile state (5/8): deactivate profile
> ModemManager[]: <debug> [1661944714.518488] [modem0] deactivating profile with id '1'...
> ModemManager[]: <debug> [1661944714.518502] [ttyUSB1/at] device open count is 4 (open)
> ModemManager[]: <debug> [1661944714.518519] [ttyUSB1/at] device open count is 3 (close)
> ModemManager[]: <debug> [1661944714.518540] [ttyUSB1/at] --> 'AT+CGACT=0,1<CR>'
> ModemManager[]: <debug> [1661944714.561517] [ttyUSB1/at] <-- '<CR><LF>OK<CR><LF>'
> ModemManager[]: <debug> [1661944714.561599] [modem0] deactivated profile '-1'
> ModemManager[]: <debug> [1661944714.561610] [modem0] set profile state (6/8): profile already stored
> ModemManager[]: <debug> [1661944714.561616] [modem0] set profile state (8/8): all done
> ModemManager[]: <debug> [1661944714.561639] [modem0/bearer0] (shared-telit) ECM: selecting NW interface as a data port
> ModemManager[]: <debug> [1661944714.561664] [ttyUSB1/at] device open count is 2 (close)
> ModemManager[]: <debug> [1661944714.561700] [modem0/wwan0/net] port now connected
> ModemManager[]: <debug> [1661944714.561707] [modem0/bearer0] connected
> ModemManager[]: <info>  [1661944714.561776] [modem0] state changed (connecting -> connected)
> ModemManager[]: <info>  [1661944714.562088] [modem0] simple connect state (10/10): all done
> ModemManager[]: <debug> [1661944730.307060] [modem0] user request to disconnect modem (all bearers)
>

Is this recent change somehow related maybe?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/829

>
> Q2: Since no mmcli or any other human input was used, what the phrase "user request to disconnect modem" really mean?
> Could internal MM logic be considered as "user input"?
>

Humm... that message should exclusively happen when a
Modem.Simple.Disconnect() DBus call arrives, that's why it's "user
input".

> Q3. Will MM always tear down existing pdp context instead of reusing it? (even if all parameters are the same)

The answer, I'm afraid, is "it depends". The MBIM implementation
ensures the profile is disconnected before attempting a new
connection, while other implementations don't do that, they try to
launch a new connection even if it was already up, letting the modem
return an error if it's appropriate. The thing is, MM doesn't expect
any PDP context to be up (ideally) if it didn´t bring it up MM itself.
The most notable cases where this is not true is with initial default
EPS bearers (attach bearers) which may be exposed as being up before
triggering any new connection (and some implementations like the ones
for u-blox TOBY modules try to handle that gracefully, because
attempting to disconnect them would result in de-registering from the
network), and also with "autoconnected" modems, where the data bearer
is brought up by the modem itself automatically (and there is no
general way to handle those yet anywhere really)

-- 
Aleksander