On Mon, Mar 6, 2017 at 11:38 AM, wrote:
> I’m using the Cinterion plugin on an EHS5. This does include ‘Radio Band’ in
> its response to ‘AT^SCFG=?’, but in a format that
> mm_cinterion_parse_scfg_test () may not be able to parse?
>
>^SCFG: "Radio/Band",("1"-"147")
>
>
>
> (Which I take to pr
Two main changes in the regex:
* Ignore double quotes around interval numbers.
* Ignore second set of values (i.e. the one after the comma), as it
may not even be given).
We now support at least these two formats:
^SCFG: "Radio/Band",("1-511","0-1")
^SCFG: "Radio/Band\",("1"-"147")
Re
On Tue, Mar 7, 2017 at 6:39 PM, Colin Helliwell
wrote:
>
>> On 07 March 2017 at 16:44 Aleksander Morgado
>> wrote:
>>
>> Two main changes in the regex:
>>
>> * Ignore double quotes around interval numbers.
>> * Ignore second set of values (i.
On Wed, Mar 8, 2017 at 1:00 PM, wrote:
> The Cinterion plugin, when initialising a modem, does 20 tries of
> AT^SIND="simstatus" (after_sim_unlock_context_step).
>
> This isn’t supported by my modems – but there may well be an alternative
> command which could be used. However I’m not sure what i
On Wed, Mar 8, 2017 at 1:45 PM, Colin Helliwell
wrote:
> I'll look for a command which can achieve the same test - perhaps the
> function could switch over to the alternative if it gets an 'unsupported'
> error? (My modems give a "+CME ERROR: 22")
That would be fine, yes.
--
Aleksander
https:
On Wed, Mar 8, 2017 at 2:12 PM, Colin Helliwell
wrote:
> I'll try to suss that out then.
> Is there a particular Cinterion modem that this command is successfully used
> on? I have access to their docs so I could examine the descriptions of
> commands & SIM Status between that and mine.
I think
On Wed, Mar 8, 2017 at 3:08 PM, Colin Helliwell
wrote:
> But this brings me back (in a round-the-houses way!) to my original question:
> when the PPP fails, for example with the ports assigned the right way round,
> but on 'faulty' SIM1, why is the PPP port getting "forced closed" and then
> un
On Wed, Mar 8, 2017 at 9:29 PM, Reinhard Speyerer wrote:
>> I'll look for a command which can achieve the same test - perhaps the
>> function could switch over to the alternative if it gets an
>> 'unsupported' error? (My modems give a "+CME ERROR: 22")
>
> Maybe AT^SSET would be worth a try as it
Hey Salvador,
On Thu, Mar 9, 2017 at 4:39 PM, Penalva, Salvador
wrote:
>
> root@ccimx6ulsbc:~# mmcli -m 0
>
>
>
> /org/freedesktop/ModemManager1/Modem/0 (device id
> '6cb907e9b25fd81d9b144d3346b48cc89f489910')
>
> -
>
> Hardware | manufacturer: 'Telit'
>
>
On Fri, Mar 10, 2017 at 5:24 PM, Tom Hayward wrote:
> I'm a new user of ModemManager and trying to understand the scope of
> the software.
>
> I've used ModemManager successfully with a cdc-wdm modem. It created a
> wwan0 interface where I could use a dhcp client and then route
> packets.
>
> Now
On Fri, Mar 10, 2017 at 8:36 AM, Colin Helliwell
wrote:
>> > > > But this brings me back (in a round-the-houses way!) to my
>> > > > original question: when the PPP fails, for example with the ports
>> > > > assigned the right way round, but on 'faulty' SIM1, why is the
>> > > > PPP port getting "
On Fri, Mar 10, 2017 at 5:43 PM, Aleksander Morgado
wrote:
>>> > mmcli -m 0 --enable
>>> > mmcli -m 0 --simple-connect="apn=wap.vodafone.co.uk"
>>> > pon
>>> > ... success ...
>>> > poff
>>> > mmcli -m 0 --s
On Fri, Mar 10, 2017 at 7:25 PM, Tom Hayward wrote:
> On Fri, Mar 10, 2017 at 9:25 AM, Tom Hayward wrote:
>> It sounds like I could improve my process by ditching the chatscript,
>> using --simple-connect, then adding a new utility to communicate with
>> the bearer and launch the appropriate type
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties
A new 'ID_MM_TTY_BAUDRATE' per-port udev tag is introduced, which
allows specifying the baudrate that will be used when opening a
specific serial port.
E.g.:
ACTION!="add|change|move", GOTO="mm_my_modem_end"
DEVPATH=="/devices/pci:00/:00:1d.0/usb1/1-1/1-1.3/*",
ENV{ID_MM_TTY_BAUD
The telit plugin is based on two main ways of checking the purpose of
each port: udev tags flagging specific interfaces (with info taken
from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
the modem about that information. If none of those applies, the port
is ignored by default.
I
If a device reports "LTE" in the list of current capabilities, we'll
set EPS network supported by default. This will enable CEREG
registration checks for AT based devices.
If a device reports only "LTE" in the list of current capabilities, we
disable all the other network support flags (e.g. will
Adding the vendor string match allows us to support RS232 devices in
the Telit plugin: the USB vendor id check may now be ignored and
instead we probe for the vendor string via AT commands, which works
even if the device is behind a USB<->RS232 adapter.
https://bugs.freedesktop.org/show_bug.cgi?id
Hey Dan and everyone,
The following two patches try to fix the capabilities reporting for 4G-only
modems, which were mistakenly being set as also GSM/UMTS as soon as +GCAP was
used to probe for capabilities.
The first patch is a new AT+WS46=? parser, which returns the full list of
combinations
The +CGSM capability is saying that the modem is a 3GPP modem, but
that doesn't necessarily mean it's a GSM/UMTS modem, it could be a
LTE-only device.
We did add the GSM_UMTS capability when +CGSM was found, so now we'll
check if the device only reports 4G-only mode, and remove the
capability if s
We want a parser that returns the full list of combinations found.
---
src/mm-broadband-modem.c | 111
src/mm-modem-helpers.c | 143 +
src/mm-modem-helpers.h | 3 +
src/tests/test-modem-helpers.c | 102
On Mon, Mar 13, 2017 at 5:33 PM, Dan Williams wrote:
>> Adding the vendor string match allows us to support RS232 devices in
>> the Telit plugin: the USB vendor id check may now be ignored and
>> instead we probe for the vendor string via AT commands, which works
>> even if the device is behind a
On Mon, Mar 13, 2017 at 11:05 AM, Martin MOKREJŠ wrote:
>>> Is this a matter of configuration, lack of support, or simply outside
>>> the scope of ModemManager? Is there a way to use ModemManager to
>>> initiate the ppp connection?
>>
>> Initiating a ppp session is currently out of scope of MM. MM
On Mon, Mar 13, 2017 at 6:29 PM, Daniele Palmas wrote:
>> With this patch on, a Telit RS232 modem still needs the udev tag in
>> the appropriate port to get it grabbed by the Telit plugin. Without
>> this patch, the telit plugin would not grab this patch even if the
>> udev tag is set because the
On Tue, Mar 14, 2017 at 10:30 AM, Carlo Lobrano wrote:
> Yes, +CPINR is not supported by all Telit modems (e.g. LE910 and LE910 V2),
> so I opted for the command with wider support. Changing the timeout can be a
> solution and I'll made some tests.
We could always run +CPINR=? to look for support
Hey,
I've created a new bugreport, see:
https://bugs.freedesktop.org/show_bug.cgi?id=100205
Is this the same issue Salvador experienced?
https://bugs.freedesktop.org/attachment.cgi?id=130225
The previous logs are just after a SIM-PIN unlock; also modified the
after-sim-unlock step to wait 10s in
Wrap the AT+CSIM=XX commands between lock (CSIM=1) and
unlock (CSIM=0) operations.
This seems to avoid the TTY lockup seen in several different Telit
modules.
https://bugs.freedesktop.org/show_bug.cgi?id=100205
Reported-by: Penalva, Salvador
---
Hey Salvador, Carlo and Daniele,
Can you guys r
It will allow us to avoid totally or partially the after-sim-unlock
explicit wait time that we're forcing.
https://bugs.freedesktop.org/show_bug.cgi?id=100206
---
Hey Carlo & Daniele,
I tried to enable #QSS=2 to see if I could get "#QSS: 3" indications:
3 - SIM INSERTED and READY (SMS and Pho
On Wed, Mar 15, 2017 at 2:40 AM, Dan Williams wrote:
>>
>> Can you guys review and test this patch? It looks like it solved the
>> issue I saw myself.
>>
>> The AT command reference for the Telit LE866 does say that the
>> AT+CSIM commands need to be enclosed within lock/unlock operations
>> like
On Wed, Mar 15, 2017 at 9:34 AM, Daniele Palmas wrote:
>> E.g. even if I remove the SIM and insert it again I get no "#QSS: 0" or
>> "#QSS: 1" indication. Any idea why?
>
> Are you using an EVK or a custom design? I'm taking a look at the user
> guides and it seems to me that SIM detection needs
On Wed, Mar 15, 2017 at 4:09 PM, Dan Williams wrote:
>> > > Can you guys review and test this patch? It looks like it solved
>> > > the
>> > > issue I saw myself.
>> > >
>> > > The AT command reference for the Telit LE866 does say that the
>> > > AT+CSIM commands need to be enclosed within lock/un
Wrap the AT+CSIM=XX commands between lock (CSIM=1) and
unlock (CSIM=0) operations.
This seems to avoid the TTY lockup seen in several different Telit
modules.
https://bugs.freedesktop.org/show_bug.cgi?id=100205
Reported-by: Penalva, Salvador
---
Hey Dan & everyone,
This v2 just adds a NOTE at
On Thu, Mar 16, 2017 at 10:57 AM, Daniele Palmas wrote:
> Tested with GL865 and working fine
>
> daniele@L2122:~$ mmcli -m 0
>
> /org/freedesktop/ModemManager1/Modem/0 (device id
> 'e31ff4d485c411511410e55f1f682373f9f68e2f')
> -
> Hardware | manufacturer: 'Telit'
>
On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano wrote:
> Sorry for the late reply, but I was double checking this change because of
> the last paragraph in +CSIM reference:
>
>> After the locking of the SIM-ME interface (AT+CSIM=1) the SIM will be
>> accessible only by AT+CSIM commands (#QSS: 0).
Hey Mike,
On Thu, Mar 16, 2017 at 11:46 AM, Engel, Mike wrote:
> We are using the UBlox L-210 modem with ModemManager 1.6.4 and the ACM
> interface we getting the following error message.
>
> ModemManager[852]: [1489583434.054490]
> [../../ModemManager-1.6.4/src/mm-port-serial-at.c:459] debug_
On Thu, Mar 16, 2017 at 1:24 PM, Engel, Mike wrote:
> Changing the modem USB profile makes the modem work with the modemmanager
> version we are using.
If you end up using the u-blox plugin, MM should be able to handle the
connection regardless of the mode.
--
Aleksander
https://aleksander.es
On Mon, Mar 13, 2017 at 5:34 PM, Dan Williams wrote:
>> If a device reports "LTE" in the list of current capabilities, we'll
>> set EPS network supported by default. This will enable CEREG
>> registration checks for AT based devices.
>>
>> If a device reports only "LTE" in the list of current capa
On Sat, Mar 11, 2017 at 1:29 PM, Aleksander Morgado
wrote:
> The telit plugin is based on two main ways of checking the purpose of
> each port: udev tags flagging specific interfaces (with info taken
> from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
> the mode
On Sun, Mar 12, 2017 at 8:47 PM, Aleksander Morgado
wrote:
> Adding the vendor string match allows us to support RS232 devices in
> the Telit plugin: the USB vendor id check may now be ignored and
> instead we probe for the vendor string via AT commands, which works
> even if the devi
On Wed, Mar 15, 2017 at 12:19 AM, Aleksander Morgado
wrote:
> Wrap the AT+CSIM=XX commands between lock (CSIM=1) and
> unlock (CSIM=0) operations.
>
> This seems to avoid the TTY lockup seen in several different Telit
> modules.
>
> https://bugs.freedesktop.org/show_bug.cgi?i
On Fri, Mar 17, 2017 at 7:50 AM, Skateboarding Boy
wrote:
> I am new to modem manager. I'd like to know if MBIM interterface requires a
> correct plugin to work.
The MBIM support is built-in ModemManager itself, no external plugin required.
--
Aleksander
https://aleksander.es
__
On Fri, Mar 17, 2017 at 10:23 AM, Carlo Lobrano wrote:
>
> I tested your patch and it seems working fine, even if #QSS: 3 always
> arrives very late respect any acceptable timeout (the modem reads all SIM
> values, even sms, before signaling QSS:3).
> Moreover, this change would be really helpful
On Fri, Mar 17, 2017 at 10:35 AM, Carlo Lobrano wrote:
> mar 17 09:07:10 D2040 ModemManager[23597]: Waiting up to 5 seconds for SIM
> readiness (#QSS: 3)
> mar 17 09:07:15 D2040 ModemManager[23597]: After SIM unlock: SIM readiness
> timeout 5 expired. Continuing...
> mar 17 09:07:18 D2040 ModemMan
On Fri, Mar 17, 2017 at 11:39 AM, Carlo Lobrano wrote:
> Well, before "#QSS: 3" you can expect some errors accessing the SIM, but
> it's not forbidden, and in fact we got some errors sometimes, like "SIM
> Busy"
That was exactly what I wanted to avoid with my patch, because
ModemManager does a lo
On Fri, Mar 17, 2017 at 2:13 PM, wrote:
> Is there anything in MM which attempts to fetch the modem’s own phone
> number? I see a line for it in ‘mmcli –m 0’, but unsure where it
> could/would/might obtain this (seems to be somewhere in the ‘libmm’ stuff?).
The default logic to try to read it i
On Fri, Mar 17, 2017 at 6:40 PM, Dan Williams wrote:
> I ended up with something like:
>
> void
> mm_3gpp_normalize_operator_id (gchar **id,
>MMModemCharset cur_charset)
> {
> g_assert (id);
>
> /* Some modems return the operator name as a hexadec
On Fri, Mar 17, 2017 at 2:16 PM, Carlo Lobrano wrote:
> Short update that might highlight better the problem. When the Modem is
> re-probed after SIM is removed, the "parse_caps_gcap" receives NULL strings,
> even if we can see the reply on the logs
>
> mar 17 14:08:40 D2040 ModemManager[7410]: (t
On Fri, Mar 17, 2017 at 4:55 PM, Carlo Lobrano wrote:
> mar 17 16:45:15 D2040 ModemManager[3946]: (ttyACM0): -->
> 'AT+GCAP'
> mar 17 16:45:15 D2040 ModemManager[3946]: (ttyACM0): <-- ''
> mar 17 16:45:15 D2040 ModemManager[3946]: (ttyACM0): <-- '+GCAP:
> +CGSM,+DS,+FCLASS,+MS,+ESOK'
Ah, ok, I
On Fri, Mar 17, 2017 at 1:19 PM, Colin Helliwell
wrote:
> I fear this may not be all that straight-forward to tackle - dunno if it's
> just them, but Cinterion seem to have great mastery in implementing different
> AT Command sets!
> AT^SSET is available on the BGS2 module, but not on the [later
On Fri, Mar 17, 2017 at 10:11 PM, Dan Williams wrote:
> ---
> src/mm-iface-modem-3gpp.c | 43 ---
> 1 file changed, 8 insertions(+), 35 deletions(-)
>
LGTM
> diff --git a/src/mm-iface-modem-3gpp.c b/src/mm-iface-modem-3gpp.c
> index d38c4ca..8b93550 10064
On Mon, Mar 20, 2017 at 4:46 PM, Engel, Mike wrote:
> I have used the MM 1.7.0 that includes the UBlox plugin and the error that I
> saw with the previous version persist. It seems that the SIM is not detected.
>
> When I change the USB profile from (3 ("NETWORK, 1 CDC-ACM"),("RNDIS"),())
> defa
Hey Colin,
On Mon, Mar 20, 2017 at 9:17 AM, Colin Helliwell
wrote:
>
>> On 17 March 2017 at 19:56 Aleksander Morgado
>> wrote:
>>
>> On Fri, Mar 17, 2017 at 6:40 PM, Dan Williams wrote:
>>
>> > I ended up with something like:
>> >
>&
On Tue, Mar 21, 2017 at 12:55 AM, Jan Graczyk wrote:
>
> I have installed Quectel UC20 modem on my development board PCIe bus. The
> Linux modem device for Quectel UC20 modem is showing up as /dev/ttymxc2. When
> I try to run mmcli -L or ModemManager –debug the message “Could not acquire
> the
On Tue, Mar 21, 2017 at 5:04 PM, José wrote:
> ModemManager reports look like this:
>
> Status | lock: 'none'
> | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
> | state: 'connected'
> | power state: 'on'
> | access tech: 'hsdpa'
> | signal quality: '38' (recent)
>
> I h
On Tue, Mar 21, 2017 at 8:18 PM, Thomas Schäfer wrote:
> I reflashed a Telekom Speedstick V (E3372h) with the firmware from megafon.
>
> Under Windows 10 this has the effect, that the stick is running dualstack.
>
> This is also possible under linux, but only manually:
>
> echo -ne '\r\nAT^NDISDUP
On Tue, Mar 21, 2017 at 8:56 PM, Jan Graczyk wrote:
> ModemManager[1623]: [1490123698.126826] [mm-port-serial-at.c:440]
> debug_log(): (ttymxc2): --> 'AT'
> ModemManager[1623]: [1490123699.675043] [mm-plugin-manager.c:710]
> min_probing_timeout_cb(): (Plugin Manager)
> [/sys/devices/soc0/soc/
On Tue, Mar 21, 2017 at 9:18 PM, Jan Graczyk wrote:
> The baudrate of /dev/ttymxc2 is 115200.
That won't work, unless you instruct ModemManager to use that specific
baudrate on the TTY. Last week I sent a patch for review to allow that
with per-port udev rules, see:
https://lists.freedesktop.org/
Hey Jan,
On Tue, Mar 21, 2017 at 9:39 PM, Jan Graczyk wrote:
> How to set ModemManager baudrate?
See
https://lists.freedesktop.org/archives/modemmanager-devel/2017-March/004075.html
If you import that patch, you would be able to configure the default
baudrate that would be used by MM on the tt
On Tue, Mar 21, 2017 at 10:59 PM, Thomas Schäfer wrote:
>> You can convince MM to use the WWAN with a udev rule like this:
>>
>> # Airtel branded E3372h-607, using huawei-cdc-ncm driver but with
>> unresponsive cdc-wdm port
>> ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1506",
>> ENV{ID_MM_HUAWEI_
Hey Jan,
On Tue, Mar 21, 2017 at 11:16 PM, Jan Graczyk wrote:
> I have tried running ModemManager with /dev/ttymxc2 port set to 57600 baud
> rate. It looks like as I can see from ModemManager debug logging the QUECTEL
> UC20 device is not recognized. I have looked into the ModemManager supporte
On 21/03/17 22:08, Dan Williams wrote:
>> There are 2 main types of udev properties: device-specific and
>> port-specific.
>>
>> The port-specific properties are set independently per port (e.g.
>> port
>> type hints set per interface number for a given vid:pid).
>>
>> The device-specific propertie
On 21/03/17 22:09, Dan Williams wrote:
>> A new 'ID_MM_TTY_BAUDRATE' per-port udev tag is introduced, which
>> allows specifying the baudrate that will be used when opening a
>> specific serial port.
>>
>> E.g.:
>>
>> ACTION!="add|change|move", GOTO="mm_my_modem_end"
>> DEVPATH=="/devices/p
Hey Jan,
See comments inline below.
>
> When you are saying not to mix e-mail threads you mean not to reply all? I am
> only replying to e-mails which are related to my problem.
It's ok to reply-all; but we're now talking in an email thread about
the ID_MM_TTY_BAUDRATE related patch, which you
Hey Jan,
>
> Could you also reply that to the mailing list for reference, please?
>
>
With "Could you also reply that to the mailing list for reference,
please?" I was kind of asking you to "hit reply" to the last email
response in the email thread with the mailing list. I was *not* asking
you to
Hey Jan,
On Thu, Mar 23, 2017 at 12:46 AM, Jan Graczyk wrote:
> But there I another problem with mmcli ‘enable’ command. Here is the output:
>
>
>
> root@linaro-alip:~# mmcli -m 0
>
>
>
> /org/freedesktop/ModemManager1/Modem/0 (device id 'unknown')
>
> -
>
> Hardware |
On 23/03/17 08:47, Thomas Lang wrote:
> Hmm. I tried at+CREG? To get the CellInfo. But I the response is empty. In
> the Debug the info is present:
>
> ModemManager[3184]: [1490255043.880383] [mm-port-serial.c:1237]
> mm_port_serial_open(): (cdc-wdm2) device open count is 2 (open)
> ModemManage
On Thu, Mar 23, 2017 at 2:29 PM, Carlo Lobrano wrote:
> Let mem1_str defaulting to NULL when current_sms_mem1_storage is
> MM_SMS_STORAGE_UNKNOWN
>
> modem_messaging_set_default_storage considers mem1 storage
> string valid if *not NULL*, but, previously, when we could not get
> current_sms_mem1_s
On Thu, Mar 23, 2017 at 5:32 PM, Carlo Lobrano wrote:
>> So why is current_sms_mem1_storage UNKNOWN? At which point did it
>> fail, if it did? Did it fail doing AT+CPMS?
>
> Correct. AT+CPMS? returns with SIM Busy. It's something that will be better
> addressed when "delay till #QSS: 3" will be im
On Fri, Mar 24, 2017 at 4:20 AM, Ajay Garg wrote:
> If we don't specify ip-type parameter while doing a simple-connect via mmcli
> (http://manpages.ubuntu.com/manpages/trusty/man8/mmcli.8.html), what is the
> default parameter picked? ipv4 or ipv6? Or whatever the network offers?
It defaults to I
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
---
Hey Carlo and Daniele,
This patch makes the Telit plugin accept QMI and MBIM modems. Can any of you
test it with such mo
The vendor id/string based rules should already be enough to get the
telit plugin bind telit devices.
This simplifies support for future Telit devices, as we wouldn't need
any additional change in the plugin. It also helps when working with
RS232 devices as the user wouldn't need to add the explic
On modems with a single TTY for both control and data, we cannot use
the TTY to load connection status once we're in connected mode:
Connection through a plain serial AT port (ttyUSB2)
(ttyUSB2): --> 'ATD*99***2#'
(ttyUSB2): <-- 'CONNECT 1'
(ttyUSB2): port now connected
When the connection request is done via ATD, flag the port as
connected as soon as the successful response is received, so that we
remove our polling on the device right away.
https://bugs.freedesktop.org/show_bug.cgi?id=99541
---
Hey Colin, Dan & everyone,
This patch tries to minimize the possi
On Fri, Mar 24, 2017 at 2:57 PM, Carlo Lobrano wrote:
>> I have a LN930 that I can switch to MBIM mode, but it exposes Intel's VID,
>> not the Telit VID. Do you know if this would be something happening to all
>> MBIM-capable Telit modems?
>
> this shouldn't happen. How do you switch to MBIM mode?
Hey Riccardo,
On Fri, Mar 24, 2017 at 3:03 PM, Riccardo Vangelisti
wrote:
> Hi, I've found an unsolicited message (^EONS) that broke the incoming voice
> call in Huawei ME909s-120 modules.
> This patch can fix it (simply ignore it).
>
Could you make sure the patch applies in top of git master an
On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas wrote:
> So LN930 was a "special" modem, in the sense that was never produced
> with Telit VID.
Did it actually have a custom Telit firmware, or was it the original
one from Intel? I see that this device also didn't have Telit VID in
AT+NCM mode.
On 24/03/17 15:43, Riccardo Vangelisti wrote:
> Ops, sorry :)
>
>
Pushed now to git master after doing some minor alignment fixes.
Thanks!
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.o
On Fri, Mar 24, 2017 at 9:15 PM, Dan Williams wrote:
>> +/* If CID not defined, error out */
>> if (!MM_BROADBAND_BEARER (self)->priv->cid) {
>> -g_task_return_new_error (task, MM_CORE_ERROR,
>> MM_CORE_ERROR_FAILED,
>> +g_task_return_new_error (task, MM_CORE_ERROR,
>> MM_
On Fri, Mar 24, 2017 at 9:11 PM, Dan Williams wrote:
> On Sun, 2017-03-12 at 21:05 +0100, Aleksander Morgado wrote:
>> We want a parser that returns the full list of combinations found.
>
> Looks good to me except the comment:
>
> +/* Fixup the ANY value, based on whethe
On Fri, Mar 24, 2017 at 9:22 PM, Aleksander Morgado
wrote:
>>> We want a parser that returns the full list of combinations found.
>>
>> Looks good to me except the comment:
>>
>> +/* Fixup the ANY value, based on whether LTE is supported or not
>>
>
On Fri, Mar 24, 2017 at 9:12 PM, Dan Williams wrote:
>> The +CGSM capability is saying that the modem is a 3GPP modem, but
>> that doesn't necessarily mean it's a GSM/UMTS modem, it could be a
>> LTE-only device.
>>
>> We did add the GSM_UMTS capability when +CGSM was found, so now we'll
>> check
On Fri, Mar 24, 2017 at 9:35 PM, Dan Williams wrote:
>> When the connection request is done via ATD, flag the port as
>> connected as soon as the successful response is received, so that we
>> remove our polling on the device right away.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=99541
>
>
On 24/03/17 21:20, Aleksander Morgado wrote:
>>> +/* If CID not defined, error out */
>>> if (!MM_BROADBAND_BEARER (self)->priv->cid) {
>>> -g_task_return_new_error (task, MM_CORE_ERROR,
>>> MM_CORE_ERROR_FAILED,
>>> +
On Fri, Mar 24, 2017 at 5:08 PM, Carlo Lobrano wrote:
> tested with HE910, LE910, LE910 V2, LE910 sv1 and everything is fine for me.
I've pushed this to git master.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-d
Hey Carlo,
On Fri, Mar 24, 2017 at 12:48 PM, Carlo Lobrano wrote:
> Let modem_messaging_set_default_storage returns with error
> if current_sms_mem1_storage is MM_SMS_STORAGE_UNKNOWN
>
> ---
>
> I updated the patch according the code review, moreover I'd like
> to note a little difference respect
On Fri, Mar 24, 2017 at 11:08 PM, Daniele Palmas wrote:
>> On Fri, Mar 24, 2017 at 3:33 PM, Daniele Palmas wrote:
>>> So LN930 was a "special" modem, in the sense that was never produced
>>> with Telit VID.
>>
>> Did it actually have a custom Telit firmware, or was it the original
>> one from Int
Instead of assuming XON/XOFF is supported, we query the supported flow
control modes, and then we set the best one based on that, preferring
hardware flow control over software flow control.
---
src/mm-broadband-modem.c | 79
1 file changed, 60 inse
The generic modem object already supports querying for the supported
methods and setting the best one found.
---
plugins/wavecom/mm-broadband-modem-wavecom.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/plugins/wavecom/mm-broadband-modem-wavecom.c
b/plugins/wave
Instead of having the parser return separate list of supported flow
controls for TE and TA, we simplify it by only returning those
settings that apply to both TE and TA.
This logic isn't perfect either, though, as some settings (e.g. '3' in
TE in some modems, specifying a different XON/XOFF behavi
The method takes care of looping if EAGAIN errors happen, as well as
checking whether all attributes were set or not.
---
src/mm-port-serial.c | 119 ---
1 file changed, 57 insertions(+), 62 deletions(-)
diff --git a/src/mm-port-serial.c b/src/mm-po
Hey Dan, Daniele, Carlo & everyone,
This series of patches tries to implement proper flow control settings on the
serial port, and is based on letting MM detect which are the supported modes
with AT+IFC=?. This makes it unnecessary to subclass the flow control setting
in plugins for modems that
We won't set XON/XOFF by default and we won't allow setting RTS/CTS
via a property. The serial port by default starts with no flow control
configured.
---
src/mm-port-serial.c | 34 ++
src/mm-port-serial.h | 1 -
2 files changed, 6 insertions(+), 29 deletions(-)
d
The generic modem object already supports querying for the supported
methods and setting the best one found.
---
plugins/telit/mm-broadband-modem-telit.c | 48
1 file changed, 48 deletions(-)
diff --git a/plugins/telit/mm-broadband-modem-telit.c
b/plugins/telit/m
During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT cont
---
src/mm-port-serial.c | 50 ++
src/mm-port-serial.h | 5 +
2 files changed, 55 insertions(+)
diff --git a/src/mm-port-serial.c b/src/mm-port-serial.c
index f2b97a02..e55f9062 100644
--- a/src/mm-port-serial.c
+++ b/src/mm-port-serial.c
@@ -1
On Wed, Mar 22, 2017 at 11:40 AM, wrote:
> ModemManager[1292]: [1490177537.405571]
> [src/mm-port-serial-at.c:459] debug_log(): (ttyMux0): --> 'ATD*99***1#'
> ModemManager[1292]: [1490177537.468957]
> [src/mm-port-serial-at.c:459] debug_log(): (ttyMux1): <-- '+CGREG:
> 2'
> ModemManager[1292]:
The operator code (MCCMNC) may also be given encoded in the current
charset (e.g. UCS2).
Based on a patch from Colin Helliwell
---
plugins/altair/mm-broadband-modem-altair-lte.c | 2 +-
src/mm-broadband-modem.c | 6 --
src/mm-modem-helpers.c | 4
The method doing the operator name normalization takes as input the
current configured modem charset. If this is UCS2, we will now just
assume this is a hint: the string may or may not come in hex/UCS2.
This logic makes the custom operator name loading in Huawei unneeded,
if the modem is configure
Hey Colin and Dan,
What do you think of these two patches?
Cheers!
[PATCH 1/2] modem-helpers: if operator not in UCS2, see if already
[PATCH 2/2] broadband-modem: normalize also operator code
___
ModemManager-devel mailing list
ModemManager-devel@lists
On Mon, Mar 27, 2017 at 12:14 PM, Daniele Palmas wrote:
> 2017-03-24 15:33 GMT+01:00 Daniele Palmas :
>> Hi Aleksander,
>>
>> 2017-03-24 14:48 GMT+01:00 Aleksander Morgado :
>>> Vendor specific plugins that support QMI or MBIM based devices need to
>>&
701 - 800 of 1794 matches
Mail list logo
