Currently, Telit plugin depends on ID_MM_TELIT_PORTS_TAGGED
environment variable, set by udev, for tagging modems that
support dynamic port config (#PORTCFG)
To remove this dependency from udev, Telit plugin now relies
only on the error management of the command AT#PORTCFG? itself
in order to see
Currently Dell plugin implements a retry logic of three commands
(AT+GMI, AT+CGMI, ATI1I2I3) to detect modem's vendor string.
Moreover, since Telit modems always reply to the first command, to speed
the probing time up, those modem are tagged with an Udev rule so that we
can avoid sending the
Hey hey,
This is a new release in the ModemManager 1.6.x series.
Overview of changes in ModemManager 1.6.6
---
* Blacklist:
** Ignored keyboard.io devices.
** Ignored Analog Devices EVAL-ADXL362Z-DB.
** Ignored promotion boards from Renesas.
Hey hey,
This is a new release in the ModemManager 1.4.x series.
Overview of changes in ModemManager 1.4.20
---
* Blacklist:
** Ignored keyboard.io devices.
** Ignored Analog Devices EVAL-ADXL362Z-DB.
** Ignored promotion boards from Renesas.
On Thu, May 11, 2017 at 9:59 AM, Carlo Lobrano wrote:
> I think that's a nice solution! I'll develop the new patch2 for this. Doe
> this affect also the part 1 of the patch? I mean, do you want me to submit
> again even part 1?
No, let's leave patch 1 as it is, but we'll
Hi,
Thank you for opening the bug and tracking it. Right now, I have not enough
time to do the changes and test it. I'm sorry. It's gonna take much of my time
to understand how to do the changes and apply them correctly. And we don't
need it to work right now if without SIM of with a retry is
Hi Dan,
I take a look to the code and I came up to this patch.
It saves the device name at the voice call connection start (^CONN) and
use it for DTMF until call ends (^CEND).
I tested on Huawei modems I own and it works perfectly. Theoretically,
it should work also in case of PPP connection.
> The retries logic is in case the port needs some time to reply, so
> probably doing the retries only for the first command would make
> sense, and this would get us 4 commands removed for all.
>
> But also, is there a modem that doesn't reply to AT+GMI at all? i.e.
> just not replying anything?