Access MMBroadbandModemPrivate from plugin

lement all messaging interface for this and it is not clear to me how access to "current_sms_mem1_storage" parameter in MMBroadbandModemPrivate. Is it even possible? Thanks in advance for any help Best regards, Carlo Lobrano ___ ModemManag

[PATCH 2/2] Fix function names

--- plugins/telit/mm-broadband-modem-telit.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/plugins/telit/mm-broadband-modem-telit.c b/plugins/telit/mm-broadband-modem-telit.c index 925face..104b4c1 100644 --- a/plugins/telit/mm-broadband-modem-telit.c +++

[PATCH] Telit plugin: add load_unlock_retries interface

--- plugins/telit/mm-broadband-modem-telit.c | 169 +++ plugins/telit/mm-broadband-modem-telit.h | 2 + 2 files changed, 171 insertions(+) diff --git a/plugins/telit/mm-broadband-modem-telit.c b/plugins/telit/mm-broadband-modem-telit.c index 0f77231..b34503d 100644

[PATCH] Telit plugin: add load_unlock_retries (2nd attempt)

From: Carlo Lobrano <c.lobr...@gmail.com> Hi, here's my new version of the patch, according to the previous code review: - it uses context in place of the plugin's private structure - response parser in a separate helper file (with tests) - errors are handled - I replaced the at_se

[no subject]

Hi all, I am using cinterion and other plugins as reference to implement load_supported_bands for Telit plugin, but there is a point which is not clear for me. In my reference plugins I've always seen this kind of result assignement supported_bands_ready (...) { /* get the results */

Re: [PATCH] Hardening PORTCFG parse reply

19:27, Dan Williams <d...@redhat.com> wrote: > On Wed, 2016-06-01 at 14:51 +0200, Carlo Lobrano wrote: >> A brief explaination of the issue that this patch solves. >> I observed a probing failure at resume from memory (S3), caused by a >> missing or wrong reply to #

[PATCH] Hardening PORTCFG parse reply

A brief explaination of the issue that this patch solves. I observed a probing failure at resume from memory (S3), caused by a missing or wrong reply to #PORTCFG? AT command sent during port probing. This error is probably due to the overposition of multiple messages and replies, since at the same

Re: [PATCH 1/2] Inverted steps in update_lock_info_context_step

Hi, has this change already merged? On Fri, 13 May 2016 at 20:05 Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Fri, May 13, 2016 at 5:15 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > Inverted steps UPDATE_LOCK_I

[PATCH] [Telit plugin] add load_supported_bands interface

--- plugins/telit/77-mm-telit-port-types.rules| 4 + plugins/telit/mm-broadband-modem-telit.c | 86 + plugins/telit/mm-modem-helpers-telit.c| 372 +- plugins/telit/mm-modem-helpers-telit.h| 58

[PATCH] [Telit plugin] add load_supported_bands interface

Hi, here is a new proposal implementation for load_supported_bands interface for Telit modems. Best regards, Carlo Carlo Lobrano (1): [Telit plugin] add load_supported_bands interface plugins/telit/77-mm-telit-port-types.rules| 4 + plugins/telit/mm-broadband-modem-telit.c

Re: [PATCH] [Telit plugin] Add load_current_bands interface

Hello guys, any news about this patch? Is there something I need to fix? Thanks, Carlo On Thu, 28 Jan 2016 at 17:30 <c.lobr...@gmail.com> wrote: > From: Carlo Lobrano <c.lobr...@gmail.com> > > --- > plugins/telit/mm-broadband-modem-telit.c | 78 +-

Re: [PATCH] [Telit plugin] Add load_supported_bands interface

Thank you! Carlo On Mon, 25 Jan 2016 at 14:02 Aleksander Morgado <aleksan...@aleksander.es> wrote: > On 25/01/16 11:02, c.lobr...@gmail.com wrote: > > From: Carlo Lobrano <c.lobr...@gmail.com> > > > > --- > > plugins/telit/mm-broadband-modem-telit.c

Re: [PATCH v3] Fix Bug 93135 +CPMS emtpy parameter support

Great! Thanks Carlo On 9 March 2016 at 14:46, Aleksander Morgado <aleksan...@aleksander.es> wrote: > On 09/03/16 11:27, c.lobr...@gmail.com wrote: > > From: Carlo Lobrano <c.lobr...@gmail.com> > > > > * Add new async virtual method init_current_storages to >

Update SIM related data according to an event

Hi all, I'm trying to update some modem data according to an unsolicited event. Telit modems have an unsolicited indication #QSS (Query SIM Status) which is emitted when the SIM status changes (e.g. SIM removed/inserted). My intention is to register an handler to this notification and somehow

Re: Update SIM related data according to an event

t 5:21 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > I'm trying to update some modem data according to an unsolicited event. > > > > Telit modems have an unsolicited indication #QSS (Query SIM Status) > which is > > emitted when the SIM status changes (e.g

Re: Update SIM related data according to an event

Thanks a lot! I'll have a look at that Carlo Il dom 13 mar 2016 11:57 AM Aleksander Morgado <aleksan...@aleksander.es> ha scritto: > On Sun, Mar 13, 2016 at 10:25 AM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > That looks like a lot of work :D, better desig

Re: Update SIM related data according to an event

2016 at 16:50 Carlo Lobrano <c.lobr...@gmail.com> wrote: > Hi Aleksander, > > thank you for this reply, lot of information and clear. > > Carlo > > On 23 March 2016 at 10:06, Aleksander Morgado <aleksan...@aleksander.es> > wrote: > >> Hey! >>

Re: [PATCH] port-probe: make sure stored task pointer is set to NULL before completing

Hi Daniele, it looks like the last commit introduced a some kind of problem. HE910 initialization ends with error > Modem couldn't be initialized: couldn't load current capabilities: Failed to determine modem capabilities Here's the pastebin link of the logs of this test, >

Re: Update SIM related data according to an event

Hi Aleksander, thank you for this reply, lot of information and clear. Carlo On 23 March 2016 at 10:06, Aleksander Morgado <aleksan...@aleksander.es> wrote: > Hey! > > On Tue, Mar 22, 2016 at 3:25 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > I had some t

Re: Update SIM related data according to an event

debugging, when SIM is removed and then re-inserted, like if the port status is invalid, "partially" close). Do you think is a viable solution? Best regards, Carlo On 13 March 2016 at 12:46, Carlo Lobrano <c.lobr...@gmail.com> wrote: > Thanks a lot! I'll have a look at that > &

Re: [PATCH] Fix Bug 93135 +CPMS emtpy parameter not always supported

Task, > instead of GSimpleAsyncResult. No need to rework this patch for that, > just take it into consideration for future patches :) > ​I will ​ > > See comments below. > > On Mon, Mar 7, 2016 at 3:04 PM, <c.lobr...@gmail.com> wrote: > > From: Carlo Lobrano <c.lobr..

Fixing bug 93135 (AT+CPMS error with Telit modems)

e to use the value of "current_sms_mem1_storage" when the local value of mem1 in mm_broadband_modem_lock_sms_storages is UNKNOWN Best regards, Carlo Lobrano ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH] Fixed cgmi_retries in dell_custom_init

Initialized "cgmi_retries" variable from CustomInitContext with the same value as the other retries, moreover the context is now allocated with g_slice_new0. Before this changes, when cgmi_retries assumed big values during the probing of no AT-capable ports, the command AT+CGMI

Re: [PATCH 2/2] Adding a short delay after SIM unlock

o <aleksan...@aleksander.es> wrote: > On Fri, May 13, 2016 at 5:15 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > A short delay is necessary with some SIMs when > > they have just been unlocked. Using 1 second as secure margin. > > I assume there's no SIM status notif

Re: [PATCH 2/2] Telit plugin: add support to SIM hot swap

On 11 July 2016 at 14:09, Aleksander Morgado wrote: > You shouldn't be passing the return of g_regex_new() directly to > mm_port_serial_at_add_unsolicited_msg_handler(), as that method takes > its own reference of the GRegex, and therefore the regex would be > leaking

[PATCH 1/2] Modem: support SIM hot swap (4th attempt)

BaseModem added reprobe property. MMDevice added logic to recreate the modem if it is set invalid and "to reprobe" MMBroadbandModem * added initialization step for SIM hot swap: 1. keep dedicated ports open to listen to modem's unsolicited 2. dedicated error management in case of

[PATCH 2/2] Telit: add support to SIM hot swap (4th attempt)

MMBroadbandModemTelit: * added logic to set MMBroadbandModem's SIM_HOT_SWAP property to TRUE * added function to enable QSS unsolicited * added QSS unsolicited handler --- plugins/telit/mm-broadband-modem-telit.c | 141 ++- 1 file changed, 140 insertions(+), 1

[PATCH 1/2] Extended wda set format message to enable QMUX

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

[PATCH 2/2] Added WDS Bind Mux Data Port message

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

Re: Data ports and maximum number of bearers

Thanks in advance, Carlo On 23 September 2016 at 09:44, Carlo Lobrano <c.lobr...@gmail.com> wrote: > Hi Bjørn, > > thanks for this reply, it's full of information! > > Carlo > > On 20 September 2016 at 11:16, Bjørn Mork <bj...@mork.no> wrote: > >>

Re: Data ports and maximum number of bearers

om> wrote: > On Mon, 2016-09-19 at 12:38 +0200, Aleksander Morgado wrote: > > On Mon, Sep 19, 2016 at 11:20 AM, Carlo Lobrano <c.lobr...@gmail.com> > > wrote: > > > > > > > > > I have a question about the maximum number of bearers that can be >

Fallback MBIM on custom plugin

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

[PATCH] Telit: Optimized supported and current band code

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

Re: [PATCH] Telit: Blacklist LE866 flashing device

Oh sure, no problem On 7 December 2016 at 16:22, Dan Williams <d...@redhat.com> 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

[PATCH v2] Telit: Blacklist LE866 flashing device

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

[PATCH] Telit: Blacklist LE866 flashing device

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

[PATCH] [Telit Plugin] Wrong port peek in telit_qss_toggle_ready

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

[PATCH v2] Fixed wrong MEM1 value passed to +CPMS

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

Re: [PATCH] telit: support QMI and MBIM modems

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

Re: [PATCH] telit: don't require udev tags to bind devices

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 <c.lobr...@gmail.com> wrote: > Hi, > > sure I can test it today or the next week > > BR, > Carlo > > On 24 March 2017 at 14:5

Re: Flow control settings for RS232 modems

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

[PATCH v4] Fixed wrong MEM1 value passed to +CPMS

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()

Re: [PATCH v2] Fixed wrong MEM1 value passed to +CPMS

Sure, I didn't see the other error. I'll update the patch Il venerdì 24 marzo 2017, Aleksander Morgado <aleksan...@aleksander.es> ha scritto: > Hey Carlo, > > On Fri, Mar 24, 2017 at 12:48 PM, Carlo Lobrano <c.lobr...@gmail.com> wrote: >> Let modem_messaging_

[PATCH v3] Fixed wrong MEM1 value passed to +CPMS

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

[PATCH] Fixed wrong MEM1 value passed to +CPMS

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

Re: [PATCH] Fixed wrong MEM1 value passed to +CPMS

efault_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 <aleksan...@aleksander.es> wrote: > On Thu, Mar 23, 2017 at 2:29 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > Let mem1_str defaul

Re: [PATCH] Fixed wrong MEM1 value passed to +CPMS

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 <aleksan...@aleksander.es> wrote: > On Thu, Mar 23, 2017 at 5:32 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >> So why is current_sm

Re: [PATCH] telit: don't require udev tags to bind devices

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

Re: SIM hot swap with SIM locked

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 16:45:17 D2040 ModemManager[3946]: Got failure code 10: SIM not inserted On Fri, 17 Mar 2017 at 14:

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

t;aleksan...@aleksander.es> wrote: > On Fri, Mar 17, 2017 at 10:23 AM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > > > I tested your patch and it seems working fine, even if #QSS: 3 always > > arrives very late respect any acceptable timeout (the modem

Re: SIM hot swap with SIM locked

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, 17 Mar 2017 at 11:15 Carlo Lobrano <c.lobr...@gma

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

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 <aleksan...@aleksander.es> wrote: > On Fri, Mar 17, 2017 at 10

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

Mar 2017 at 12:00 Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Fri, Mar 17, 2017 at 11:39 AM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > > Well, before "#QSS: 3" you can expect some errors accessing the SIM, but > > it's not forbidden, an

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

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 >

Re: [PATCH v2] telit: lock/unlock CSIM operations by default

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

Re: [PATCH v2] telit: lock/unlock CSIM operations by default

#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 <aleksan...@aleksander.es> wrote: > On Thu, Mar 16, 2017 at 10:58 AM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > &g

[PATCH] telit: add error_code recognition to +CSIM parser

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:

[PATCH v2] telit: add error_code recognition to +CSIM parser

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:

[PATCH v3] telit: add error_code recognition to +CSIM parser

- 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

[PATCH v2] telit: unsupported CSIM lock should not skip loading unlock retries

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

[PATCH] telit: give load lock retries steps a descriptive name

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

[PATCH v3] telit: unsupported CSIM lock should not skip loading unlock retries

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

Re: [PATCH v4] telit: add error_code recognition to +CSIM parser

0:46, Aleksander Morgado <aleksan...@aleksander.es> 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 > >

Re: cinterion: modification to fetching unlock retries

Il martedì 18 aprile 2017, Aleksander Morgado <aleksan...@aleksander.es> ha scritto: > On Tue, Apr 18, 2017 at 9:59 AM, Carlo Lobrano <c.lobr...@gmail.com > <javascript:;>> wrote: > > the examples in the docs do not show quoted strings, but I just gave a > try

[PATCH v4] telit: add error_code recognition to +CSIM parser

- 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

Re: [PATCH] telit: add error_code recognition to +CSIM parser

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

[PATCH v3] telit-plugin: ignore QSS when SIM-ME interface is locked

With some modems, the lock/unlock of the SIM-ME interface with +CSIM=1/0 command is followed by #QSS unsolicited messages. With the current implementation, this messages are mistaken for SIM swap events and so the modem is first dropped and then re-probed. With this patch, the plugin takes into

Re: Handling QSS unsolicited in power state transitions

​> This is getting a bit out of hands :) I felt the same :) > So, yes, if the module powers off the SIM slot during CFUN=4 we won't > get #QSS events, that's understandable. But... what would happen if we > go to low power mode and switch the SIM card with a different one? We > would be gettting

[PATCH] sim hot swap: improved error management

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

Re: [PATCH] sim hot swap: improved error management

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

Re: sim hot swap problem with Telit GE910-QUAD

Hi Tim, > I think that the commands which mm issue causes it to close and reopen > the SIM and this takes longer than mm is giving it. How should I work > around this? This modem has an unsolicited signal (QSS) that shows the presence and status of the SIM. According to this signal, it seems

Re: sim hot swap problem with Telit GE910-QUAD

Hi Aleksander, Tim, I just reproduced the issue on my hardware, so I can develop a patch for > this > after some analysis, I think that the fix for this issue should count two steps 1. When +CSIM=1 is sent, the QSS handler should ignore QSS unsolicited -> I brefly solved this with a

Re: [PATCH] sim hot swap: improved error management

> More importantly, after SIM hot swap is set up, an 'ATZ' command is > issued which resets the modem to power on state and so turns off sim hot > swap notification. I can't reproduce this issue. I see the ATZ command, but I still receive each QSS notification. By the way, do you mind if I

Re: [PATCH] sim hot swap: improved error management

> Thanks for the patch. It doesn't seem to be working here unfortunately. this is the patch to improve SIM hot swap error management in both AT and MBIM based modems :) The patch for GE910-QUAD is in thread "[PATCH] telit-plugin: ignore QSS when SIM-ME interface is locked" On Tue, 25 Jul

[PATCH] telit-plugin: ignore QSS when SIM-ME interface is locked

With some modems, the lock/unlock of the SIM-ME interface with +CSIM=1/0 command is followed by #QSS unsolicited messages. With the current implementation, this messages are mistaken for SIM swap events and so the modem is first dropped and then re-probed. With this patch, the plugin takes into

Re: [PATCH v2] sim hot swap: improved error management

oss.co.uk> wrote: > On 24/07/17 12:54, Carlo Lobrano wrote: > > 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 inserti

Re: sim hot swap problem with Telit GE910-QUAD

> I'll be back with the patch Sorry, I made a mistake and created a new thread. The patch is in "[PATCH] telit-plugin: ignore QSS when SIM-ME interface is locked" On Mon, 24 Jul 2017 at 12:27 Carlo Lobrano <c.lobr...@gmail.com> wrote: > That sounds perfect. > I'

Re: [PATCH] telit-plugin: ignore QSS when SIM-ME interface is locked

>> +csim_unlock_complete (self->priv->csim_lock_task); > Reset the csim_lock_task pointer here to NULL, please. Can I do this inside csim_unlock_complete or there is a reason to do it outside this function? On Tue, 25 Jul 2017 at 14:28 Carlo Lobrano <c.lobr..

Re: [PATCH] telit-plugin: ignore QSS when SIM-ME interface is locked

That's right, thank you On Wed, 26 Jul 2017 at 12:21 Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Wed, Jul 26, 2017 at 10:36 AM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >>> +csim_unlock_complete (self->priv->csim_lock_task); &

Re: sim hot swap problem with Telit GE910-QUAD

That sounds perfect. I'll be back with the patch On Mon, 24 Jul 2017 at 12:16 Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Mon, Jul 24, 2017 at 12:02 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >> What would happen if you completely disa

[PATCH v2] sim hot swap: improved error management

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

Re: MC7455 sporadically wrong primary port

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

Re: Re: Issues with modem reset

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

Re: Handling QSS unsolicited in power state transitions

/enabling its emission. On Tue, 1 Aug 2017 at 13:14 Carlo Lobrano <c.lobr...@gmail.com> wrote: > Yes, I agree. That's why it's on a different patch > > On Tue, 1 Aug 2017, 13:12 Aleksander Morgado, <aleksan...@aleksander.es> > wrote: > >> On Tue, Aug 1, 2017 at 12:31 PM, C

Re: [PATCH] sim hot swap: improved error management

ap notifiation. In practise this is highly unlikely, but > just thought I'd mention it. and thanks Tim, you're right, I'll work on this as well On 1 August 2017 at 10:34, Aleksander Morgado <aleksan...@aleksander.es> wrote: > On 25/07/17 09:03, Carlo Lobrano wrote: > > Cu

Re: Handling QSS unsolicited in power state transitions

ling on CFUN=1, but not around the same command. On 1 August 2017 at 10:32, Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On 01/08/17 10:04, Carlo Lobrano wrote: > > last week I was working to handle a behavior that most of the Telit modem > > have, that is,

Re: Handling QSS unsolicited in power state transitions

Yes, I agree. That's why it's on a different patch On Tue, 1 Aug 2017, 13:12 Aleksander Morgado, <aleksan...@aleksander.es> wrote: > On Tue, Aug 1, 2017 at 12:31 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >> Aren't the sim hot swap unsolicited messages

Re: Handling QSS unsolicited in power state transitions

OK, I'll need some time to understand at which level make the changes, but I think it's fine On 2 August 2017 at 19:19, Aleksander Morgado wrote: > >> Note that this issue is again unrelated to the actual hot sim swapping > >> logic implemented; but now that we're

Re: MMKernelDevice ID_USB_INTERFACE_NUM property isn't set anymore

r Morgado wrote: > > On Wed, May 3, 2017 at 2:09 PM, Carlo Lobrano <c.lobr...@gmail.com> > > wrote: > > > > > > When using the "udev" backend, which you are, the property > > > > > > isn't > > > > > > "loa

Re: MMKernelDevice ID_USB_INTERFACE_NUM property isn't set anymore

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 <c.lobr...@gmail.com> wrote: > By chance I have another Ubuntu machine, which is 17.04 while

Re: MMKernelDevice ID_USB_INTERFACE_NUM property isn't set anymore

On 3 May 2017 at 12:47, Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Wed, May 3, 2017 at 12:10 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >> When using the "udev" backend, which you are, the property isn't > >> "loaded&

Re: [PATCH 2/2] dell: speed probing time up and reduce udev dependency

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​ ___

Re: [PATCH 2/2] dell: removed ID_MM_TELIT_PORTS_TAGGED dependency

t again even part 1? On 10 May 2017 at 21:22, Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Wed, May 10, 2017 at 4:34 PM, Carlo Lobrano <c.lobr...@gmail.com> > wrote: > >> Could you gather debug logs using the Telit/Dell modem in 2 different > >&

[PATCH 1/2] telit: removed ID_MM_TELIT_PORTS_TAGGED dependency

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

[PATCH 2/2] dell: speed probing time up and reduce udev dependency

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

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

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​ ___

Re: [PATCH] broadband-modem: don't create sim hot swap ports context multiple times

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 >

Re: [PATCH] telit: manage QSS transistions

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

Re: [PATCH 2/2] dell: speed probing time up and reduce udev dependency

Awesome! Thank you! Carlo On 29 May 2017 at 12:27, Aleksander Morgado <aleksan...@aleksander.es> 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

Re: [PATCH] telit: enable 'SIM ready' notifications with #QSS=2

h, 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 <c.lobr...@gmail.com> wrote: > > On 16 May 2017 at 10:53, Aleksander Morgado <aleksan...@aleksander.es> > wrote: > >> But g_simple_async_result

  1   2   >