Cinterion radio bands

[Aleksander Morgado]

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 veeeerry 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).


>     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.

> 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?

>     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?

-- 
Aleksander
https://aleksander.es