> > 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) >
Actually... I'm a bit wrong here. There is some generic logic to deactivate a profile before setting it up again in the 3GPP manager "set profile" sequence, which is used when the user didn't specify a given "profile-id" to use. See e.g. select_profile_3gpp() in mm-broadband-bearer.c (applicable to all AT modems) and the set_profile_step() method in mm-iface-modem-3gpp-profile-manager.c -- Aleksander
