Support for Fibocom MC610 with non-standard EPS bearer handling

[Yannick Serafini]

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