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
