[PATCH] altair-lte: don't use send-delay=0

As observed on some modems, send-delay=0 seems to break port probing. --- plugins/altair/mm-plugin-altair-lte.c | 1 - 1 file changed, 1 deletion(-) diff --git a/plugins/altair/mm-plugin-altair-lte.c b/plugins/altair/mm-plugin-altair-lte.c index 2338502b..7f6a7c0b 100644 ---

[PATCH] huawei: ensure MMBearerConnectResult populated into GSimpleAsyncResult

During the CONNECT_3GPP_CONTEXT_STEP_LAST step, connect_3gpp_context_step() conditionally creates and populates a MMBearerConnectResult object into the GSimpleAsyncResult object when the ipv4_config field of the Connect3gppContext struct is set. That assumes the ipv4_config field is always

Re: Handling QSS unsolicited in power state transitions

On Tue, Aug 1, 2017 at 4:40 PM, Carlo Lobrano wrote: > It seems that sometimes the decision to send the #QSS=0 is taken with some > delay (with HE910) and in these cases it arrives quite late (10-13 seconds) > and disabling the notifications and then re-enabling them later

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

> Pushed to git master, thanks. Thanks! > I suppose there is a bit of a race in the code, because: > > First the current SIM insertion state is checked (with AT#QSS?), and > stored, and afterwards unsolicited notifications are enabled "AT#QSS=1". > > If a SIM eject happens between the two, then

Re: Handling QSS unsolicited in power state transitions

It seems that sometimes the decision to send the #QSS=0 is taken with some delay (with HE910) and in these cases it arrives quite late (10-13 seconds) and disabling the notifications and then re-enabling them later does not avoid it. Considered this, I would go with ignoring #QSS unsolicited

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, wrote: > On Tue, Aug 1, 2017 at 12:31 PM, Carlo Lobrano > wrote: > >> Aren't the sim hot swap unsolicited messages received always, regardless > >> of

Re: Handling QSS unsolicited in power state transitions

On Tue, Aug 1, 2017 at 12:31 PM, Carlo Lobrano wrote: >> Aren't the sim hot swap unsolicited messages received always, regardless >> of whether the modem is enabled or disabled? > > disabling_stopped function releases both ports contexts, so we don't receive > unsolicited on

Re: Handling QSS unsolicited in power state transitions

> Aren't the sim hot swap unsolicited messages received always, regardless of whether the modem is enabled or disabled? disabling_stopped function releases both ports contexts, so we don't receive unsolicited on SIM swap ports. > The only issue is when getting #QSS=0 after a +CFUN=4, right?

Re: ATZ in enabling_modem_init() step

On 27/07/17 11:15, Tim Small wrote: >>> I wonder if issuing ATZ is the right thing to do here at all? >>> >>> It's trying to reset the modem to a well-known state, but ATZ doesn't do >>> that - it loads the default user defined profile - which could be >>> anything that the user or another piece

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

On 25/07/17 09:03, 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 insertion, > instead of clearly saying that SIM hot

Re: Handling QSS unsolicited in power state transitions

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, they emit *#QSS* unsolicited in consequence of *+CFUN* > commands. Most of the times, the modems are already in *+CFUN=1* at the > start so we did not notice it in

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

On 28/07/17 15:57, Carlo Lobrano wrote: > 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