Hi Ondřej,
On Wed, 7 Aug 2019 at 13:24, Ondřej Krajsa wrote:
> Hi,
> I have problems with TELIT LE910v2 modem, OS is Debian, ModemManager 1.10
> from repository.
> The first is as follows:
> Sometimes the modem refuses to connect to a bearer, with a error:
>
> error: couldn't connect the bearer:
Hi Aleksander,
On Fri, 5 Jun 2020, 10:22 am Aleksander Morgado,
wrote:
> Hey!
>
> > I am facing an unexpected - as far as I can tell - behavior with
> ModemManager 1.12.8 and network manager is 1.22.10 on Ubuntu 20.04, the
> modem is LE910 V2.
> >
> > During and ongoing connection, lasting since
Hi,
I thought this should have been fixed in
> 5f29bd64de8127cb326488d68a2a2b64a45e1f45, but I don't see the relevant
> "PPP is required for connection, will ignore disconnection reports"
> message that should happen once the modem gets connected in PPP mode.
>
> If you have the setup with you, co
Hi!
Could it be that the log is really from a MM 1.10 run instead of a MM
> 1.12 run? The fix to ignore disconnection reports when PPP is used was
> only added in MM 1.12.0 IIRC.
>
>
that was indeed the case, problem solved! :D
Thanks!
___
ModemManager-
up default
Thanks in advance,
Carlo
On 23 September 2016 at 09:44, Carlo Lobrano wrote:
> Hi Bjørn,
>
> thanks for this reply, it's full of information!
>
> Carlo
>
> On 20 September 2016 at 11:16, Bjørn Mork wrote:
>
>> Carlo Lobrano writes:
>>
>&g
In place of two slightly different regexes for 2g/3g and 2g/3g/4g modems
we now use only one regex with conditional patterns for both supported
and current Bands detection.
Adding also minor fix in test code
---
plugins/telit/mm-modem-helpers-telit.c| 18 --
plugins/te
Hello everybody,
I'm working on a MBIM modem with GPS capabilities and my understanding is
that, since there is no service to access GPS through MBIM protocol, for
the gps APIs the ModemManager falls back to the generic broadband modem
plugin. If this is correct, would it be possible to make it fa
I see. Curious, because I can send "location" commands through mmcli to a
MBIM modem and I thought it was because the fallback. I'll look into
Cinterion plugin though, thanks a lot!
On Fri, 11 Nov 2016 at 18:10 Aleksander Morgado
wrote:
> On Fri, Nov 11, 2016 at 3:26 PM, Carl
---
plugins/telit/77-mm-telit-port-types.rules | 5 +
1 file changed, 5 insertions(+)
diff --git a/plugins/telit/77-mm-telit-port-types.rules
b/plugins/telit/77-mm-telit-port-types.rules
index 36a4f99..072c48f 100644
--- a/plugins/telit/77-mm-telit-port-types.rules
+++ b/plugins/telit/77-mm-
Oh sure, no problem
On 7 December 2016 at 16:22, Dan Williams wrote:
> On Wed, 2016-12-07 at 12:59 +0100, Carlo Lobrano wrote:
> > ---
> > plugins/telit/77-mm-telit-port-types.rules | 5 +
> > 1 file changed, 5 insertions(+)
>
> Would you mind moving this to
Moved blacklist code to 77-mm-usb-device-blacklist.rules as per code review
---
src/77-mm-usb-device-blacklist.rules | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/77-mm-usb-device-blacklist.rules
b/src/77-mm-usb-device-blacklist.rules
index 28ef060..3ef6310 100644
--- a/src/77-mm-us
qss unsolicited handler should be assigned to primary port first,
while secondary port was peeked.
---
plugins/telit/mm-broadband-modem-telit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/telit/mm-broadband-modem-telit.c
b/plugins/telit/mm-broadband-modem-telit.c
Added the following configurable values:
- upload datagram protocol
- download datagram protocol
- download datagram max size
- download max datagrams
- endpoint type
- endpoint interface number
According to last GobiNet from CodeAura project, setting the following
values is necessary to enable mu
This message is used to bind a muxed data port to a controller device.
The Muxed data port has to be managed by qmi_wwan driver.
The Muxed data port is identified by:
- mux_id: the numeric ID given to qmi_wwan once created
- interface number: the interface number of the qmi controller device on
; On Mon, Mar 13, 2017 at 03:48:51PM +0000, Carlo Lobrano wrote:
> > Hi Salvador,
> >
> > I'll look into this CSIM lock thing, but with a newer FW version I'm
> > actually getting responses to CSIM and the next messages (see logs
> below).
> >
>
> Hi
Hi Aleksander,
that's weird. By the way I should be able to test it this afternoon with a
LE910 or HE910 and let you know.
BR,
Carlo
On Wed, 15 Mar 2017 at 00:38 Aleksander Morgado
wrote:
> It will allow us to avoid totally or partially the after-sim-unlock
> explicit wait time that we're forc
Hi all,
I agree with Dan, we should send the unlock csim command. I should be able
to test and fix it this afternoon.
BR,
Carlo
On Wed, 15 Mar 2017 at 02:40 Dan Williams wrote:
> On Wed, 2017-03-15 at 00:19 +0100, Aleksander Morgado wrote:
> > Wrap the AT+CSIM=XX commands between lock (CSIM=1)
nder Morgado [mailto:aleksan...@aleksander.es]
> Sent: miércoles, 15 de marzo de 2017 10:28
> To: Dan Williams
> Cc: Carlo Lobrano; Penalva, Salvador; Daniele Palmas; ModemManager
> (development)
> Subject: Re: [PATCH] telit: lock/unlock CSIM operations by default
>
> On Wed, Mar 1
Hi all,
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). The GSM and GPRS services
> will be automatically de-r
o it. #QSS: 0/1 are for physical
changes on SIM, #QSS: 2 should be for SIM unlock, but we're not listening
to it.
On Thu, 16 Mar 2017 at 11:17 Aleksander Morgado
wrote:
> On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano
> wrote:
> > Sorry for the late reply, but I was double c
Hi Aleksander,
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 for the issue I reported in
"[PATCH] telit: lock/u
Aleksander Morgado
wrote:
> 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, bef
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"
On Fri, 17 Mar 2017 at 10:38 Aleksander Morgado
wrote:
> On Fri, Mar 17, 2017 at 10:35 AM, Carlo Lobrano
> w
On Fri, 17 Mar 2017 at 12:00 Aleksander Morgado
wrote:
> 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,
const ModemCaps *cap = modem_caps;
guint32 ret = 0;
mm_dbg ("parse_caps_gcap on '%s'", response);
if (!response)
return FALSE;
However, still not a clue about why a use case with SIM locked should work
differently that one with SIM unlocked.
On Fri
ager[3946]: (ttyACM0): <--
'332OK'
mar 17 16:45:17 D2040 ModemManager[3946]: parse_caps_gcap on
'(null)'
mar 17 16:45:17 D2040 ModemManager[3946]: (ttyACM0): -->
'AT+CPIN?'
mar 17 16:45:17 D2040 ModemManager[3946]: (ttyACM0): <--
'+CME ERROR: 10'
mar 17 1
n Fri, 17 Mar 2017 at 21:03 Aleksander Morgado
wrote:
> 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): <--
>
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_storage value right, mem1_str defaulted to "unknown"
and that strin
t. So, set_default_storage should return error directly
when it finds that mem1 is UNKNOWN. Is that right?
On Thu, 23 Mar 2017 at 17:16 Aleksander Morgado
wrote:
> On Thu, Mar 23, 2017 at 2:29 PM, Carlo Lobrano
> wrote:
> > Let mem1_str defaulting to NULL when current_sms_mem1_storag
ppened, so we should just return error here as well, IMO.
Ok, I'll update the patch then
On Thu, 23 Mar 2017 at 19:39 Aleksander Morgado
wrote:
> 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
&g
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 the previous version:
currently, even if +CPMS fails because of the wrong valu
Hi Aleksander,
> 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?
Carlo
Il venerdì 24 marzo 2017, Aleksander Mor
well, actually, I double checked and that model does not have Telit VID
Carlo
Il venerdì 24 marzo 2017, Carlo Lobrano ha scritto:
> Hi Aleksander,
>
> > 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 thi
Hi,
sure I can test it today or the next week
BR,
Carlo
On 24 March 2017 at 14:51, Aleksander Morgado
wrote:
> 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
Hi Aleksander,
tested with HE910, LE910, LE910 V2, LE910 sv1 and everything is fine for me.
On 24 March 2017 at 15:37, Carlo Lobrano wrote:
> Hi,
>
> sure I can test it today or the next week
>
> BR,
> Carlo
>
> On 24 March 2017 at 14:51, Aleksander Morgado
> wrote
Sure, I didn't see the other error. I'll update the patch
Il venerdì 24 marzo 2017, Aleksander Morgado ha
scritto:
> Hey Carlo,
>
> On Fri, Mar 24, 2017 at 12:48 PM, Carlo Lobrano
wrote:
>> Let modem_messaging_set_default_storage returns with error
>>
In functions
- mm_broadband_modem_lock_sms_storages
- modem_messaging_set_default_storage
return with error when using current_sms_mem1_storage as +CPMS value, but
current_sms_mem1_storage value is UNKNOWN.
---
src/mm-broadband-modem.c | 79 ++
src
Hi Aleksander,
I've got some problems configuring MM for this test. This is the message I
got just after applying the patch:
ModemManager[28005]: [1490621030.009049] [mm-base-manager.c:263]
device_added(): (tty/ttyS0): adding device at sysfs path:
/sys/devices/pnp0/00:05/tty/ttyS0
ModemManager[2
In functions
- mm_broadband_modem_lock_sms_storages
- modem_messaging_set_default_storage
return with error when using current_sms_mem1_storage as +CPMS value, but
current_sms_mem1_storage value is UNKNOWN.
---
>> +g_simple_async_report_error_in_idle (
>
>report_error_in_idle() shouldn'
Here it is
$ udevadm info -p /sys/class/tty/ttyS0
P: /devices/pnp0/00:05/tty/ttyS0
N: ttyS0
E: DEVNAME=/dev/ttyS0
E: DEVPATH=/devices/pnp0/00:05/tty/ttyS0
E: ID_MM_CANDIDATE=1
E: MAJOR=4
E: MINOR=64
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=955641
On Mon, 27 Mar 2017 at 20:44 Aleksa
Updated mm_telit_parse_csim_response in order to correctly recognize the
following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
Fixes: https://bugs.freedes
Sure, good point!
At least for the error codes it's easy, I'll think something for the hex
with the retry value as well.
I'll update the patch
Carlo
Il lunedì 3 aprile 2017, Dan Williams ha scritto:
> On Mon, 2017-04-03 at 17:01 +0200, Carlo Lobrano
Refactored mm_telit_parse_csim_response in order to correctly recognize the
following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
Fixes: https://bugs.free
Uhm, sorry, not the right patch. Please ignore
Carlo
Il martedì 4 aprile 2017, Carlo Lobrano ha scritto:
> Refactored mm_telit_parse_csim_response in order to correctly recognize the
> following +CSIM error codes:
>
> * 6300 - Verification failed
> * 6983 - Authentication
- Refactored mm_telit_parse_csim_response in order to correctly recognize the
following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
Some modems do not support CSIM lock/unlock, but they do support
querying SIM unlock retries through +CSIM command.
If CSIM lock returns with "unsupported command" do not propagate
the error and continue with the other CSIM queries instead.
---
Sorry for not having caught this problem earlier,
wh
think it's a good idea, I can update the patch with this implemented.
Il giovedì 6 aprile 2017, Aleksander Morgado ha
scritto:
> On 06/04/17 14:37, Carlo Lobrano wrote:
> > Some modems do not support CSIM lock/unlock, but they do support
> > querying SIM unlock retries through
Some modems do not support CSIM lock/unlock, but they do support
querying SIM unlock retries through +CSIM command.
If CSIM lock returns with "unsupported command" do not propagate
the error and continue with the other CSIM queries instead, moreover the
CSIM lock feature is signed as FEATURE_UNSUP
fer
to keep it, if you don't mind
>
Looks like csim_lock_support isn't set anywhere to FEATURE_SUPPORTED? It
should be set here I believe.
Doh!
I'll fix it :D
On 10 April 2017 at 13:25, Aleksander Morgado
wrote:
> On 10/04/17 12:25, Carlo Lobrano wrote:
> > Som
Some modems do not support CSIM lock/unlock, but they do support
querying SIM unlock retries through +CSIM command.
If CSIM lock returns with "unsupported command" do not propagate
the error and continue with the other CSIM queries instead, moreover the
CSIM lock feature is signed as FEATURE_UNSUP
Hi Aleksander,
the examples in the docs do not show quoted strings, but I just gave a try
with a couple of modems and I saw no problems.
On 15 April 2017 at 00:14, Aleksander Morgado
wrote:
> On Fri, Apr 14, 2017 at 2:57 PM, Colin Helliwell
> wrote:
> >
> > static const UnlockRetriesMap unlock
Il martedì 18 aprile 2017, Aleksander Morgado ha
scritto:
> On Tue, Apr 18, 2017 at 9:59 AM, Carlo Lobrano > wrote:
> > the examples in the docs do not show quoted strings, but I just gave a
> try
> > with a couple of modems and I saw no problems.
>
> Ok, so mayb
Hi Aleksander,
see below my reply
Il giovedì 6 aprile 2017, Aleksander Morgado ha
scritto:
> Hey Carlo,
>
> On 04/04/17 14:55, Carlo Lobrano wrote:
> > - Refactored mm_telit_parse_csim_response in order to correctly
> recognize the
> > following +CSIM error c
>
> From a quick online search in TS 102.221, I see a lot of other generic
> errors defined there as well, see multiple tables in section "10.2.1
> Status conditions returned by the UICC"; maybe we should extend the
> list of possible errors supported with all know ones?
>
> http://www.etsi.org/del
- Refactored mm_telit_parse_csim_response in order to correctly
recognize the following +CSIM error codes:
* 6300 - Verification failed
* 6983 - Authentication method blocked
* 6984 - Reference data invalidated
* 6A86 - Incorrect parameters
* 6A88 - Reference data not found
-
0:46, Aleksander Morgado
wrote:
> On 19/04/17 10:00, Carlo Lobrano wrote:
> > - Refactored mm_telit_parse_csim_response in order to correctly
> > recognize the following +CSIM error codes:
> > * 6300 - Verification failed
> > * 6983 - Authentication method
In order to make debug logging more clear, I replaced the step ID with a
descriptive step name.
---
plugins/telit/mm-broadband-modem-telit.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/plugins/telit/mm-broadband-modem-telit.c
b/plugins/telit/mm-broadband
Hi,
first of all, I've already asked this question on IRC, but then I had to
disconnect and I have no bouncer configured, so my apologize if someone has
already answered.
I'm working on telit plugin port configuration (telit_custom_init_step to
be precise) and it seems that MMKernelDevice ID_USB_
TEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=75726372964
On 2 May 2017 at 18:04, Aleksander Morgado wrote:
> On Tue, May 2, 2017 at 4:49 PM, Carlo Lobrano wrote:
> >
> > first of all, I've already asked this question on IRC, but then I had to
> > disconnect and I have
On 3 May 2017 at 12:47, Aleksander Morgado wrote:
> On Wed, May 3, 2017 at 12:10 PM, Carlo Lobrano
> wrote:
> >> When using the "udev" backend, which you are, the property isn't
> >> "loaded" or "stored" anywhere in our code. We direct
On 3 May 2017 at 14:55, Aleksander Morgado wrote:
> On Wed, May 3, 2017 at 2:09 PM, Carlo Lobrano wrote:
> >> >> When using the "udev" backend, which you are, the property isn't
> >> >> "loaded" or "stored" anywhere in ou
t; On Wed, May 3, 2017 at 2:09 PM, Carlo Lobrano
> > wrote:
> > > > > > When using the "udev" backend, which you are, the property
> > > > > > isn't
> > > > > > "loaded" or "stored" anywh
h a virtualized Fedora 18 and
IS_USB_INTERFACE_NUM is correctly set.
I do think this should be a problem with my main machine now
(sorry for the top posting)
On 3 May 2017 at 17:25, Carlo Lobrano wrote:
> By chance I have another Ubuntu machine, which is 17.04 while the main one
> is 16.1
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 depends on ID_MM_TELIT_PORTS_TAGGED
environment variable, set by udev, to speed up probing time
avoiding +CGMI and ATI sending.
To remove this dependency from udev, I moved the product ID
check from dell's udev rule to mm-plugin-dell.c file.
---
plugins/dell/77-mm-dell-port-
>
>
> I don't see any clear benefit in doing this; we're moving the match
> with the PID from the udev rules file to the actual source code, which
> means that if we ever get any other Dell-branded modem we'll need to
> update the source code instead of adding a new udev rules file. But...
>
Th
On 8 May 2017 at 09:55, Aleksander Morgado wrote:
> Wouldn't this happen in the same way for all non-AT ports in modems
> managed by the Telit plugin, now that ID_MM_TELIT_PORTS_TAGGED is
> removed from the Telit plugin as well?
>
In Telit plugin we only probe the port with ID_USB_INTERFACE_NUM
SS transitions and some debug logs
>
> On Fri, 17 Mar 2017 at 21:03 Aleksander Morgado
> wrote:
>
>> On Fri, Mar 17, 2017 at 4:55 PM, Carlo Lobrano
>> wrote:
>> > mar 17 16:45:15 D2040 ModemManager[3946]: (ttyACM0): -->
>> > 'AT+GCAP'
>>
you want me to submit
again even part 1?
On 10 May 2017 at 21:22, Aleksander Morgado
wrote:
> On Wed, May 10, 2017 at 4:34 PM, Carlo Lobrano
> wrote:
> >> Could you gather debug logs using the Telit/Dell modem in 2 different
> >> runs:
> >>* with the custom bloc
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 other
> Maybe it wouldn't be a bad idea to keep track of which operations may
> fail due to SIM being busy, and perform automatic retry later if we
> get that specific error, something like that.
Hey,
I made a little proof of concept of this improvement. So far, it's
restricted to *loading unlock retr
On 15 May 2017 at 12:12, Aleksander Morgado
wrote:
> Also, any chance you can send debug logs with
> the whole process once the patch updated?
>
Sure, no problem. I'll update the patch and provide the logs
___
ModemManager-devel mailing list
ModemMa
and only for PIN2 and
PUK2.
I'm gonna develop this idea further, since I really like to have something
generic and applicable also to other commands that return with SIM Busy
error.
On 15 May 2017 at 12:23, Aleksander Morgado
wrote:
> Hey hey,
>
> On 12/05/17 16:18, Carlo Lobrano wr
On 15 May 2017 at 17:15, Aleksander Morgado
wrote:
> Not sure I understand; how does the call complete if the
> GSimpleAsyncResult isn't completed?
>
I save a copy of the instance in a GList, then complete the call
___
ModemManager-devel mailing list
On 16 May 2017 at 10:53, Aleksander Morgado
wrote:
> But g_simple_async_result_complete() can only be called once; as soon
> as you call it the async call would be completed, not sure what you do
> with the copy afterwards. Maybe I'm not understanding it properly?
>
No, you got it right, I was
Hey,
> Carlo, any chance you can make a quick test with these patches to see
> if they work as expected in the Telit modems? One of the changes I
> see is that the Telit plugin previously did the AT+CMER command only
> in the secondary port, while now we do it in both primary and
> secondary, not
On 22 May 2017 at 17:15, Aleksander Morgado
wrote:
> Maybe, yes, although that shouldn't be an issue in most cases.
I see. Anyway, the patch works fine for me, no issues observed.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedes
Ciao Aleksander,
On 22 May 2017 at 13:18, Aleksander Morgado
wrote:
> ---
>
> Hey Carlo,
>
> It's never too late :)
>
> I couldn't reproduce the issue with the SIM hot swap changes you were
> trying, because none of my Telit modems here were able to support it
> properly, so I ended up re-revie
27;ve tried both, but I didn't see any other issues with this two solutions.
What do you think?
On 16 May 2017 at 12:33, Carlo Lobrano wrote:
>
> On 16 May 2017 at 10:53, Aleksander Morgado
> wrote:
>
>> But g_simple_async_result_complete() can only be called once
On May 25, 2017 3:17 PM, "Carlo Lobrano" wrote:
Hi,
> What I was thinking regarding this issue was to define a common error
> id, like "MM_CORE_ERROR_RETRY_LATER". If the logic (e.g. MMIfaceModem
> logic) receives such an error, it would re-schedule the execution
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with cu
> We're trying to move away from GSimpleAsyncResult, how about using
> GTask? If you have any doubt or not sure how to do it, leave it with
> GSimpleAsyncResult and I'll do the port to GTask as a follow up patch,
> so that you can see what the changes were; it really is very easy, you
> can check
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 other
Awesome! Thank you!
Carlo
On 29 May 2017 at 12:27, Aleksander Morgado
wrote:
> On 29/05/17 09:48, Carlo Lobrano wrote:
> > Currently Dell plugin implements a retry logic of three commands
> > (AT+GMI, AT+CGMI, ATI1I2I3) to detect modem's vendor string.
> > Moreover,
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with cu
Currently, Telit's SIM swap implementation is stateless and
based on #QSS unsolicited messages 0/1 (SIM_REMOVED/SIM_INSERTED).
However, the user might have configured the modem in order to provide a
more detailed information, with #QSS values 2/3 (SIM UNLOCKED/SIM READY).
In this case and with cu
Hi
On 2 June 2017 at 13:10, Aleksander Morgado
wrote:
> Hey Carlo,
>
> Your v3 looks good, but I ended up preparing a couple of additional
> patches to go on top of it; could you review/test them?
>
> [PATCH 1/2] telit: make sure QSS status values read are always known
> [PATCH 2/2] te
Hi Aleksander,
I tested this patch and it looks good to me (I specially like the second
one). There is just a little mistake I made in my part of the patch. In the
"status changed" log I inverted current status with the previous one.
---
plugins/telit/mm-broadband-modem-telit.c | 6 +++---
1 fil
On 5 June 2017 at 08:49, Carlo Lobrano wrote:
> sure, I'll do it today
I replied in the patches' thread
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo
> In your case with the Telit modem and QSS:3; if we decide that it's
> not worth waiting for QSS:3 because it takes too long and for our
> purposes we can use it much earlier, then we could do the per-step
> retries on SIM busy errors.
The problem here is that, according to my tests, even if we
Hi Aleksander, Piotr,> I'm checking the logs and if my understanding is correct it looks like> some logic from bearer disconnect from the connection before the modem> reset happens still executes after modem was lost and when "new" modem> is probed, it looks like it may get in the way of AT ports p
Hi,
> If I'm not mistaken, whenever a sim insert/removal event is detected, we
should just call
> mm_broadband_modem_update_sim_hot_swap_detected(), which will trigger a
full modem re-probe.
yes, I confirm this. *mm_broadband_modem_update_sim_hot_swap_detected* will
trigger full re-probe and disa
Hi Karoly,
which modem are you using?
cdc-wdmX and tty ports are used for totally different communication
protocols. Like, if you're modem supports QMI or MBIM, it's ok to use
cdc-wdmX, otherwise is ok to use tty. Also consider that is up to the
kernel to assign the number at the end of cdc-wdmX
On 4 July 2017 at 17:37, Karoly Pados wrote:
> As you can see the modem has multiple ports. The modem is the only USB
> device in the whole system (except for the on-board USB wifi adapter, which
> is non-removable). The phenomenon I'm seeing is that the "primary port"
> above is often something
Hey,
looking at sim hot swap code, I noticed that even if sim swap configuration
fails at some point (in core or in the modem), we still print the message
"SIM is missing, but the modem supports SIM hot swap. Waiting for
SIM...", which is kind of misleading in that case.
I'm working on a patch an
Hi Alexander,
yes you understood correctly and I agree with the suggestion. I'll work on
it.
Thanks
On 6 July 2017 at 18:44, Aleksander Morgado
wrote:
> On Thu, Jul 6, 2017 at 5:10 PM, Carlo Lobrano wrote:
> > looking at sim hot swap code, I noticed that even if sim swap
&
Currently, when SIM hot swap fails in either mm-iface or plugin, the
ModemManager still opens ports context and prints a message saying that
SIM hot swap is supported and that it's waiting for SIM insertion,
instead of clearly saying that SIM hot swap is not working.
This patch:
1. introduces a n
Hi Aleksander,
Any chance you can update also the MBIM implementation to use
> MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED in the same way?
>
sure, I can have a look at this this afternoon or next week at the most
___
ModemManager-devel mailing list
ModemM
Hi Kelvin,
I tried upgrading to modemmanager-1.6.4 and similar results.
>
>
could you please attach the full debug logs, so we can have a complete
picture of what's going on?
Moreover, what's the PID of your modem? By default LE910 uses QMI protocol
(cdc-wdmX device, instead of ttyUSB).
_
1 - 100 of 216 matches
Mail list logo
