Hey, >> > u-blox released the following guidance in June 2020 on the TOBY-L2, >> > TOBY-R2, and LARA-R2 to setup your APN you want to connect to as the >> > initial bearer at CID=1. >> > >> > https://www.u-blox.com/sites/default/files/LTE-initial-default-bearer_AppNote_%28UBX-20015573%29.pdf >> > >> > These modems already have a default CID=1 APN setup that is generic and >> > ModemManager then uses another CID based on the APN you want to use and >> > the IP type (IPv4, IPv6, both). When I manually modified the modem's >> > CID=1 entry to the correct APN and IP type to match what ModemManager is >> > trying to use, the modem connected so much faster with ModemManager and >> > did not have as many issues with re-connection times. >> > >> > I am interested in making changes to ModemManager to implement always >> > using CID=1 for these modems. I know the code that handles the CID >> > selection and creation of new ones if there is no a match is in >> > src/mm-broadband-bearer.c. I also know there is a plugin for u-blox that >> > can detect model types. What I am not sure how to do is override the >> > functions in src/mm-broadband-bearer.c with ones that will be in the >> > u-blox plugin. The AT command u-blox uses to modify CIDs is AT+CGDCONT. >> > >> > Additionally I still want to use the code in src/mm-broadband-bearer.c for >> > all other u-blox modems that don't match these models. >> > >> > Another difficult part of this is the modem needs to be de-registered from >> > the network when changing CID=1 if the APN and IP type do not match what >> > the ModemManager APN and IP type are. The modems use AT+CFUN to put the >> > modem in airplane mode and back to full mode when changing the CID=1 APN >> > settings. I don't think this works with the current data connection flow >> > in ModemManager. >> > >> > I am currently using the ModemManager 1.8.X series, but could implement >> > the changes on the newest version and the back port them for the product I >> > am working on. I plan to update to the newest ModemManager eventually, >> > but if updating now makes this easier to implement, then I might do that >> > sooner than originally planned. >> > >> > I would really appreciate some guidance on how I would best go about >> > implementing these changes. Thanks. >> > >> >> Please take a look at the recent Cinterion plugin changes, because >> Giacinto has already implemented this kind of thing for Cinterion >> modems, using the SetInitialEpsBearerSettings() method: >> https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Modem3gpp.html#gdbus-method-org-freedesktop-ModemManager1-Modem-Modem3gpp.SetInitialEpsBearerSettings >> >> See >> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/e2ab49db0f5078716156c70a23f8f5d5b6d27848 >> for the specific details. In the case of Cinterion modems, it was not >> always CID=1, it was required some additoinal logic to guess which >> would be the correct CID to use based on the operator. >> >> My suggestion would be to provide a u-blox specific implementation for >> now, without looking at making it generic yet, and once we have >> several such implementations we can simplify the logic and build up >> the generic code to match all. > > > I would like to add one note: NM does not call this > SetInitialEpsBearerSettings() method. > You will need a separate supervision to set it adequately on a given trigger > (when the modem is detected or when a new SIM is detected). >
Yes, that is true. My personal suggestion is that: * For standard desktop systems e.g. based on GNOME or KDE, the initial EPS bearer settings should be considered as modem configuration (e.g. like the allowed modes) and so the suggestion is to add these in the desktop "Settings" application (e.g. a new WWAN device panel in GNOME Settings). I planned to work on this a while ago, but there's always been some other things to do :/ For now, if users require to change this setting, they can use mmcli manually. * For customized systems (usually without a GUI and without direct user interaction), the suggestion is to have a supervisor process (e.g. a "WWAN monitor" application) that would take care of that initial configuration of the device however it's needed in the customized system. A simple shell script using mmcli calls may be enough in most cases. I've worked on multiple such "WWAN monitor" applications for different clients which had different needs, and I've also thought of making a new FOSS project providing a generic configurable implementation for the same thing, but as before, there's always been some other things to do :D -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
