Re: How to recover from serial device being force closed.

[Giacinto Cifelli]

Hello Jessy,

it would be great if you could verify the behavior on the main branch
(at least on the last stable 1.20.6), and give us some logs, so we can
have a better idea of the issue and how proceed, whether in a general
manner, or with some specific fixes.

Giacinto




On Mon, May 1, 2023 at 8:47 AM Jessy Exum  wrote:
>
> Hello ModemManager devs,
>
> I have encountered an issue while running ModemManager (version 1.18.4) on a 
> Cinterion PLAS8 modem. Sometimes, the serial device used for AT communication 
> with the modem is force closed (due to G_IO_HUP) without any obvious reason.
>
> Despite the modem being unreachable over the dead connection, the modem 
> remains listed in mmcli (without being marked as having an error), and any 
> ModemManager command that would send an AT command to the modem fails with an 
> error similar to:
>
> GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Connected: Cannot run 
> sequence: 'Could not open serial device ttyACM1: it has been forced close'
>
>
> When I first saw this issue, I thought it was the modem acting up (it would 
> not be the first time), but I found that restarting ModemManager recovers the 
> modem. This tells me that the modem was still functioning, and ModemManager 
> was unable (or never tried) to re-open the channel. I have not had this error 
> occur on a device with ModemManager debugging enabled, so I can not be sure 
> if reconnection is attempted (I will try to find a way to manually trigger 
> this issue so I can get better debugging).
>
> If I could reset the modem, that should cause it to be re-initiated in 
> ModemManger and likely fix the issue. But as far as I know, there is no way 
> to have ModemManager re-enumerate a modem without removing the device 
> (physically, through a modem reset, etc). Unfortunately, I am also unable to 
> recover the modem through ModemManager because a modem reset requires the 
> ability to send AT commands to the modem. Currently, the only solutions I 
> have found to recover the modem is to physically power cycle the modem (which 
> is not always possible), or to stop and restart ModemManager (inconvenient if 
> there are other modems). I may also be able to use an external script to 
> detect ModemManager getting into this state, and directly send a reset 
> command to the modem over the AT channel (without ModemManager), but I would 
> prefer if ModemManager was able to recover this on its own.
>
> The error occurs rarely/randomly enough that I am not interested in chasing 
> down why this happens (it could be the modem being flakey, electrical 
> interference, whatever). I am more interested in being able to gracefully 
> recover from this situation, so I want to know what ModemManager should be 
> doing so I can try to help fix it.
>
> Any suggestions or information would be greatly appreciated.
>
> Thanks for all the hard work in this useful tool,
> Jessy Diamond Exum
>

Re: Cinterion MV31-W modem support

[Giacinto Cifelli]

Hi Aleksander, all,

On Wed, Aug 4, 2021 at 9:56 AM Aleksander Morgado
 wrote:
>
> Hey Tomasz,
>
> >
> > Thank you. The patch works. The correct vendor and device id are presented.
> > The plugin manager still prints that it found 3 plugins to try, but now the 
> > first to try and best plugin is cinterion.
> >
>
> Please post your changes to add support for the WWAN subsystem in the
> Cinterion plugin once you have them working properly.
> Will they always have the Thales PCI vid 0x1269?

yes.

A side note: this PCIe card doesn't follow most of the
Cinterion-specific commands.
It is useful to classify it under the same plugin, for the sake of
finding it later, but it is really a standalone device.

Regards,
Giacinto

Re: Modem reset in mPLS62-w?

[Giacinto Cifelli]

Hi Aleksander,

the classic:
AT+CFUN=1,1

the question, however, would be why do you want to reboot the modem?
It looks like you want to update the FW, but Thales offers its own
method, and so not what is delivered by the chipset manufacturer.

Cheers,
Giacinto



On Tue, Jul 6, 2021 at 6:39 PM Aleksander Morgado
 wrote:
>
> Hey Giacinto,
>
> On an Intel-based mPLS62-w Cinterion module (0x1E2D:0x005D), running
> XMM7160_V1.1_MBIM_NAND_ADAPT_R, how can we trigger a modem reset
> successfully?
>
> We've tried to use the "Intel Firmware Update" MBIM service and run
> the "Modem Reboot" command, but it's either failing with "Failure" or
> the request just times out.
>
> [05 Jul 2021, 11:22:21] [Debug] [/dev/cdc-wdm0] Received message 
> (translated)...
> >> Header:
> >>   length  = 48
> >>   type= command-done (0x8003)
> >>   transaction = 24
> >> Fragment header:
> >>   total   = 1
> >>   current = 0
> >> Contents:
> >>   status error = 'Failure' (0x0002)
> >>   service  = 'intel-firmware-update' 
> >> (0ed374cb-f835-4474-bc11-3b3fd76f5641)
> >>   cid  = 'modem-reboot' (0x0001)
>
> On the equivalent Sierra Wireless modules with the same kind of XMM
> chipset, the same operation succeeds and the module reboots
> successfully; but looks like this is not happening here.
>
> So what's the best way to request the reset in the mPLS62w?
>
> Cheers!
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [RFC] Keeping send-delay for all RS232 ttys only?

[Giacinto Cifelli]

Hi Aleksander,

100ms between characters seems excessive.
In general there are the RTS/CTS on the serial line and on the virtual
serial over usb (supported by option and acm drivers) for this.
A stripped down RS232 with only TX/RX/GND could need some delay, but
it is very difficult to guess how much: in this case it would be
better to have it as a parameter.

Some modems require a different delay: between the last answer and the
following command, to have time to output some URCs in between.
At least for Cinterion modems, they don't output URCs between a
command and its response, so they must be given a chance.
The Cinterion ATC guides always specify 100ms, but it turns out that
1-2ms are enough.

Regards,
Giacinto


On Tue, May 4, 2021 at 12:34 AM Aleksander Morgado
 wrote:
>
> Hey Dan & all,
>
> The send-delay property allows us to send the characters in an AT
> command one by one, with some delay in between them. Right now the
> default configuration of the send-delay property is 100ms unless
> explicitly disabled, as it's done in several plugins.
>
> I'm wondering whether it makes sense to keep this logic as it is, or
> change the defaults a bit; e.g. we could keep the logic for plain
> RS232 modems but assume that all USB/PCI modems will be fine without
> the send delay.
>
> What do you all think?
>
> P.S. this comes in the context of this bug, which to me is due to a
> firmware issue or limitation, but anyway:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/354
>
> --
> Aleksander
> https://aleksander.es
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: UE Initiated Dedicated Bearer

[Giacinto Cifelli]

Hi Aleksander,

the business of secondary bearers is a bit murky, and so far it is
limited to VoLTE in practical usage, for which use the modems create
it automatically on top of the IMS bearer when an ATD; command is
entered (or equivalent on MBIM/QMI).

BR,
Giacinto


On Mon, Apr 26, 2021 at 7:01 PM Aleksander Morgado
 wrote:
>
> Hey,
>
> > I then came across this MR 
> > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/477?commit_id=bb6ed93dda185e679b76f77ffc67aa3a4a9eaf83
> >  which appears to be related to creating multiple bearers and configuring 
> > said profiles through MM. I didn't see anything specifically related to 
> > QOS/dedicated bearers but it made me wonder if this goal could be 
> > accomplished with MM.  I am curious if anyone has experience with creating 
> > UE Initiated Dedicated bearers with AT commands? Or, more related to the 
> > context of this forum, if there are provisions for this configuration 
> > within MM.
>
> That branch is related to creating multiple default bearers / primary
> contexts. There is no support in MM, at the moment, to create
> dedicated bearers / secondary contexts with different QoS settings.
> Would be a nice addition though, although not completely trivial (as
> the lifecycle of the dedicated/secondary is bound to the lifecycle of
> a different default/primary one).
>
> --
> Aleksander
> https://aleksander.es
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: UE Initiated Dedicated Bearer

[Giacinto Cifelli]

Hello Jack,

what is your modem?  Does it support secondary PDNs?
And - mainly - does your subscription support the QOS that you have requested?

Maybe you can switch to a more talkative error report, like AT+CMEE=2

Regards,
Giacinto

On Mon, Apr 26, 2021 at 5:43 PM Jack Broderick
 wrote:
>
> Hello,
>
> I am currently attempting to setup multiple PDN connections to support QOS by 
> creating a dedicated bearer, configuring the QOS profile and Traffic Flow 
> Template, then sending a request to the MME for this second context.
>
> I have been following the 3GPP AT command guide to no avail:
>
> 1. Define a default bearer +CGDCONT: 1,"IP","internet","0.0.0.0",0,0,0,0
> 2. Define a dedicated secondary bearer referencing the default bearer: 
> +CGDSCONT: 2,1,0,0
> 3. Define a QOS profile for the dedicated bearer: 
> AT+CGEQOS=2,2,2944,960,1,1
> 4. Define a traffic flow template for the QOS profile: 
> AT+CGTFT=2,5,0,,,"5205.5205"
> 5. Activate default bearer (successfully)
> at+cgact=1,1
> OK
>
> +CGEV: PDN ACT1
> 6. Activate dedicated bearer (unsuccessfully)
> at+cgact=1,2
> ERROR
>
> I then came across this MR 
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/477?commit_id=bb6ed93dda185e679b76f77ffc67aa3a4a9eaf83
>  which appears to be related to creating multiple bearers and configuring 
> said profiles through MM. I didn't see anything specifically related to 
> QOS/dedicated bearers but it made me wonder if this goal could be 
> accomplished with MM.  I am curious if anyone has experience with creating UE 
> Initiated Dedicated bearers with AT commands? Or, more related to the context 
> of this forum, if there are provisions for this configuration within MM.
>
> Any support/comments would be greatly appreciated.
>
> Thanks!
> Jack
>
> --
> Jack Broderick
> R Engineer
> Council Rock
> (585)505-5959
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: reuse CID=3 problem for 2G/3G?

[Giacinto Cifelli]

Hi Norbert, Aleksander,

On Wed, Mar 10, 2021 at 12:38 AM Norbert van Bolhuis
 wrote:
>
> Hi,
>
> We're using a Cinterion ELS61-E R2 modem and ModemManager-1.14.0.
> It looks like we're facing a PDN activation problem which maybe caused
> by ModemManager.
>
> Our modem is happily connected, using 4G and PDP Context ID (CID) 1.
> The CID refers to type=ipv4 and APN=blablabla.com.bla.bla.gprs.
>
> The APN to use is actually blablabla.com but MM reports:
>
>  [1613584864.390514] [modem0/bearer0] found 3 PDP contexts
>  [1613584864.391031] [modem0/bearer0]   PDP context [cid=1]
> [type='ipv4'] [apn='blablabla.com.bla.bla.gprs']
>  [1613584864.391381] [modem0/bearer0]   PDP context [cid=2]
> [type='ipv4'] [apn='']
>  [1613584864.391730] [modem0/bearer0]   PDP context [cid=3]
> [type='ipv4'] [apn='blablabla.com']
>  [1613584864.409742] [modem0/bearer0] looking for best CID
> matching APN 'blablabla.com' and PDP type 'ipv4'...
>  [1613584864.410388] [modem0/bearer0] found exact context at CID 1


In general the UE is allowed to enable an APN only once.
Some modems bridge internally when you use a different CID for attach
and for the data PDN.
AFAIK it is not the case for Intel chipsets (ELS61), and therefore MM
should use CID1 only (because it is used for the attach).

For 3G, obviously it fails: two (activated) CIDs are simply 2
contexts, and must have different APNs.

Best Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: QMI protocol error (14): 'CallFailed''

[Giacinto Cifelli]

Hi Federico,


On Sat, Feb 27, 2021 at 6:16 PM Federico Murciano
 wrote:
>
>
> Hardware:
> Quectel
> RG500QEA_VH
> firmware revision: RG500QEAAAR11A03M4G

according to the brochure it might support VoLTE.
I think the normal profile for t-mobile uses CID #2 for the combined
attach (and not CID #1).
Try to set this CID #2 empty or also with internet.telekom, and then
it might work.

Otherwise I have no other ideas :(

>
> System:
> device: /sys/devices/pci:00/:00:14.0/usb2/2-2
> drivers: qmi_wwan, option
> plugin: quectel
> primary port: cdc-wdm0
> ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (gps), wwan0 (net)
>
> The result to lsusb -t is:
>
> edge2@dai-edge2:~$ lsusb -t
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 1M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
> |__ Port 2: Dev 6, If 0, Class=Vendor Specific Class, Driver=option, 5000M
> |__ Port 2: Dev 6, If 1, Class=Vendor Specific Class, Driver=option, 5000M
> |__ Port 2: Dev 6, If 2, Class=Vendor Specific Class, Driver=option, 5000M
> |__ Port 2: Dev 6, If 3, Class=Vendor Specific Class, Driver=option, 5000M
> |__ Port 2: Dev 6, If 4, Class=Vendor Specific Class, Driver=qmi_wwan, 
> 5000M
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M

the drivers seem all ok, the device is mapped correctly.


Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: QMI protocol error (14): 'CallFailed''

[Giacinto Cifelli]

Hi Federico,

On Fri, Feb 26, 2021 at 4:52 PM Federico Murciano
 wrote:
>
> Hello everyone,
>
>
> since a while I have been experimenting this problem when I try to connect my 
> modem to the APN. It was working for a long time till a upgraded the firmware 
> and after that it always appear so I cant use ModemManager to connect the 
> modem. I just tried upgrading to ModemManager1.16 but it seems to be the same 
> (Also upgraded qmi and mbim to the last stable releases in 
> https://www.freedesktop.org/software)?
>
>
> Could someone give me a hint? Thanks. The error is the following:
>
>
> sudo mmcli -m 0 --simple-connect="apn=internet.telekom"
>
> error: couldn't connect the modem: 
> 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.CallFailed: QMI protocol 
> error (14): 'CallFailed''
>

what is your modem and can you give the "lsusb -t" result for your device?

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Howto "AT^SXRAT" (Cinterion specific)

[Giacinto Cifelli]

Hi Norbert,

> >>> We're using a Cinterion ELS61-E R2 and seem to suffer from a lot of
> >>> "packet data disconnects" and cell/rat/MO switching.
> >
> > Are you using the bare modem or on some datacard?
> > Is the power supply good?
> > And the antenna?
> > Please ask your contact in Thales (or a reseller) if there is a more
> > recent FW for your modem.  (I am part of Thales, too, but I am not
> > deep into ELS61 and all its variants and options, so it would take
> > more time to me to find out than for a more direct contact).
> >
>
> Yeah, Thales supports us with the "packet data disconnects" and
> cell/rat/MO switching issues.
> Let me be clear: about 95% of our systems have a proper working and
> stable LTE connection using the bare Cinterion ELS61-E R2 modem.
> We're trying to draw a conclusion on the remaining 5%. It doesn't look
> like it simply is a "too weak signal case" although it might have
> something to do with it.
>
> Thanks for your suggestions, we did plan to checkout the antenna (once
> more).
> About the power supply, I guess you mean it has to be a single voltage
> source (for BATT+BB and BATT+RF) and must be able to provide the peak
> current. Or is there anything else you had in mind?
>
I think it is ok like this.

> > These would be the main things to look at, to understand and fix the
> > root cause, the rest below (in  which I am going to comment anyway),
> > could be workarounds for special situations, but not the solution.
>
> That is quite an interesting and clear statement.
> So what you're saying is that the many cell/rat/MO switching we see
> cannot really be resolved by limiting the RAT?

It can, but I consider it a workaround for strange situations.  The
normal mode should be enough.
You mentioned about that this is for the 5%, which can qualify as
"strange situation".
When the applications start playing with the RAT and the operator
selection, however, they become quickly complicated due to all rules
and exceptions to them that they have to introduce.

> Not even when the signal really is too weak or when we're near the
> 2G<->3G or 3G<->4G RAT-switch-over threshold?

The standard has an hysteresis for switching, which should guarantee
some stability (the acceptable values are not fixed but instead
broadcast by each cell, so that it is possible to design smaller and
more dense cells and bigger cells).
If you are at the border of 2 or 3 cells, all equally weak, then it is
possible that you switch often.  This should be visible in the
AT^SMONI response.

> It's only
> mm_iface_modem_3gpp_register_in_network->modem_3gpp_register_in_network
> that sends "AT+COPS=0" (and factory_reset).
> I'm not sure when modem_3gpp_register_in_network is called. In a quick
> test where I let NetworkManager disconnect(DOWN) and connect(UP) the
> mobile connection it doesn't seem to be called (and so the one RAT that
> was set with --set-allowed-modes was honored)
>
> So SXRAT shouldn't follow COPS=0, OK. Then how to implement SXRAT
> for combined RAT (preferences)?
> I guess it is not "enough" to simply use SXRAT instead of COPS=,,,x in
> the function: set_current_modes?
>

AT+COPS=0 is necessary to force the modem to scan in some conditions,
and so you cannot avoid it.
>From the description of your case, it looks like you really need to
top it up with AT^SXRAT.
However making it generic in the plugin wouldn't be my choice.  Or at
least it should have a flag for the application to decide whether it
wants this quirk or not (default: no).

Best Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Howto "AT^SXRAT" (Cinterion specific)

[Giacinto Cifelli]

Hi Norbert,

>
> I don't think a COPS=0 command overrules any previously COPS-selected
> RAT (if I read the AT command manual correctly).
>

It does, it is the only way to go back to "all technologies" mode.

Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Howto "AT^SXRAT" (Cinterion specific)

[Giacinto Cifelli]

Hi Norbert, Aleksander,

>
> Giacinto, added you in CC, in case you have some suggestion.

don't worry, I am following MM, libMbim, libQmi.

>
> >
> > We're using a Cinterion ELS61-E R2 and seem to suffer from a lot of
> > "packet data disconnects" and cell/rat/MO switching.

Are you using the bare modem or on some datacard?
Is the power supply good?
And the antenna?
Please ask your contact in Thales (or a reseller) if there is a more
recent FW for your modem.  (I am part of Thales, too, but I am not
deep into ELS61 and all its variants and options, so it would take
more time to me to find out than for a more direct contact).

These would be the main things to look at, to understand and fix the
root cause, the rest below (in  which I am going to comment anyway),
could be workarounds for special situations, but not the solution.

> > We're advised to force the modem to use 3G/2G (or 4G/2G) Radio Access
> > Technology with the AT^SXRAT command.

MM doesn't use (as of today) this command, so you are guaranteed that
the modem will remember the settings.
AT^SXRAT allows to set up to 3 preferences, which can also be
combined.  I haven't tested on ELS61, but PLS62 should be the same.

> > We've been told the "AT+COPS=0" may reset SXRAT settings.

I have checked on the ATC, and indeed AT+COPS=,,,x (or AT+COPS=0) will
change the preferences, as well as AT^SXRAT, and the last-sent will
define the behavior.

> >
> > I've tried to do this via:
> > mmcli -m 0 --set-allowed-modes='2g|4g' --set-preferred-mode='4g'
> >
> > but it doesn't work and even if it would, I'm not sure this means the
> > "AT^SXRAT" command alwaysf ollows "AT+COPS=0" nicely.
> >
> > I see no "AT^SXRAT" in the source code, so I guess "AT^SXRAT" is a
> > Cinterion specific command that isn't supported yet.
> >
> > I do like to use the "AT^SXRAT" command.
> >
> > So I'd like to do a "AT^SXRAT" after each "AT+COPS=0". This involves
> > changing modem_3gpp_register_in_network, is this the right thing to do?
> >
> > If not, how to best use the "AT^SXRAT" command?
> >
>
> The Cinterion plugin currently uses AT+COPS also to configure access
> technology; e.g. if 4G-only is requested, we would run AT+COPS=,,,7
>
> Does this COPS based logic to configure access tech not work in the
> ELS61? Is ^SXRAT the only way to do that in the ELS61? If ^SXRAT is
> the only way to do it, we could upgrade the Cinterion plugin to use
> it. But I'm not sure that sending the SXRAT after each COPS would make
> much sense; is there no other way to do that?
>
> Also, if COPS=0 resets the desired access tech, I wonder if the same
> is currently happening with our already available COPS based access
> tech selection logic.

AT^SXRAT could be used for Intel chipsets (ELS61, PLS62, ...), instead
of the AT^SCFG="Radio/Band..." commands and/or AT+COPS=,,,x (and so in
the --set-allowed-modes command)
However AT+COPS=0 might be sent at startup if the modem reports +COPS:
2, and in this case it will start the registration/attach, but also
reset the preferred technologies.

I don't really agree to append AT^SXRAT to AT+COPS, that would make
the modem search twice in most of the cases, and I know that it is
particularly slow on this chipset under some conditions.
And so it would maybe solve a specific problem, but introduce others.

If you want a single tech, a better solution would be to track that in
the code where AT+COPS=0 is sent and use AT+COPS=0,,,x instead.

Best Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [RFC] Exposing profiles (provisioned contexts) in the API

[Giacinto Cifelli]

Hi Aleksander,


On Tue, Jan 19, 2021 at 11:06 AM Aleksander Morgado
 wrote:
>
> Hey Giacinto,
>
> >
> > for Cinterion modems that support the profiles, there is a special
> > command to read them (ATI61, no mbim equivalent, maybe qmi but I
> > wouldn't know it; and an at^scfg? option to read the current one) as a
> > list and would fit well with option 2.
> > The second option would also sit better in the context of a get/set
> > option, because clearly option 3 wouldn't set it globally, and option
> > 1 would be just informative.
> >
> > For Cinterion modems, the profiles have been experimented with for a
> > few years, so old modems restart when a new profile is selected (for
> > example, the PLAS9-X).
> > Also, for all Cinterion modems supporting profile selection, they are
> > normally in automatic mode and the property is indeed read-only.  It
> > becomes writeable by changing the flag automatic/manual.
> >
> > I don't know exactly how other manufacturers work, but there are
> > chances that it is implemented in a similar way, because the profiles
> > were introduced by the chipset manufactures (initially) to deal with
> > the various VoLTE flavours.
> >
>
> I believe we're not talking about the same thing, maybe we chose the
> "profile" name poorly. The suggestion to manage the profiles in the
> merge request is to be able to manage the settings for the PDP
> contexts / EPS bearers stored in the modem. E.g. when you run
> AT+CGDCONT? you get the list of contexts/bearers settings reported by
> the module, that is what we would call "profiles" in the API. I don't
> think this is what you were referring to, right? Maybe we should
> choose a different name to avoid confusions.
>

I am not sure it is different.
If a MM "profile"  is a set of APN settings, to be set in the modem
one-by-one with eg. CGDCONT, it is different.
A modem "profile" is this (ie: a set of APN, including attach APN,
data APN, administrative APN, IMS apn, ...), plus additional settings
related to VoLTE (SIP/SDP format and datagrams), SMS handling (over
IMS, SGs, CSFG), audio codecs.
All these settings are applied at once, depending on the inserted SIM.
I know that Thales changes the required settings, and have heard that
Sierra selects a whole different image instead (like a different
virtual modem).  Not sure about the handling by other manufacturers.

BR,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: On allowing bearer creation from PDP context ID.

[Giacinto Cifelli]

Hello Jessy,

On Sat, Sep 5, 2020 at 10:11 AM Jessy Exum 
wrote:

> Hello everyone, I hope this finds you well.
>
> I have been working on getting a product certified with Verizon, but
> failed because my first implementation did not handle their OTA-DM (Over
> the Air Device Management) 
> behavior. This stage of certification relies heavily on creating bearers
> out of PDP context IDs (Verizon handles most of the messy bits in setting
> those contexts for you in the modem).
>
> My current solution is to manually read the PDP contexts off of the device
> with AT+CGDCONT=?, reading out the Verizon mandated PDP context, and then
> asking ModemManager to create a bearer out of that bearer configuration
> (which causes ModemManager to scan the list of contexts and find an exact
> match with the one we just read). This works, but it is cumbersome, and I
> hear that more networks are planning to move to a similar process in the
> future (Sprint already has, though I heard that is a little half baked).
>
> *Because of this, I feel it would be worthwhile to allow bearers to be
> created by specifying only a PDP context (and perhaps even an API backed
> way to inspect them).* This would make passing Verizon certification a
> lot less hackey than it currently is.
>
> I am happy to do as much of the work as necessary, but I want to know the
> community's opinion of this base proposal, and make sure anything that is
> built actually solves a problem and will be accepted.
>
> *Brief overview of the OTA-DM procedure
> :*
> I am not a cellular expert, so please forgive and correct any inaccuracies
> I may let slip in.
>
> For those unfamiliar (I know I was), Verizon has a procedure called OTA-DM
> for automatically determining the APN to use for a SIM card.
>
> Verizon has all compatible modems preloaded with a series of PDP contexts.
> These PDP Contexts are only available when the modem is running Verizon
> firmware (which is triggered when a Verizon SIM card is inserted).
>
> Verizon expects the initial attach bearer will be created from PDP context
> #1. This first bearer is only for notifying Verizon that we have attached,
> and will never pass user traffic.
>
> Once this initial bearer connects, Verizon and the modem talk for a while.
> In this conversation:
>
>1. The modem reports details about its SIM card to Verizon,
>2. Verizon checks its database to see if this is the last SIM card it
>saw in this modem,
>3. if this is not the SIM Verizon expected, Verizon will update the
>modem's PDP contexts to the most up to date settings for this SIM.
>
> To clarify, this process will not happen every time you connect. A modem
> has to connect to Verizon with a different SIM card for Verizon to do this
> process again (flipping between SIMs for each connection would cause this
> process to happen for each connection).
>
> After this process completes, Verizon expects that the modem will connect
> using PDP context #3 for the first data bearer. APNs are not touched by the
> user, only Verizon defined PDP contexts. I found out the hard way that you
> will fail your device certification if you do not connect using the 3rd
> context.
> *END OTA-DM description.*
>
> Any input on if we should allow creation of bearers from PDP context
> numbers to support new cellular network features would be appreciated.
>

There is an embryo of what you need in the SetInitialEpsBearerSettings().
For Cinterion modems on VZW networks, the latest MM upstream considers that
the modem will attach with CID#3. CID#1 is not used, but also should not be
overwritten.
I think CID#1 is used internally and transparently.

Ideally it should be possible to specify only the CID for activating a PDN,
however it is non-portable: modems using MBIM instead of AT commands don't
support the notion of CID at all.
I am not sure how VZW specifies the operations for these modems. I know
that for Cinterion modems AT and MBIM coexist whenever possible, but on the
MBIM_CONNECT there is no CID parameter, only APN (and
username/password/...).

Best 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

[Giacinto Cifelli]

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

inhibit network interface over slow link

[Giacinto Cifelli]

Dear all,

I have a problem with some modems that don't support USB <2.00 for the
network interface.
In this case, PPP must be used.

It is a modem-specific limitation, and maybe it should have a udev flag:
MM_USE_PPP_OVER_USB1, or something more creative.

The question is how to recognize the overall USB version . The udev USB
version property for the device  will be >=2.00, but along the way, either
the root hub or an intermediate one, will bring the effective version down.
The speed property is "cumulative": if a hub along the way is 12Mbps, then
the final speed for the device is shown as 12Mbps:

  looking at device
'/devices/pci:00/:00:14.0/usb3/3-2/3-2.4/3-2.4.3/3-2.4.3.2/3-2.4.3.2:1.0/tty/ttyACM4':
KERNEL=="ttyACM4"
SUBSYSTEM=="tty"
DRIVER==""

  looking at parent device
'/devices/pci:00/:00:14.0/usb3/3-2/3-2.4/3-2.4.3/3-2.4.3.2/3-2.4.3.2:1.0':
KERNELS=="3-2.4.3.2:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="cdc_acm"
ATTRS{authorized}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceClass}=="02"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bInterfaceProtocol}=="01"
ATTRS{bInterfaceSubClass}=="02"
ATTRS{bNumEndpoints}=="01"
ATTRS{bmCapabilities}=="2"
ATTRS{iad_bFirstInterface}=="00"
ATTRS{iad_bFunctionClass}=="02"
ATTRS{iad_bFunctionProtocol}=="01"
ATTRS{iad_bFunctionSubClass}=="02"
ATTRS{iad_bInterfaceCount}=="02"
ATTRS{interface}=="CDC Abstract Control Model (ACM)"
ATTRS{supports_autosuspend}=="1"

  looking at parent device
'/devices/pci:00/:00:14.0/usb3/3-2/3-2.4/3-2.4.3/3-2.4.3.2':
KERNELS=="3-2.4.3.2"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{authorized}=="1"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{bConfigurationValue}=="1"
ATTRS{bDeviceClass}=="ef"
ATTRS{bDeviceProtocol}=="01"
ATTRS{bDeviceSubClass}=="02"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{bMaxPower}=="500mA"
ATTRS{bNumConfigurations}=="1"
ATTRS{bNumInterfaces}=="12"
ATTRS{bcdDevice}=="0318"
ATTRS{bmAttributes}=="a0"
ATTRS{busnum}=="3"
ATTRS{configuration}==""
ATTRS{devnum}=="79"
ATTRS{devpath}=="2.4.3.2"
ATTRS{idProduct}=="0065"
ATTRS{idVendor}=="1e2d"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Cinterion"
ATTRS{maxchild}=="0"
ATTRS{product}=="LTE Modem"
ATTRS{quirks}=="0x0"
ATTRS{removable}=="unknown"
ATTRS{serial}=="8d8f52c8"
ATTRS{speed}=="12"
ATTRS{urbnum}=="463"
ATTRS{version}==" 2.10"


It is possible to cross the entire parent chain, and then get the minimum
version. I don't have a root hub USB 1.x at hand, but I have found an old
external USB hub 1.1, and connected this way: device - hub1.1 - hub2.0 -
roothub2.0:
name: ttyACM4, version:   NULL, minversion: NULL
name: ttyACM4, version:   NULL, minversion: NULL
name: ttyACM4, version:   2.10. minversion:  2.10
name: ttyACM4, version:   1.10. minversion:  1.10
name: ttyACM4, version:   2.00. minversion:  1.10
name: ttyACM4, version:   2.00. minversion:  1.10
name: ttyACM4, version:   2.00. minversion:  1.10
name: ttyACM4, version:   NULL, minversion:  1.10
name: ttyACM4, version:   NULL, minversion:  1.10

I have placed some code in mm-kernel-device-udev.c to obtain the chain
above.

The question is whether there is a better way to do this, possibly without
touching the udev implementation.
Or whether it is acceptable to read the speed property instead of
rebuilding the effective usb version: is it ok to replace a variable for
another here for all foreseeable cases?

Thank you all in advance,
Kind Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: LTE attach settings

[Giacinto Cifelli]

Hi Aleksander,


On Thu, Jul 23, 2020 at 8:28 AM Aleksander Morgado
 wrote:
>
> Hey
>
> > > > I need to set up the default LTE bearer settings: APN, type of APN,
> > > > authentication parameters, in the Cinterion plugin.
> > > >
> > > > And for this, I am going to add the two methods:
> > > > void (* set_initial_eps_bearer_settings)
> > > > (MMIfaceModem3gpp *self, ..
> > > > gboolean (* set_initial_eps_bearer_settings_finish)
> > > > (MMIfaceModem3gpp *self, ..
> > > >
> > > > Is this the right way to do it? I see that nobody implemented it so
> > > > far. Is this called for mbim or qmi?
> > > >
> > >
> > > This is currently implemented for MBIM devices, because in MBIM
> > > devices there are explicit APIs to set them without needing to worry
> > > about what specific CID number we're touching.
> > >
> > > > I will have to run the following sequence:
> > > > -go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > > > necessary because the CID might be locked or not taken into account
> > > > immediately (in case there is an attach attempt ongoing).
> > > > -set AT+CGDCONT for the right CID (normally 1)
> > > > -set AT^SGAUTH for the same CID
> > > > -go back to AT+CFUN=1.
> > > >
> > > > Is this ok to you?
> > >
> > > The requirement to run CFUN=4 before and CFUN=1 after seems very
> > > generic to me; at the end we're changing the APN settings used during
> > > LTE registration, so it is assumed the device needs to re-register. I
> > > say this because it may make sense to move that logic "up" to the
> > > Modem3gpp interface, so that the interface itself puts the modem in
> > > low-power mode before the change and puts it back into full-power mode
> > > after the change. But don't worry about that, this can be done later,
> > > if you do the CFUN=4/1 yourself in the cinterion plugin for now it's
> > > ok.
> > >
> >
> > ok, I think that it should also be moved up, but this requires further
> > consideration.
> > For example in case of SIM hot swap: then the entire state should be
> > moved back to that point.
>
> Do not worry at all about SIM hot swap, because a SIM hot swap
> triggers a full modem re-probe: the modem is removed from DBus and
> re-probed from scratch, and then re-exposed in DBus with a new object
> path. At this point, SIM hot swap is always seen in MM as a full modem
> power cycle, even if there isn't such power cycle really.
>

This is exactly the behavior that would be necessary.
So it is already in place. Cool!

> >
> > > >
> > > > Instead of CFUN=4/1 also COPS=2/0 could be used, but I prefer the 
> > > > former.
> > > >
> > >
> > > The only issue I see is the selection of the "right CID" in CGDCONT.
> > > As you said, it is normally 1, but as we've already found in the past
> > > it may be operator dependent; e.g. wasn't it CID=4 for Verizon?
> > >
> >
> > Cinterion modules use CID=3 for VZW, CID=2 for T-Mobile Germany with
> > VoLTE, 1 in all other cases.
>
> Is this a choice done by the manufacturer, or a choice done by the
> carrier, or a mix of both?

for t-mobile, I think it is a chipset decision, but for VZW it is an
intrusive choice of the carrier,
and so the manufacturers have to comply to get access to the network.
Due to this and other requirements, VZW products are limited (of
course most the handsets for the US market follow the requirements,
but they are in another league), so it is not surprising you don't
hear much about it.

>
> > I intend to filter for this by querying the current VoLTE profile with
> > AT^SCFG="MEopMode/Prov/Cfg".
> > This would go between steps 1 and 2 above, but for the general
> > discussion I left this out as an implementation detail.
> >
>
> I'm trying to understand whether this is a change we require to do in
> a more generic way (if the CIDs are chosen by carrier) or just
> specific in this plugin (if the CIDs are chosen by manufacturer or by
> both). CID=3 for Verizon is the first time I've seen, IIRC, so not
> sure.
>

I am not sure I can help you here directly. I will anyway implement
the entire logic for it in the Cinterion plugin, then we can decide
whether it makes sense to broaden it.

> > > I believe that other vendors use other approaches, even with separate
> > > APIs, e.g. the u-blox TOBY-L2 had specific commands for this IIRC.
> >
> > I saw uBlox specifications, and they use CID=1 and CID=4 quite often.
> > It is not impossible that they also use a special API in some models.
> > Some XMM modems use CID=0 (as would be prescribed by the 3GPP 27.007).
> >
>
> Oh, so 3GPP specs specify CID=0 for the initial LTE default bearer
> settings, but almost no manufacturer implements it that way? :( CID=0
> would be a proper default then, but we would need to subclass that in
> each plugin that doesn't follow that.
>

Yes, but only Intel implements it, and only on some products, as far
as I know. And Intel is going out of market soon.
So the reference remains Qualcomm, whose 

Re: LTE attach settings - CFUN

[Giacinto Cifelli]

On Thu, Jul 23, 2020 at 8:16 AM Aleksander Morgado
 wrote:
>
> > > > > I will have to run the following sequence:
> > > > > -go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > > > > necessary because the CID might be locked or not taken into account
> > > > > immediately (in case there is an attach attempt ongoing).
> > > > > -set AT+CGDCONT for the right CID (normally 1)
> > > > > -set AT^SGAUTH for the same CID
> > > > > -go back to AT+CFUN=1.
> > > > >
> >
> > I am implementing this sequence, and will submit soon (I hope), but I
> > am stepping into a problem with CFUN:
> >
> > ModemManager[2541]:  [1595452432.501830] [modem0/ttyACM0/at]
> > --> 'AT+CFUN=1'
> > ModemManager[2541]:  [1595452432.533882] [modem0/ttyACM0/at]
> > <-- 'OK^SYSSTART'
> > ModemManager[2541]:  [1595452452.512543] [modem0] (cinterion)
> > error in step = 5
>
> Maybe you should add a regex to ignore the ^SYSSTART URC.

not sure how to do it. Any examples I can look at?
I have also noticed that it could be a known issue, because in
src/mm-broadband-modem.c: modem_power_up(), the error is not checked,
and the command
mm_base_modem_at_command (MM_BASE_MODEM (self),
  "+CFUN=1",
  5,
  FALSE,
  NULL,
  NULL);
takes 5 seconds  and then continues. It works faster if the modem is
already in cfun=1, because then there is no urc, only ok, but takes 5
seconds (the timeout) when changing from another mode.

> But it's a
> bit strange I must say, would need to look at the code, because the
> kind of errors we get with URCs is when the URCs get interleaved
> before the OK.
>

Yes, this is disrupting all right, but it is avoided in Cinterion
modems just because of the interpretation issues.

Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: LTE attach settings - CFUN

[Giacinto Cifelli]

Hi Aleksander,

> >
> > > I will have to run the following sequence:
> > > -go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > > necessary because the CID might be locked or not taken into account
> > > immediately (in case there is an attach attempt ongoing).
> > > -set AT+CGDCONT for the right CID (normally 1)
> > > -set AT^SGAUTH for the same CID
> > > -go back to AT+CFUN=1.
> > >

I am implementing this sequence, and will submit soon (I hope), but I
am stepping into a problem with CFUN:

ModemManager[2541]:  [1595452432.501830] [modem0/ttyACM0/at]
--> 'AT+CFUN=1'
ModemManager[2541]:  [1595452432.533882] [modem0/ttyACM0/at]
<-- 'OK^SYSSTART'
ModemManager[2541]:  [1595452452.512543] [modem0] (cinterion)
error in step = 5
ModemManager[2541]:  [1595452452.512754] [modem0/ttyACM0/at]
device open count is 0 (close)
ModemManager[2541]:  [1595452452.512789] [modem0/ttyACM0/at]
closing serial port...
ModemManager[2541]:  [1595452452.514960] [modem0/ttyACM0/at]
serial port closed

MM doesn't seem to get the OK if it is immediately followed by an URC,
and this is the case for both CFUN=4 and CFUN=1.
What can I do to fix it?

> > >
> > > Instead of CFUN=4/1 also COPS=2/0 could be used, but I prefer the former.
> > >

I have also tried this, except that the modem I am using is annoying,
because on AT+CFUN=0 takes a lot of time.
I would therefore prefer to use AT+CFUN.

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: LTE attach settings

[Giacinto Cifelli]

Hi Aleksander,

On Wed, Jul 22, 2020 at 3:47 PM Aleksander Morgado
 wrote:
>
> Hey Giacinto!
>
> >
> > I need to set up the default LTE bearer settings: APN, type of APN,
> > authentication parameters, in the Cinterion plugin.
> >
> > And for this, I am going to add the two methods:
> > void (* set_initial_eps_bearer_settings)
> > (MMIfaceModem3gpp *self, ..
> > gboolean (* set_initial_eps_bearer_settings_finish)
> > (MMIfaceModem3gpp *self, ..
> >
> > Is this the right way to do it? I see that nobody implemented it so
> > far. Is this called for mbim or qmi?
> >
>
> This is currently implemented for MBIM devices, because in MBIM
> devices there are explicit APIs to set them without needing to worry
> about what specific CID number we're touching.
>
> > I will have to run the following sequence:
> > -go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > necessary because the CID might be locked or not taken into account
> > immediately (in case there is an attach attempt ongoing).
> > -set AT+CGDCONT for the right CID (normally 1)
> > -set AT^SGAUTH for the same CID
> > -go back to AT+CFUN=1.
> >
> > Is this ok to you?
>
> The requirement to run CFUN=4 before and CFUN=1 after seems very
> generic to me; at the end we're changing the APN settings used during
> LTE registration, so it is assumed the device needs to re-register. I
> say this because it may make sense to move that logic "up" to the
> Modem3gpp interface, so that the interface itself puts the modem in
> low-power mode before the change and puts it back into full-power mode
> after the change. But don't worry about that, this can be done later,
> if you do the CFUN=4/1 yourself in the cinterion plugin for now it's
> ok.
>

ok, I think that it should also be moved up, but this requires further
consideration.
For example in case of SIM hot swap: then the entire state should be
moved back to that point.

> >
> > Instead of CFUN=4/1 also COPS=2/0 could be used, but I prefer the former.
> >
>
> The only issue I see is the selection of the "right CID" in CGDCONT.
> As you said, it is normally 1, but as we've already found in the past
> it may be operator dependent; e.g. wasn't it CID=4 for Verizon?
>

Cinterion modules use CID=3 for VZW, CID=2 for T-Mobile Germany with
VoLTE, 1 in all other cases.
I intend to filter for this by querying the current VoLTE profile with
AT^SCFG="MEopMode/Prov/Cfg".
This would go between steps 1 and 2 above, but for the general
discussion I left this out as an implementation detail.

> I believe that other vendors use other approaches, even with separate
> APIs, e.g. the u-blox TOBY-L2 had specific commands for this IIRC.

I saw uBlox specifications, and they use CID=1 and CID=4 quite often.
It is not impossible that they also use a special API in some models.
Some XMM modems use CID=0 (as would be prescribed by the 3GPP 27.007).

For the rest, the great majority use CID=1, I believe because it is
the most common setting from the chipset makers.

>
> At this point, and given that it is everyday more common to have the
> requirement to change the initial LTE bearer settings, I wouldn't mind
> to have this logic with the "far from perfect" initial default of
> reconfiguring CID=1. I just got this very same requirement just
> yesterday debugging connectivity with an Orange Morocco SIM, so I'm
> sure there are users out there also requiring this kind of
> configuration.
>

Sound good.
Only I am not sure how you would do it in MM.
The modem is set to CFUN=1 as soon as it is mapped, and the APN and
other parameters have to be supplied via dbus, and so after the modem
has already attempted to attach.

Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

LTE attach settings

[Giacinto Cifelli]

Dear all,

I need to set up the default LTE bearer settings: APN, type of APN,
authentication parameters, in the Cinterion plugin.

And for this, I am going to add the two methods:
void (* set_initial_eps_bearer_settings)
(MMIfaceModem3gpp *self, ..
gboolean (* set_initial_eps_bearer_settings_finish)
(MMIfaceModem3gpp *self, ..

Is this the right way to do it? I see that nobody implemented it so
far. Is this called for mbim or qmi?

I will have to run the following sequence:
-go in AT+CFUN=4 (airplane mode with SIM connected). This is
necessary because the CID might be locked or not taken into account
immediately (in case there is an attach attempt ongoing).
-set AT+CGDCONT for the right CID (normally 1)
-set AT^SGAUTH for the same CID
-go back to AT+CFUN=1.

Is this ok to you?

Instead of CFUN=4/1 also COPS=2/0 could be used, but I prefer the former.

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Memory Full Error

[Giacinto Cifelli]

Hi Bruce,

On Sun, Jul 19, 2020 at 4:51 AM Bruce  wrote:
>
> Please excuse me if this is an inappropriate place to post this,
> I searched around for a MM User List and this was all I found.
>
> I'm having trouble sending and receiving SMS messages.
> I have done a number of searches for this error message
> and it has turned up only one reference that was no help.
> I have tried uninstalling (complete), deleting all associated
> files (data and lib), and then re-installing, no joy...  :-(
>
> The error message I am getting every time I try to SEND is,
>
> "(GDBus.Error:org.freedesktop.libmbim.Error.Status.MemoryFull: Couldn't send 
> SMS part: MemoryFull)"

the memory full is the SMS storage memory.
You simply need to delete some SMSs from the modem or from the SIM.


>
> and I am unable to receive any text either...
>
> What do I need to do to get my SMS working again ?
> Modem is a Sierra Wireless 340U with PureTalkUSA
> and it worked fine for 8 months, until about a month ago...
>
> I am using modem-manager-gui v0.0.19.1
> and ModemManager v0.0.19.1
> under Linux Mint 19.3 Cinnamon v4.4.8, muffin/LightDM
> Kernel v5.3.0-62-generic
> on an Intel© Core™ i3-2350M CPU @ 2.30GHz × 2 Laptop
> with 7.7 GB RAM and 462 GB available on the SSD...
>
> advTHANKSance
>
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: "port not candidate" error message with DELL Wireless 5570 (aka Sierra Wireless AirPrime 7W5P6)

[Giacinto Cifelli]

Hey,

On Wed, Jun 17, 2020 at 2:19 PM Aleksander Morgado
 wrote:
>
> Hey!
>
> >
> > but it seems the ID_MM_CANDIDATE variable isn't there.
> >
> > $ udevadm info /dev/cdc-wdm0
> > P: 
> > /devices/pci:00/:00:1d.0/usb3/3-1/3-1.6/3-1.6:2.12/usbmisc/cdc-wdm0
> > N: cdc-wdm0
> > L: 0
> > E: 
> > DEVPATH=/devices/pci:00/:00:1d.0/usb3/3-1/3-1.6/3-1.6:2.12/usbmisc/cdc-wdm0
> > E: DEVNAME=/dev/cdc-wdm0
> > E: MAJOR=180
> > E: MINOR=0
> > E: SUBSYSTEM=usbmisc
> >
>
> Oh wow, this is strange. And even more strange, I just found out a
> very similar problem in my own host system running Arch, this time
> with a net port instead of a cdc-wdm port:
>
> ModemManager[461452]:  [1592395909.393490] [base-manager]
> adding port wwan0 at sysfs path:
> /sys/devices/pci:00/:00:14.0/usb1/1-8/1-8.2/1-8.2:1.10/net/wwan0
> ModemManager[461452]:  [1592395909.394961] [base-manager] port
> wwan0 not candidate
>

could there be some bad udev file breaking the chain of rules?
check
   journalctl --boot |grep '\ udev\:'

>
> --
> Aleksander
> https://aleksander.es
> ___
> ModemManager-devel mailing list
> ModemManager-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

cinterion radio bands

[Giacinto Cifelli]

Dear Aleksander, all,

I am starting a new thread because I think the previous one was
filtered as spam, maybe when I added the log?

I collected some more modems and did more tests, and with an ALS3
(supported maybe as PLS8), which uses the single AT^SCFG: "Radio/Band"
value for all technologies, the crash of the demon does not occur.
And this with the patch I am developing, not only with the legacy one.

Therefore I thing there must be something wrong with my memory
management in the new code, but I don't see where, nor Aleksander's
review highlighted some problems in that sense.

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion radio bands

[Giacinto Cifelli]

Hey Aleksander,

thank you for your answer.

On Wed, May 20, 2020 at 11:37 AM Aleksander Morgado
 wrote:
>
> Hey Giacinto,
>
> > I have finally submitted a merge request for the band reading and
> > setting for Cinterion Modems.
> >
> > Not sure whether is it good quality, thou. I would appreciate a review
> > and comments.
> > Starting for example from the naming of the udev variable, and then
> > the use of other variables to track formats, and the existing 2g/3g
> > one, also used for differentiating models.
> > I am wondering if there is a smart way to reduce all these variables
> > and corresponding if()'s to something more structured.
> >
> > Apart from that, the code works.
> > The Band setting also goes well, but...
> > 1) the command is vrry slow (about 30-50 seconds) on PLS62, but
> > there seems to be a problem with MM itself, because I have set a
> > timeout to 3 minutes, and sometimes MM still times out, but the
> > command has already succeeded and the bands are changed.
> > Any idea why the command would timeout? is there a maximum timeout
> > that MM would tolerate? How to go round this limitation?
>
> Are you testing this with mmcli? If so, mmcli has a default timeout
> for the DBus requests of 30s. If you believe a command you run may
> take longer, you need to use --timeout to explicitly request a longer
> timeout of the mmcli command. The mmcli timeout is orthogonal to the
> actual AT command timeout; so even if you configure the AT command to
> timeout at 120s, the mmcli command may timeout earlier for the user
> (but the AT command would still be running in MM until the 120s
> timeout).
>

I prefer d-feet (under Ubuntu) for unit tests, because it shows me all
options and I am sure I am making a single dbus call, so that I have a
fine control on the sequence.
Nevertheless, you are right: it seems to be a timeout on the client side.

>
> > It looks like that the PLS62 applies the bands at once, rescans
> > (so also it de-registers and re-registers), and I think this is the
> > reason why it is slow.
> >
>
> Possibly. In this case, we need to make sure we reload registration
> settings after setting bands. I believe this is already the case, but
> we should recheck.

it looks like it re-reads the current bands, but not the registration
status & co. See trace below.

>
> > 2) If I reduce the current mask, say from
> > [1,2,3,4,5,7,9,10,11,12,31,32,33,34,35,37,38,42,48,49,50,58,219]
> > to [1,2,10,11,12,48,49,50,58], and I re-read the CurrentBands
> > property, a realloc fails and MM crashes.
>
> Oh? the daemon crashes? How are you reading the properties, via custom
> DBus commands?

d-feet uses the standard GetProperty when it recognizes the
properties, as it is the case for ModemManager.
But looking at the timestamps below, maybe MM crashed on the
SetCurrentBands already, and the effects were only visible on the next
action?

>
> > It seems to be completely on the dbus handling, and also
> > independent from this patch.
> > I have traced it with gdb, but wasn't able to get to the root of
> > the issue, because the stack starts from the dbus get property call.
> > If I don't read the property, it works fine.
> > Also, if the setting is done in the other direction (from less to
> > more bands), then it works.
> > Any idea?
>
> Could you please share how exactly you're triggering the error, and
> what's that gdb stacktrace?
>

Please see at the end of the trace below

ModemManager[17390]:  [1589971907.559079] [modem0] setting new
list of bands: egsm, dcs, utran-8, utran-9, utran-2, eutran-18,
eutran-19, eutran-20, eutran-28
ModemManager[17390]:  [1589971907.559231] [modem0/ttyACM0/at]
opening serial port...
ModemManager[17390]:  [1589971907.560245] [modem0/ttyACM0/at]
setting up baudrate: 57600
ModemManager[17390]:  [1589971907.560289] [modem0/ttyACM0/at]
no flow control explicitly requested for device
ModemManager[17390]:  [1589971907.560372] [modem0/ttyACM0/at]
device open count is 1 (open)
ModemManager[17390]:  [1589971907.560466] [modem0/ttyACM0/at]
--> 
'AT^SCFG="Radio/Band/2G","0030007800300030003000300030003000310034";^SCFG="Radio/Band/3G","0030007800300030003000300030003100380032";^SCFG="Radio/Band/4G","0030007800300038003000450030003000300030"'
ModemManager[17390]:  [1589971908.596000] [modem0/ttyACM0/at]
<-- '^SCFG:
"Radio/Band/2G","0030007800300030003000300030003000310034"'
ModemManager[17390]:  [1589971927.537323] [modem0/ttyACM0/at]
<-- '^SCFG:
"Radio/Band/3G","0030007800300030003000300030003100380032"'
ModemManager[17390]:  [1589971935.727578] [modem0/ttyACM0/at]
<-- '^SCFG:
"Radio/Band/4G","0030007800300038003000450030003000300030"OK'
ModemManager[17390]:  [1589971935.727753] [modem0/ttyACM0/at]
device open count is 2 (open)
ModemManager[17390]:  [1589971935.727790] [modem0/ttyACM0/at]
device open count is 1 (close)
ModemManager[17390]:  [1589971935.727820] [modem0/ttyACM0/at]
--> 'AT^SCFG?'
ModemManager[17390]:  [1589971935.752061] 

Re: Cinterion radio bands

[Giacinto Cifelli]

Hey Aleksander, all,

I have finally submitted a merge request for the band reading and
setting for Cinterion Modems.

Not sure whether is it good quality, thou. I would appreciate a review
and comments.
Starting for example from the naming of the udev variable, and then
the use of other variables to track formats, and the existing 2g/3g
one, also used for differentiating models.
I am wondering if there is a smart way to reduce all these variables
and corresponding if()'s to something more structured.

Apart from that, the code works.
The Band setting also goes well, but...
1) the command is vrry slow (about 30-50 seconds) on PLS62, but
there seems to be a problem with MM itself, because I have set a
timeout to 3 minutes, and sometimes MM still times out, but the
command has already succeeded and the bands are changed.
Any idea why the command would timeout? is there a maximum timeout
that MM would tolerate? How to go round this limitation?
It looks like that the PLS62 applies the bands at once, rescans
(so also it de-registers and re-registers), and I think this is the
reason why it is slow.

2) If I reduce the current mask, say from
[1,2,3,4,5,7,9,10,11,12,31,32,33,34,35,37,38,42,48,49,50,58,219]
to [1,2,10,11,12,48,49,50,58], and I re-read the CurrentBands
property, a realloc fails and MM crashes.
It seems to be completely on the dbus handling, and also
independent from this patch.
I have traced it with gdb, but wasn't able to get to the root of
the issue, because the stack starts from the dbus get property call.
If I don't read the property, it works fine.
Also, if the setting is done in the other direction (from less to
more bands), then it works.
Any idea?

Thank you,
Regards,
Giacinto



On Mon, May 18, 2020 at 4:55 PM Aleksander Morgado
 wrote:
>
> Hey,
>
> > > > > > > > > > I am trying to update the code for the Radio/Bands of 
> > > > > > > > > > Cinterion
> > > > > > > > > > Today in the code there is a parser for this format (only 
> > > > > > > > > > for the test part):
> > > > > > > > > > AT^SCFG=?
> > > > > > > > > > ^SCFG: "Radio/Band",("1-479","0-1")
> > > > > > > > > >
> > > > > > > > > >  the PLS62 reports:
> > > > > > > > > > under GSM charset:
> > > > > > > > > > AT^SCFG=?
> > > > > > > > > >  ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
> > > > > > > > > >  ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
> > > > > > > > > >  ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
> > > > > > > > > > and under UCS2 charset:
> > > > > > > > > >AT^SCFG=?
> > > > > > > > > >  ^SCFG: 
> > > > > > > > > > "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> > > > > > > > > >  ^SCFG: 
> > > > > > > > > > "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> > > > > > > > > >  ^SCFG: 
> > > > > > > > > > "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> > > > > > > > >
> > > > > > > > > > To determine the charset, I use some heuristics on string 
> > > > > > > > > > length and
> > > > > > > > > > prefix (0x aka 00300078). Note also that a model returns 
> > > > > > > > > > lowercase
> > > > > > > > > > hexa while another uppercase...
> > > > > > > > >
> > > > > > > > > Isn't mm_broadband_modem_get_current_charset () not returning 
> > > > > > > > > the
> > > > > > > > > correct thing? I would definitely avoid doing heuristics to 
> > > > > > > > > detect
> > > > > > > > > charset if possible.
> > > > > > > >
> > > > > > > Is there not a CSCS=? check during initialization, plus a CSCS=X 
> > > > > > > set
> > > > > > > command after that? I believe that ModemManager tries to set the
> > > > > > > "best" charset of the ones available. Do you have a full debug 
> > > > > > > log to
> > > > > > > check how that is happening?
> > > > > > >
> > > > > > > > The only time it is called is after setting it, and it looks 
> > > > > > > > like it
> > > > > > > > requires a dbus input, and therefore can only happen after the 
> > > > > > > > modem
> > > > > > > > is detected.
> > > > > > >
> > > > > > > No no, there is no charset setting based on DBus calls. It's done 
> > > > > > > during init.
> > > > > > >
> > > > > > > > Unfortunately the call above happens during the modem detection 
> > > > > > > > phase.
> > > > > > > >
> > > > > > > > one fix could be sending the line
> > > > > > > > AT+CSCS="GSM"
> > > > > > > > in the initialization, along with other test commands like 
> > > > > > > > AT*CNTI=2?
> > > > > > > >
> > > > > >
> > > > > > I have checked the code, and the charset detection is part of 
> > > > > > the
> > > > > > enable state machine, while the radio/band detection is part of the
> > > > > > modem discovery state machine in :src/mm-iface-modem.c:
> > > > > >
> > > > > > typedef enum {
> > > > > > ...
> > > > > > 

Re: Cinterion radio bands

[Giacinto Cifelli]

Hey Aleksander,


On Mon, May 18, 2020 at 1:11 PM Aleksander Morgado
 wrote:
>
> Hey,
>
> > > > > > > > I am trying to update the code for the Radio/Bands of Cinterion
> > > > > > > > Today in the code there is a parser for this format (only for 
> > > > > > > > the test part):
> > > > > > > > AT^SCFG=?
> > > > > > > > ^SCFG: "Radio/Band",("1-479","0-1")
> > > > > > > >
> > > > > > > >  the PLS62 reports:
> > > > > > > > under GSM charset:
> > > > > > > > AT^SCFG=?
> > > > > > > >  ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
> > > > > > > >  ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
> > > > > > > >  ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
> > > > > > > > and under UCS2 charset:
> > > > > > > >AT^SCFG=?
> > > > > > > >  ^SCFG: 
> > > > > > > > "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> > > > > > > >  ^SCFG: 
> > > > > > > > "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> > > > > > > >  ^SCFG: 
> > > > > > > > "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> > > > > > >
> > > > > > > > To determine the charset, I use some heuristics on string 
> > > > > > > > length and
> > > > > > > > prefix (0x aka 00300078). Note also that a model returns 
> > > > > > > > lowercase
> > > > > > > > hexa while another uppercase...
> > > > > > >
> > > > > > > Isn't mm_broadband_modem_get_current_charset () not returning the
> > > > > > > correct thing? I would definitely avoid doing heuristics to detect
> > > > > > > charset if possible.
> > > > > >
> > > > > Is there not a CSCS=? check during initialization, plus a CSCS=X set
> > > > > command after that? I believe that ModemManager tries to set the
> > > > > "best" charset of the ones available. Do you have a full debug log to
> > > > > check how that is happening?
> > > > >
> > > > > > The only time it is called is after setting it, and it looks like it
> > > > > > requires a dbus input, and therefore can only happen after the modem
> > > > > > is detected.
> > > > >
> > > > > No no, there is no charset setting based on DBus calls. It's done 
> > > > > during init.
> > > > >
> > > > > > Unfortunately the call above happens during the modem detection 
> > > > > > phase.
> > > > > >
> > > > > > one fix could be sending the line
> > > > > > AT+CSCS="GSM"
> > > > > > in the initialization, along with other test commands like 
> > > > > > AT*CNTI=2?
> > > > > >
> > > >
> > > > I have checked the code, and the charset detection is part of the
> > > > enable state machine, while the radio/band detection is part of the
> > > > modem discovery state machine in :src/mm-iface-modem.c:
> > > >
> > > > typedef enum {
> > > > ...
> > > > ENABLING_STEP_SUPPORTED_CHARSETS,
> > > > ENABLING_STEP_CHARSET,
> > > > ...
> > > > } EnablingStep;
> > > >
> > > > typedef enum {
> > > > ...
> > > >INITIALIZATION_STEP_SUPPORTED_BANDS,
> > > > ...
> > > >INITIALIZATION_STEP_CURRENT_BANDS,
> > > > ...
> > > > } InitializationStep;
> > > >
> > > > It is possible that other initialization steps require the right
> > > > charset. Wouldn't be good to move the charset settings among these
> > > > steps?
> > > > After all setting the charset is part of setting up the communication
> > > > channel, a bit like the baudrate and similar parameters.
> > > >
> > >
> > > That makes sense I think, yes. Would you like to send a patch for that?
> > >
> >
> > Yes, however I fear some regressions. For example, things work in the
> > current Cinterion supported/current bands because the charset is
> > 'unknown'.
> > I would propose to split the supported & detection during the initial
> > phase, and the actual setting of the charset where it is.
> >
>
> I'm not really sure about that; you actually convinced me when you
> said that initializing charset is a bit like initializing the serial
> channel :D
> Why do you say that things work because the channel is unknown?
>

I have moved the two procedures (need to clean the code before
submitting) to the init phase, and seems to work well, so I will
submit the change.

My point above is the following. During the init phase, all
conversions are handled as follow:
if (charset != MM_MODEM_CHARSET_UNKNOWN)
maxbandstr = mm_charset_take_and_convert_to_utf8
(maxbandstr, charset);

since the charset was not initialized so far, we are guaranteed that
the if() above fails, and therefore whatever follows has been tested
on untranslated strings.
What if now the string is different?
I can and will test for the modems I have, but cannot guarantee for
other plugins.

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion radio bands

[Giacinto Cifelli]

Hi Aleksander,


On Mon, May 18, 2020 at 9:04 AM Aleksander Morgado
 wrote:
>
> Hey,
>
> > On Fri, May 15, 2020 at 9:02 PM Aleksander Morgado
> >  wrote:
> > >
> > > Hey,
> > > > > > I am trying to update the code for the Radio/Bands of Cinterion
> > > > > > Today in the code there is a parser for this format (only for the 
> > > > > > test part):
> > > > > > AT^SCFG=?
> > > > > > ^SCFG: "Radio/Band",("1-479","0-1")
> > > > > >
> > > > > >  the PLS62 reports:
> > > > > > under GSM charset:
> > > > > > AT^SCFG=?
> > > > > >  ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
> > > > > >  ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
> > > > > >  ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
> > > > > > and under UCS2 charset:
> > > > > >AT^SCFG=?
> > > > > >  ^SCFG: 
> > > > > > "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> > > > > >  ^SCFG: 
> > > > > > "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> > > > > >  ^SCFG: 
> > > > > > "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> > > > >
> > > > > > To determine the charset, I use some heuristics on string length and
> > > > > > prefix (0x aka 00300078). Note also that a model returns lowercase
> > > > > > hexa while another uppercase...
> > > > >
> > > > > Isn't mm_broadband_modem_get_current_charset () not returning the
> > > > > correct thing? I would definitely avoid doing heuristics to detect
> > > > > charset if possible.
> > > >
> > > Is there not a CSCS=? check during initialization, plus a CSCS=X set
> > > command after that? I believe that ModemManager tries to set the
> > > "best" charset of the ones available. Do you have a full debug log to
> > > check how that is happening?
> > >
> > > > The only time it is called is after setting it, and it looks like it
> > > > requires a dbus input, and therefore can only happen after the modem
> > > > is detected.
> > >
> > > No no, there is no charset setting based on DBus calls. It's done during 
> > > init.
> > >
> > > > Unfortunately the call above happens during the modem detection phase.
> > > >
> > > > one fix could be sending the line
> > > > AT+CSCS="GSM"
> > > > in the initialization, along with other test commands like AT*CNTI=2?
> > > >
> >
> > I have checked the code, and the charset detection is part of the
> > enable state machine, while the radio/band detection is part of the
> > modem discovery state machine in :src/mm-iface-modem.c:
> >
> > typedef enum {
> > ...
> > ENABLING_STEP_SUPPORTED_CHARSETS,
> > ENABLING_STEP_CHARSET,
> > ...
> > } EnablingStep;
> >
> > typedef enum {
> > ...
> >INITIALIZATION_STEP_SUPPORTED_BANDS,
> > ...
> >INITIALIZATION_STEP_CURRENT_BANDS,
> > ...
> > } InitializationStep;
> >
> > It is possible that other initialization steps require the right
> > charset. Wouldn't be good to move the charset settings among these
> > steps?
> > After all setting the charset is part of setting up the communication
> > channel, a bit like the baudrate and similar parameters.
> >
>
> That makes sense I think, yes. Would you like to send a patch for that?
>

Yes, however I fear some regressions. For example, things work in the
current Cinterion supported/current bands because the charset is
'unknown'.
I would propose to split the supported & detection during the initial
phase, and the actual setting of the charset where it is.

Regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion radio bands

[Giacinto Cifelli]

Hey Aleksander,


On Fri, May 15, 2020 at 9:02 PM Aleksander Morgado
 wrote:
>
> Hey,
> > > > I am trying to update the code for the Radio/Bands of Cinterion
> > > > Today in the code there is a parser for this format (only for the test 
> > > > part):
> > > > AT^SCFG=?
> > > > ^SCFG: "Radio/Band",("1-479","0-1")
> > > >
> > > >  the PLS62 reports:
> > > > under GSM charset:
> > > > AT^SCFG=?
> > > >  ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
> > > >  ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
> > > >  ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
> > > > and under UCS2 charset:
> > > >AT^SCFG=?
> > > >  ^SCFG: 
> > > > "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> > > >  ^SCFG: 
> > > > "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> > > >  ^SCFG: 
> > > > "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> > >
> > > > To determine the charset, I use some heuristics on string length and
> > > > prefix (0x aka 00300078). Note also that a model returns lowercase
> > > > hexa while another uppercase...
> > >
> > > Isn't mm_broadband_modem_get_current_charset () not returning the
> > > correct thing? I would definitely avoid doing heuristics to detect
> > > charset if possible.
> >
> Is there not a CSCS=? check during initialization, plus a CSCS=X set
> command after that? I believe that ModemManager tries to set the
> "best" charset of the ones available. Do you have a full debug log to
> check how that is happening?
>
> > The only time it is called is after setting it, and it looks like it
> > requires a dbus input, and therefore can only happen after the modem
> > is detected.
>
> No no, there is no charset setting based on DBus calls. It's done during init.
>
> > Unfortunately the call above happens during the modem detection phase.
> >
> > one fix could be sending the line
> > AT+CSCS="GSM"
> > in the initialization, along with other test commands like AT*CNTI=2?
> >

I have checked the code, and the charset detection is part of the
enable state machine, while the radio/band detection is part of the
modem discovery state machine in :src/mm-iface-modem.c:

typedef enum {
...
ENABLING_STEP_SUPPORTED_CHARSETS,
ENABLING_STEP_CHARSET,
...
} EnablingStep;

typedef enum {
...
   INITIALIZATION_STEP_SUPPORTED_BANDS,
...
   INITIALIZATION_STEP_CURRENT_BANDS,
...
} InitializationStep;

It is possible that other initialization steps require the right
charset. Wouldn't be good to move the charset settings among these
steps?
After all setting the charset is part of setting up the communication
channel, a bit like the baudrate and similar parameters.

Thank you,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion radio bands

[Giacinto Cifelli]

Hey Aleksander,

thank you for your hints.

On Fri, May 15, 2020 at 1:49 PM Aleksander Morgado
 wrote:
>
> Hey!
>
> > I am trying to update the code for the Radio/Bands of Cinterion
> > modules, and it seems a nasty job, because of the way the indicators
> > evolved.
> > Today in the code there is a parser for this format (only for the test 
> > part):
> > AT^SCFG=?
> > ...
> > ^SCFG: "Radio/Band",("1-479","0-1")
> > ...
> >
> > where all the bands for 2G+3G fit in an unsigned integer on 32 bits,
> > ie, the value 511 above.
> > The format is decimal, but the interpretation is a bitmap.
> > This is done well in the current code and works well.
> > One possible flaw is that the detection of the charset is not perfect,
> > but the above output is invariant also when UCS2 is used.
> >
> > When we go to LTE, however, the 32 bits are not enough to host all
> > bands, and so it was decided to split the command by technologies.
> > In these implementations there are some divergences.
> > For instance, the PLS62 reports:
> > under GSM charset:
> > AT^SCFG=?
> >  ...
> >  ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
> >  ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
> >  ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
> >  ...
> > and under UCS2 charset:
> >AT^SCFG=?
> >  ...
> >  ^SCFG: 
> > "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> >  ^SCFG: 
> > "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> >  ^SCFG: 
> > "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> >  ...
> >
> > While the PLPS9 reports (invariant under charset change):
> >  ...
> >  ^SCFG: "Radio/Band/2G",("0001-000f"),,("0","1")
> >  ^SCFG: "Radio/Band/3G",("0001-000400b5"),,("0","1")
> >  ^SCFG: 
> > "Radio/Band/4G",("0001-8a0e00d5"),("0002-01e2"),("0","1")
> >
> >note also the second range for the LTE bands >32
> >  ...
> >
> > My idea is to parse first the old format, then the newer one. I have a
> > regular expression that works well for all 3 formats for the
> > Radio/Band/xG syntax.
> > Q1: Do you think this strategy is ok?
> >
>
> It probably is, yes. The fact that the modem manufacturers don't
> usually keep the same AT command reference for all their devices is
> extremely annoying as you just found out...

Oh well, for this one the fault is the lack of crystal ball :)
I don't think they imagined once they launched 3G that they needed
more than 32 bands, and the prediction even hold for quite some time
for LTE.
About the inconsistency of point 3 below, this is disappointing
indeed, but it happens sometime when there are more groups working on
different projects in parallel.
And once a product or a feature is on the field, it is quite
impossible to come back. This would put off the current users of that
feature that have perhaps adapted their applications.

>
> > To determine the charset, I use some heuristics on string length and
> > prefix (0x aka 00300078). Note also that a model returns lowercase
> > hexa while another uppercase...
>
> Isn't mm_broadband_modem_get_current_charset () not returning the
> correct thing? I would definitely avoid doing heuristics to detect
> charset if possible.

the plugins/cinterion/mm-broadband-modem-cinterion.c call is:
!mm_cinterion_parse_scfg_test (response,
   g_task_get_source_object (task),
   mm_base_modem_get_product_id (_self),

mm_broadband_modem_get_current_charset (MM_BROADBAND_MODEM (self)),
   ,
   ))

and so mm_broadband_modem_get_current_charset returns MM_MODEM_CHARSET_UNKNOWN.
I am not really surprised because I see no call to AT+CSCS? on the code.
The only time it is called is after setting it, and it looks like it
requires a dbus input, and therefore can only happen after the modem
is detected.
Unfortunately the call above happens during the modem detection phase.

one fix could be sending the line
AT+CSCS="GSM"
in the initialization, along with other test commands like AT*CNTI=2?

In any case, I do need to check whether I have "0x" at the beginning
of the string (because not all formats have it), and so checking also
for 00300078 (the corresponding UCS2 coding) is not a big issue.

>
> > The charset transformation with mm_charset_take_and_convert_to_utf8()
> > seems to work well only with MM_MODEM_CHARSET_UCS2, which is ok
> > because it is the only conversion needed.
> > Q2: Is there a better way?
> >
>
> If the modem is configured for UCS2,
> mm_broadband_modem_get_current_charset() should return
> MM_MODEM_CHARSET_UCS2. Would not that be enough? Is that not the case?

that would indeed be enough, and no, it is not the 

Cinterion radio bands

[Giacinto Cifelli]

Dear all,

I am trying to update the code for the Radio/Bands of Cinterion
modules, and it seems a nasty job, because of the way the indicators
evolved.
Today in the code there is a parser for this format (only for the test part):
AT^SCFG=?
...
^SCFG: "Radio/Band",("1-479","0-1")
...

where all the bands for 2G+3G fit in an unsigned integer on 32 bits,
ie, the value 511 above.
The format is decimal, but the interpretation is a bitmap.
This is done well in the current code and works well.
One possible flaw is that the detection of the charset is not perfect,
but the above output is invariant also when UCS2 is used.

When we go to LTE, however, the 32 bits are not enough to host all
bands, and so it was decided to split the command by technologies.
In these implementations there are some divergences.
For instance, the PLS62 reports:
under GSM charset:
AT^SCFG=?
 ...
 ^SCFG: "Radio/Band/2G",("0x0004"-"0x0074")
 ^SCFG: "Radio/Band/3G",("0x0001"-"0x0004019B")
 ^SCFG: "Radio/Band/4G",("0x0001"-"0x080E08DF")
 ...
and under UCS2 charset:
   AT^SCFG=?
 ...
 ^SCFG: 
"Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
 ^SCFG: 
"Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
 ^SCFG: 
"Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
 ...

While the PLPS9 reports (invariant under charset change):
 ...
 ^SCFG: "Radio/Band/2G",("0001-000f"),,("0","1")
 ^SCFG: "Radio/Band/3G",("0001-000400b5"),,("0","1")
 ^SCFG: 
"Radio/Band/4G",("0001-8a0e00d5"),("0002-01e2"),("0","1")

   note also the second range for the LTE bands >32
 ...

My idea is to parse first the old format, then the newer one. I have a
regular expression that works well for all 3 formats for the
Radio/Band/xG syntax.
Q1: Do you think this strategy is ok?

To determine the charset, I use some heuristics on string length and
prefix (0x aka 00300078). Note also that a model returns lowercase
hexa while another uppercase...
The charset transformation with mm_charset_take_and_convert_to_utf8()
seems to work well only with MM_MODEM_CHARSET_UCS2, which is ok
because it is the only conversion needed.
Q2: Is there a better way?

And finally, the main question: please notice above that the PLS62
range (and modules in this family) for GSM is different than from any
other module:
0x0004, MM_MODEM_BAND_EGSM
0x0010, MM_MODEM_BAND_DCS
0x0020, MM_MODEM_BAND_PCS
0x0040, MM_MODEM_BAND_G850

I am thinking about passing the USB pid to the fuction, since I can't
find an internal way to discriminate here (for the
mm_cinterion_parse_scfg_test() could be possible, but not for the
mm_cinterion_parse_scfg_response(): in case the current GSM band is
'4', would be 900MHz for the PLS62, and 850 for all others).
Is there another way?

Thank you for your comments.

regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Cinterion modems

[Giacinto Cifelli]

Hi Aleksander,

On Fri, Mar 20, 2020 at 4:01 PM Aleksander Morgado
 wrote:
>
> Hey Giacinto,
>
> > I would like to add some Cinterion/Gemalto/Thales modems in
> > ModemManager, and I have some questions:
>
> Nice!
>
> > - first of all, if code from the modem vendors are welcome
> > - is there a procedure to submit commits? I see that on the gitlab
> > page there are some pull requests. Is it enough to create an account
> > and do a pull request?
>
> Yes, that is enough. The request will be reviewed, and if more changes
> are needed, they'll be requested.

thank you, will do.

>
> > - is there a preferred or forbidden way to code for some behaviors?
> >. To be more specific, if a modem supports both AT and QMI
> > interfaces, is there a community preference that would override the
> > vendor one? For the Cinterion modems, so far, the vendor supports AT
> > commands, even if the QMI interface is sometimes available.
> >. Some modems support AT+MBIM, and should be used at the same time.
> > Is this acceptable for the ModemManager community?
> >
>
> So, in general if a feature is available in either QMI or MBIM, that
> is always preferred. If the feature isn't available via QMI/MBIM, then
> AT fallback can be used. And definitely, the modems can use both if
> available, following the previous rules. If there are features that
> are shared between e.g. QMI-capable and AT-only-capable devices, e.g.
> GPS management in the cinterion devices, then that would go to the
> "shared" interface of the plugin, and then used by the multiple
> different modem types. E.g. the MMSharedCinterion interface provides
> features implemented both by the AT-only MMBroadbandModemCinterion and
> by the AT+QMI MMBroadbandModemQmiCinterion.

we struggle to keep the AT interface as much compatible as possible
among models, and it is what we validate extensively.
QMI, being used internally, can lead to inexplicable conflicts (in
theory, I never observed that).
I believe that the old TC75i, already supported, will be pretty much
compatible already with more recent models.

>
> > One additional topic: building the source code, I spent some time
> > checking a build error, and found out that xsltproc was not installed
> > on my machine, but no direct error was produced.
> > For problems like this, a simple patch in the configure.ac like the 
> > following:
> > +AC_CHECK_PROG(XSLTPROC_CHECK,xsltproc,yes)
> > +AS_IF([test x"$XSLTPROC_CHECK" != x"yes"], [AC_MSG_ERROR([Please
> > install xsltproc before configuring.])])
> > My questions are: is there a fast way to submit a simple patch like
> > this or needs a pull request? Should such a patch also have a matching
> > bug?
>
> No need to create a bug report for that. You can either create a merge
> request in gitlab, or send the patch to the mailing list, whatever you
> prefer.

submitted as a patch. I hope it is ok.

> Cheers!

Thank you for your welcoming,

>
> --
> Aleksander
> https://aleksander.es

regards,
Giacinto
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH] configure.ac: check for program xsltproc availability

[Giacinto Cifelli]

---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index 57495032..fad73a66 100644
--- a/configure.ac
+++ b/configure.ac
@@ -46,6 +46,9 @@ AM_PROG_CC_C_O
 AC_PROG_INSTALL
 AC_PROG_MKDIR_P
 
+AC_CHECK_PROG(XSLTPROC_CHECK,xsltproc,yes)
+AS_IF([test x"$XSLTPROC_CHECK" != x"yes"], [AC_MSG_ERROR([Please install 
xsltproc before configuring.])])
+
 dnl Initialize libtool
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
-- 
2.17.1

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Cinterion modems

[Giacinto Cifelli]

Dear ModemManager community,

I would like to add some Cinterion/Gemalto/Thales modems in
ModemManager, and I have some questions:
- first of all, if code from the modem vendors are welcome
- is there a procedure to submit commits? I see that on the gitlab
page there are some pull requests. Is it enough to create an account
and do a pull request?
- is there a preferred or forbidden way to code for some behaviors?
   . To be more specific, if a modem supports both AT and QMI
interfaces, is there a community preference that would override the
vendor one? For the Cinterion modems, so far, the vendor supports AT
commands, even if the QMI interface is sometimes available.
   . Some modems support AT+MBIM, and should be used at the same time.
Is this acceptable for the ModemManager community?

One additional topic: building the source code, I spent some time
checking a build error, and found out that xsltproc was not installed
on my machine, but no direct error was produced.
For problems like this, a simple patch in the configure.ac like the following:
+AC_CHECK_PROG(XSLTPROC_CHECK,xsltproc,yes)
+AS_IF([test x"$XSLTPROC_CHECK" != x"yes"], [AC_MSG_ERROR([Please
install xsltproc before configuring.])])
My questions are: is there a fast way to submit a simple patch like
this or needs a pull request? Should such a patch also have a matching
bug?

Kind Regards,
Giacinto Cifelli
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel