Hi Giacinto,
> >
> > I'm working on adding proper support for the Fibocom MC610 modem which has
> > some unusual behaviour regarding the initial EPS bearer configuration
> > that's causing issues with ModemManager.
> >
> > The key issue is that on this modem, the attachment bearer must use
> > CID 0,
>
> I'm surprised that there is actually a modem following the 27.007:
> "The feature "initial PDP context" may be supported and is a manufacturer
> specific option. For this option, the context with
> <cid>=0 (context number 0) is defined upon startup and does not need to be
> created with the +CGDCONT command. The initial PDP context has particular
> manufacturer specific default settings disassociated with any other default
> settings of +CGDCONT." (paragraph 10.1.0 of the
> V16.12.0 (2022-06)).
Really interesting. This modem is based on the UNISOC 8910DM (Cat. 1bis),
contextual information as Fibocom suggested this particular behavior is linked
to the chipset.
> >
> > Similarly, for authentication settings, both AT+CGAUTH and AT+MGAUTH
> > commands don't report CID 0 as valid:
> > +CGAUTH: (1..7),(0..2),(0..20),(0..20)
> > +MGAUTH: (1-7),(0-2),(64),(64)
> >
>
> this goes together, yes, but in general it is only needed for private APNs
> (as well as setting the attach APN to some actual value and not to an empty
> string that lets the network do the job)
Yes indeed. In our case, we choose this modem for an embedded product and found
out that a lot of our customers are using private/custom APN.
We have for example ourselves a custom APN (which we can access through a VPN)
with Sunrise, one of the 3 Swiss main operators, and it requires a
username/password.
> > I've tried overriding 'load_initial_eps_bearer_cid' to return 0, but the
> > profile manager still fails because this CID is outside the range reported
> > by AT+CGDCONT=?.
> >
> > An additional complication: when the modem is in power-down mode (CFUN=4),
> > AT+CGDCONT? returns just "OK" with no profile data. This breaks the
> > 'handle_set_initial_eps_bearer_settings_step' function, which powers down
> > the modem first and then tries to get the current profile list.
> >
>
> this is not good. it means that you have to go to CFUN=1, and while the
> modem attempts to attach you need to change the APN/user/pwd...
I made some progress here after overloading some callbacks in the Fibocom's
plugin (load_initial_eps_bearer_cid, modem_3gpp_profile_manager_store_profile,
modem_3gpp_set_initial_eps_bearer_settings,
modem_3gpp_load_initial_eps_bearer_settings, ...).
I also hardcoded the min_cid to 0 instead of 1 and some other ugly things, just
to do some tests.
I appears in fact AT+CGDCONT? returns correctly the context but only once the
context is attached to the network something like:
1. EPS bearer settings
2. AT+CFUN=1
3. AT+CGDCONT?
OK
<later...>
+CREG: 1," XXXX"," XXXXXXXX",7
4. AT+CGDCONT?
+CGDCONT: 0,"IP","internet","<ip>",0,0
So the profile manager fails during the reload steps:
ModemManager[259464]: <msg> [1742847998.979878] [modem0] power state
updated: on
ModemManager[259464]: <dbg> [1742847998.979905] [modem0] modem power state
updated: low -> on
ModemManager[259464]: <msg> [1742847998.979921] [modem0] set initial EPS
bearer settings state (4/5): reload
ModemManager[259464]: <dbg> [1742847998.979925] [modem0] (shared-fibocom)
modem_3gpp_load_initial_eps_bearer_settings
ModemManager[259464]: <dbg> [1742847998.979940] [ttyUSB0/at] device open
count is 4 (open)
ModemManager[259464]: <dbg> [1742847998.979962] [ttyUSB0/at] device open
count is 3 (close)
! ModemManager[259464]: <dbg> [1742847998.980036] [ttyUSB0/at] -->
'AT+CGDCONT?<CR>'
! ModemManager[259464]: <dbg> [1742847999.019595] [ttyUSB0/at] <--
'<CR><LF>OK<CR><LF>'
ModemManager[259464]: <dbg> [1742847999.019717] [modem0] (shared-fibocom)
load_initial_eps_bearer_settings_parent_ready
! ModemManager[259464]: <wrn> [1742847999.019743] [modem0] failed reloading
initial EPS bearer settings after update: Profile '0' not found
ModemManager[259464]: <msg> [1742847999.019758] [modem0] set initial EPS
bearer settings state (5/5): failed
ModemManager[259464]: <dbg> [1742847999.019827] [modem0] [operation 2]
default - set-initial-eps-bearer-settings: lock released
ModemManager[259464]: <dbg> [1742847999.019873] [ttyUSB0/at] device open
count is 2 (close)
ModemManager[259464]: <dbg> [1742848000.681337] [ttyUSB0/at] <--
'<CR><LF>+GSM Service<CR><LF>'
ModemManager[259464]: <dbg> [1742848000.681586] [ttyUSB5/at] <--
'<CR><LF>+GSM Service<CR><LF>'
! ModemManager[259464]: <dbg> [1742848000.683500] [ttyUSB0/at] <--
'<CR><LF>+CREG: 1,"XXXX","XXXXXXXX",7<CR><LF>'
The CGDCONT command returns something only when the modem gets attached to the
network. And if the configuration is wrong (bad APN name, bad authentication,
etc), nothing happens.
But I can imagine MM would even not start correctly if I don't have network
signal during the init process as GDCONT would never return the PDP0 if not
attached.
Should the EPS bearer considered as a standard bearer, while we can't "connect"
with it but only register the network so no synchronous feedback, we get only
asynchronous event on network attachment (with CREG for example).
Sorry if my question is naive as I don't have experience with any other modem
so that's just my "small vision". The only hack I can see now is to memorize
this PDP context in the plugin and reuse it instead of asking to the modem.
> > I've seen in the code that ModemManager has special handling for some
> > modems' EPS bearer quirks, but I'm not sure where to start with these
> > particular issues. Any guidance on the best approach would be greatly
> > appreciated.
>
> what is the network interface? MBIM/ECM/NCM/...?
This modem can be configured for PPP, ECM or RNDIS and I'm using the ECM
alternative.
Yannick
