Re: u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations
Hey, > >>> 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). > > I'm looking into implementing the ModemManager portion of this in the u-blox > plugin. In looking through the code, I noticed that the cinterion plugin > implements the Modem3gpp interface (where the SetInitialEpsBearerSettings() > method is defined) in mm-broadband-modem-cinterion.c, while the u-blox > plugin's counterpart does not implement it, opting to use the generic 3gpp > code instead. Is there a good way to add the SetInitialEpsBearerSettings() > method to the u-blox plugin while still using all the rest of the generic > 3gpp code? I would appreciate any guidance. > You can extend the MMBroadbandModemUblox to implement the Modem3gpp interface, same as the Cinterion plugin does it. As soon as you extend the modem object with the new interface you're NOT losing any of the generic interface logic, but you're now able to subclass specific methods. If you're subclassing a method that has a generic implementation and you want to keep both, you need to make sure your new method calls the parent method at some point, in addition to your new logic. E.g. in the ublox MMBroadbandModemUblox, see how the logic calls iface_modem_voice_parent->enable_unsolicited_events() inside modem_voice_enable_unsolicited_events(). If you're subclassing a method that either doesn't exist in the generic implementation or you want to fully replace the generic implementation, you would not need to call the parent method. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations
Hello, >>> 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). I'm looking into implementing the ModemManager portion of this in the u-blox plugin. In looking through the code, I noticed that the cinterion plugin implements the Modem3gpp interface (where the SetInitialEpsBearerSettings() method is defined) in mm-broadband-modem-cinterion.c, while the u-blox plugin's counterpart does not implement it, opting to use the generic 3gpp code instead. Is there a good way to add the SetInitialEpsBearerSettings() method to the u-blox plugin while still using all the rest of the generic 3gpp code? I would appreciate any guidance. Thanks, Andrew ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations
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
Re: u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations
Hi Matthew, On Sat, Sep 5, 2020 at 10:27 AM Aleksander Morgado wrote: > Hey Matthew, > > > 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). Regards, Giacinto ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: u-blox TOBY-L2, TOBY-R2, and LARA-R2 new initial bearer recommendations
Hey Matthew, > 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. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
