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-
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 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 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, Jose
Carlo & Daniele in CC, to see if they can shed some light.
>
I'm looking into it
Carlo
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-deve
On Jan 4 2018, at 2:05 pm, Carlo Lobrano wrote:
> I'll have a look at that today or tomorrow at the most, thanks a lot!
>
I tested the patch on both LE910 and HE910 (just to test a modem that supports
csim lock and one that does not) and it looks very g
Hi Aleksander,
On Jan 1 2018, at 7:35 pm, Aleksander Morgado wrote:
> The generic broadband modem provides a common method to load unlock
> retries based on CSIM queries. We modify the Telit plugin to use the
> generic method but keeping the CSIM locking/unlocking logic in place.
> ---
>
> Hey Ca
Hey,
> +Carlo in CC for review/test as he's probably interested in this change.
It makes totally sense and looks good to me
Carlo
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin
> This is actually a good test, thank you!
>
>
>
>
>
You're welcome :)
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Hi Aleksander,
On Nov 20 2017, at 2:33 pm, Carlo Lobrano wrote:
> Hi Aleksander,
>
> > I plan to get this merged to git master sometime this week; tests and
> > comments welcome!
>
> I plan to have some testing done in the next couple of days
>
> Carlo
I just teste
Hi Aleksander,
> I plan to get this merged to git master sometime this week; tests and
> comments welcome!
I plan to have some testing done in the next couple of days
Carlo
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
h
> Of course it looks great, I just want to have a try tomorrow on a modem
to double check it.
Double checked, all green. Thanks a lot!
On 4 September 2017 at 18:41, Carlo Lobrano wrote:
> Of course it looks great, I just want to have a try tomorrow on a modem to
> double check it.
Of course it looks great, I just want to have a try tomorrow on a modem to
double check it.
On 4 September 2017 at 18:29, Carlo Lobrano wrote:
> > Using its own GTask ends up requiring the extra _ready() method, but
> that
> > makes the flow much more clear and consistent I thi
xplanation and the fixes!
On 4 September 2017 at 18:09, Aleksander Morgado
wrote:
> Hey!
>
> On Mon, Sep 4, 2017 at 8:13 AM, Carlo Lobrano wrote:
> > When transitioning between power-low and power-on modes, Telit modems
> > switch the SIM off/on, which leads to the emissio
When transitioning between power-low and power-on modes, Telit modems
switch the SIM off/on, which leads to the emission of #QSS unsolicited not
related to actual SIM swaps.
To handle this #QSS unsolicited, this patch:
* disables reacting on #QSS unsolicited when modem_power_down is received
* im
Please, ignore the previous v3 patch... I wasn't compiling the right
project and missed some errors.
On 4 September 2017 at 07:59, Carlo Lobrano wrote:
> When transitioning between power-low and power-on modes, Telit modems
> switch the SIM off/on, which leads to the emiss
When transitioning between power-low and power-on modes, Telit modems
switch the SIM off/on, which leads to the emission of #QSS unsolicited not
related to actual SIM swaps.
To handle this #QSS unsolicited, this patch:
* disables reacting on #QSS unsolicited when modem_power_down is received
* im
When transitioning between power-low and power-on modes, Telit modems
switch the SIM off/on, which leads to the emission of #QSS unsolicited not
related to an actual SIM swap.
To handle this use case, this patch:
* disables reacting on #QSS unsolicited when modem_power_down is received
* implemen
> Pushed to git master after fixing up the change in the file mode line,
> which I assume wasn't on purpose :)
Indeed, I don't even know how I made it :D
Thanks
On 29 August 2017 at 11:20, Aleksander Morgado
wrote:
> On Tue, Aug 29, 2017 at 9:15 AM, Carlo Lobrano
> wro
Currently when the modem is disabled, it releases SIM hot swap ports context,
and is not able to receive any notification about the SIM status.
This patch keeps these ports opened when Modem is disabled and released them
only when SIM swap is detected or when modem is released.
---
If I understoo
2017 at 07:34, Aleksander Morgado
wrote:
> On 28/08/17 14:18, Carlo Lobrano wrote:
> > Currently when the modem is disabled, it also releases SIM hot swap
> ports context,
> > and it is not able to receive any notification about the SIM status
> anymore.
> >
> > Thi
Currently when the modem is disabled, it also releases SIM hot swap ports
context,
and it is not able to receive any notification about the SIM status anymore.
This patch keeps these ports opened when Modem is disabled and released them
only when SIM swap is detected.
---
Hi Aleksander,
as you
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 starting to support hot sim
> >
> 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
ot swap 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
wrote:
> On 25/07/17 09:03, Carlo Lobrano wrote:
> > Currently, when SIM ho
disabling/enabling its
emission.
On Tue, 1 Aug 2017 at 13:14 Carlo Lobrano wrote:
> 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:
>
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 w
out disabling on CFUN=4
and re-enabling on CFUN=1, but not around the same command.
On 1 August 2017 at 10:32, Aleksander Morgado
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 i
Hi all,
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 a normal power up, but if we put the mode
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 ac
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 ac
That's right, thank you
On Wed, 26 Jul 2017 at 12:21 Aleksander Morgado
wrote:
> On Wed, Jul 26, 2017 at 10:36 AM, Carlo Lobrano
> wrote:
> >>> +csim_unlock_complete (self->priv->csim_lock_task);
> >> Reset the csim_lock_task pointer here
>> +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 wrote:
> >
age the two references and I didn't
think I actually don't need it.
On Tue, 25 Jul 2017 at 14:10 Aleksander Morgado
wrote:
> Hey,
>
> On Mon, Jul 24, 2017 at 6:23 PM, Carlo Lobrano
> wrote:
> > With some modems, the lock/unlock of the SIM-ME interface with +CSIM=1/0
&g
> 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 report
> 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 201
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
> 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 wrote:
> That sounds perfect.
> I'll be back with the pat
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 ac
e:
> 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 insertion,
> >
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
That sounds perfect.
I'll be back with the patch
On Mon, 24 Jul 2017 at 12:16 Aleksander Morgado
wrote:
> On Mon, Jul 24, 2017 at 12:02 PM, Carlo Lobrano
> wrote:
> >> What would happen if you completely disable and enable the handlers >
> with
> >> the metho
> What would happen if you completely disable and enable the handlers >
with the method I'm suggesting, and then you just let the #QSS=1 >
indication happen? If the modem already had a SIM inserted, an extra >
#QSS=1 wouldn't harm, right? Won't it be just ignored when it's
> processed?
You're righ
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 "*is_csim_
> Carlo, what do you think?
I just reproduced the issue on my hardware, so I can develop a patch for
this
On 21 July 2017 at 09:58, Aleksander Morgado
wrote:
> >> Oh wait, what happened here?... How did we "recreate" the modem object
> >> and we're still sending AT+CSIM commands?
> >
> > Would
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 tha
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).
_
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
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 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
&
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
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
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
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 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
> 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
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
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
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
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
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 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
> 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, 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
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
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
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
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
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 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
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
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 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
> 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
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
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
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'
>>
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
>
>
> 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
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-
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
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
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
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
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
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
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_
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
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
- 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
-
>
> 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
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
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,
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
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
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
1 - 100 of 216 matches
Mail list logo
