Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-21 Thread José 
On Wed, Jan 20, 2016 at 11:32 AM, Aleksander Morgado
 wrote:
>
> Actually, why don't you try to get the modem fully connected manually
> with qmicli or qmi-network and see if you still see the same issues
> when ModemManager's logic is not around?
>

With qmicli and qmi-network the problem persist.

My workaround was to set the modem in full power mode (AT+CFUN=1) and
then store this state as the default in the non volatile memory
(AT).

With the new firmware the modem is working worse, it resets when connecting...

I will update if I find a better solution.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-20 Thread Aleksander Morgado 
Hey,

>>
>> Yes, it should be using the Telit plugin.
>>
>>
>
> I was adding the udev rules for the LE910 in the
> 77-mm-telit-port-types.rules file when I saw the following comment:
>
> # NOTE: Qualcomm Gobi-based devices like the LE920 should not be handled
> # by this plugin, but by the Gobi plugin.
>
> The Telit LE910 is a Gobi based device ('The LE910, based on Qualcomm
> Technologies' Gobi™ MDM9215 ...' from
> http://www.telit.com/media/press-releases/press-releases/view/item/telit-expands-its-qualcomm-technologies-based-portfolio-with-new-lte-concept-product/)
> so I guess it should have been managed by the Gobi plugin.
>

In git master, that would be the Telit plugin itself managing the QMI
modem, that's what I was suggesting. In 1.4.12, yeah, could be the
Gobi plugin or directly the Generic one which both have QMI support.

> I am using ModemManager 1.4.12, but I removed the Gobi plugin because
> it was not working properly with the Sierra MC7710. So, is the generic
> plugin afterall a good candidate for Telit LE910? (in general it works
> really well, it is only problematic for this power management issues)
>

As long as the plugin managing the modem is a QMI based one, yes, you're good.

> I will also test if the power mode is changing correctly using qmicli
> -d /dev/cdc-wdm1 --dms-get-operating-mode and qmicli -d /dev/cdc-wdm1
> --dms-set-operating-mode when I have the modem available.

Actually, why don't you try to get the modem fully connected manually
with qmicli or qmi-network and see if you still see the same issues
when ModemManager's logic is not around?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-20 Thread José 
On Tue, Jan 19, 2016 at 5:34 PM, Aleksander Morgado
 wrote:
>
> Yes, it should be using the Telit plugin.
>
>

I was adding the udev rules for the LE910 in the
77-mm-telit-port-types.rules file when I saw the following comment:

# NOTE: Qualcomm Gobi-based devices like the LE920 should not be handled
# by this plugin, but by the Gobi plugin.

The Telit LE910 is a Gobi based device ('The LE910, based on Qualcomm
Technologies' Gobi™ MDM9215 ...' from
http://www.telit.com/media/press-releases/press-releases/view/item/telit-expands-its-qualcomm-technologies-based-portfolio-with-new-lte-concept-product/)
so I guess it should have been managed by the Gobi plugin.

I am using ModemManager 1.4.12, but I removed the Gobi plugin because
it was not working properly with the Sierra MC7710. So, is the generic
plugin afterall a good candidate for Telit LE910? (in general it works
really well, it is only problematic for this power management issues)

I will also test if the power mode is changing correctly using qmicli
-d /dev/cdc-wdm1 --dms-get-operating-mode and qmicli -d /dev/cdc-wdm1
--dms-set-operating-mode when I have the modem available.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread José 
The problem only occurs if the LE910 was in low power mode (AT+CFUN=4) when
plugged to the embbeded device. Does ModemManager manage power state modes?
Should it automatically full enable the modem (AT+CFUN=1) when issuing
mmcli --simple-connect?

I am going to test with a new firmware I have received from Telit and check
if the issue is reproducible.

On Mon, Jan 18, 2016 at 6:04 PM, Dan Williams  wrote:

> On Mon, 2016-01-18 at 16:55 +0100, José  wrote:
> > I was not sure what caused the 'limited' registration state... I am
> > going to check if there is any firmware updates available and try
> > that.
> >
> > They all are nanoSIM. Not sure if there is any errors when using
> > Movistar and Yoigo SIMs, I will try it out and check the logs as soon
> > as I can.
>
> Yes, some SIMs cannot be read by some modems.
>
> For example, there is a bug in older Icera-based modems (Nokia 21M-02,
> Samsung Y3300 and Y3400, T-Mobile Rocket 2, Option GIO-322) that
> refuses to read T-Mobile USA SIMs that have Isis/Softcard mobile wallet
> capabilities.  Other, non-Isis-branded T-Mobile USA SIMs do not have
> this problem.  These Icera devices will never receive a firmware update
> to fix the problem, so they will remain incompatible forever.
>
> For the Telit device, your only recourse would be to ask Telit if it is
> a known bug, and request an updated firmware to fix the issue.  Or use
> a different SIM :(
>
> Dan
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread Aleksander Morgado 
On Tue, Jan 19, 2016 at 9:55 PM, c.lobr...@gmail.com
 wrote:
>
>> I have also noticed that ModemManager uses not documented AT+CFUN modes:
>>
>> root at ccimx6sbc:~# mmcli -m 0 --set-power-state-off
>> ModemManager[791]:  Modem powered off... may no longer be accessible
>> successfully set new power state in the modem
>> root at ccimx6sbc:~# microcom /dev/ttyUSB2
>>
>> OK
>> at+cfun?
>> +CFUN: 7
>>
>> OK
>> root at ccimx6sbc:~# mmcli -m 0 --set-power-state-low
>> successfully set new power state in the modem
>> root at ccimx6sbc:~# microcom /dev/ttyUSB2
>> at+cfun?
>> +CFUN: 6
>>
>> OK
>>
>> The only documented modes are 0, 1, 4 ,5 (see
>>
>> http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf,
>> page 106).
>
> Here you can find a more recent document that defines also state 7
>
> http://www.telit.com/products/cellular/4g/
>
> e.g. If your modem is a LE910 (namely non V2):
>
> Parameters:
>
>  - is the power saving function mode
> 0 - minimum functionality, NON-CYCLIC SLEEP mode
> 1 - mobile full functionality with power saving disabled (factory default)
> 2 - disable TX (Not support)
> 4 - disable both TX and RX
> 5 - mobile full functionality with power saving enabled
> Special modes , you can see them through the read command but you can't set
> those
> mode :
> 7 – Offline mode
> 8 – FTM

The key point, though, is that the modem is being managed in QMI mode,
not via AT commands. I wonder if the "QMI DMS operating system"
request/responses aren't enough or something.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread Aleksander Morgado 
Hey!

On Tue, Jan 19, 2016 at 6:36 PM, José  wrote:
> Looking at 
> http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/telit/mm-plugin-telit.c?id=1.4.12
> seems like the Telit plugin only handles tty port, but I am using QMI
> with the Telit LE910. Should it still be using the Telit plugin?
>

Ideally, the Telit plugin itself should be able to manage QMI modems.
That is what I was targeting to do in git master, no more generic
"gobi" plugin.

> The following lines appear at the log (in this order):
>
> (Telit) [wwan0] filtered by subsystem
> (Telit) [ttyUSB4] filtered by udev tags
> (Telit) [ttyUSB1] filtered by udev tags
> (Telit) [ttyUSB2] filtered by udev tags
> (Telit) [ttyUSB3] filtered by udev tags
> (Telit) [ttyUSB0] filtered by udev tags
> (Telit) [cdc-wdm0] filtered by subsystem
>

That means there are no udev tags for your device, I guess.

> I think at least one of the ttyUSBn device nodes should NOT filter
> Telit plugin, right? From the code:
>

Yes. All of them should have udev tags; check the udev rules in the
plugins/telit directory.

> /* If we didn't match any udev tag: unsupported */
> if (!self->priv->udev_tags[i]) {
> mm_dbg ("(%s) [%s] filtered by udev tags",
> self->priv->name,
> g_udev_device_get_name (port));
> return TRUE;
> }
>
>
> I have been looking at
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=mm-1-4=0505021ac6c79c28bd28184a9daa988b0712c71f
> and seems like the idProduct is not in the udev rules. Should the
> idProduct 1201 be added? Looking around (for exapmle
> http://www.spinics.net/lists/linux-usb/msg115457.html) seems like this
> is the right productId for Telit LE910.
>
> I attach all the relevant information (I think) for the modem.
>

Also, as said earlier, I would make sure the Telit plugin handles QMI
when QMI is found, so that we see the Telit plugin managing the modem,
even if it's using the generic QMI implementation; in that way we
could subclass the QMI implementation in the plugin directly if needed
(as we do for Cinterion to provide AT-based GPS management given that
no QMI service is implemented).

So, to recap:
 * Check if you can add udev tags for your device in the Telit plugin
udev rules.
 * Check if you can add QMI support in the Telit plugin directly.

Thanks!

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread José 
I have update to the last firmware (17.01.522  1  [Oct 16 2014
07:00:00]) and the issue is still reproducible.

I am almost sure that the issue is related to power management.

When the modem is in AT+CFUN=4, trying to enable it with ModemManager
(mmcli -m 0 -e) does not work. Trying to change the power state does
also not work (mmcli --set-power-state-on).

root@ccimx6sbc:~# mmcli -m 0 --set-power-state-on
ModemManager[791]: Couldn't reload current power state: Unhandled
power state: 'reset' (4)
error: couldn't set new power state in the modem:
'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction:
Couldn't set operating mode: QMI protocol error (60):
'InvalidTransaction''
root@ccimx6sbc:~# mmcli -m 0 -e
ModemManager[791]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (disabled ->
enabling)
ModemManager[791]:   (ttyUSB2): port attributes not fully set
ModemManager[791]:   (ttyUSB3): port attributes not fully set
ModemManager[791]: Couldn't reload current power state: Unhandled
power state: 'reset' (4)
ModemManager[791]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (enabling ->
disabled)
error: couldn't enable the modem:
'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction:
Couldn't set operating mode: QMI protocol error (60):
'InvalidTransaction''

Note that a SIM card is inserted.


I have also noticed that ModemManager uses not documented AT+CFUN modes:

root@ccimx6sbc:~# mmcli -m 0 --set-power-state-off
ModemManager[791]:   Modem powered off... may no longer be accessible
successfully set new power state in the modem
root@ccimx6sbc:~# microcom /dev/ttyUSB2

OK
at+cfun?
+CFUN: 7

OK
root@ccimx6sbc:~# mmcli -m 0 --set-power-state-low
successfully set new power state in the modem
root@ccimx6sbc:~# microcom /dev/ttyUSB2
at+cfun?
+CFUN: 6

OK

The only documented modes are 0, 1, 4 ,5 (see
http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf,
page 106).

I have noticed that mmcli -m 0 reports that the Generic plugin is
being used. Should it be using some specific for Telit?

Just in case this is the report of mmcli -m 0 when the modem is in low
power state:

root@ccimx6sbc:~# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id
'dff8e6a4b1f4c5db7b0e79cea559b461ae4f450e')
  -
  Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
   |  model: '3'
   |   revision: '17.01.522  1  [Oct 16 2014 07:00:00]'
   |  supported: 'gsm-umts
   |  lte
   |  gsm-umts, lte'
   |current: 'gsm-umts, lte'
   |   equipment id: 'unknown'
  -
  System   | device:
'/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3'
   |drivers: 'qmi_wwan, option1'
   | plugin: 'Generic'
   |   primary port: 'cdc-wdm0'
   |  ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), ttyUSB3
(at), wwan0 (net), cdc-wdm0 (qmi)'
  -
  Numbers  |   own : 'unknown'
  -
  Status   |   lock: 'sim-pin2'
   | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10),
sim-puk2 (10)'
   |  state: 'disabled'
   |power state: 'low'
   |access tech: 'unknown'
   | signal quality: '0' (cached)
  -
  Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
   |current: 'allowed: 2g, 3g, 4g; preferred: none'
  -
  Bands|  supported: 'cdma-bc15-aws, dcs, egsm, u2100, u800,
u850, u900, eutran-iii, eutran-vii, eutran-xx'
   |current: 'cdma-bc15-aws, dcs, egsm, u2100, u800,
u850, u900, eutran-iii, eutran-vii, eutran-xx'
  -
  IP   |  supported: 'ipv4, ipv6, ipv4v6'
  -
  3GPP |   imei: 'unknown'
   |  enabled locks: 'none'
   |operator id: 'unknown'
   |  operator name: 'unknown'
   |   subscription: 'unknown'
   |   registration: 'unknown'
  -
  SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'

  -
  Bearers  |  paths: 'none'

On Tue, Jan 19, 2016 at 10:29 AM, Aleksander Morgado
 wrote:
> On 19/01/16 10:13, José  wrote:
>> The problem only occurs if the LE910 was in low power mode (AT+CFUN=4) when
>> plugged to the embbeded device. Does ModemManager manage power state modes?
>> Should it automatically full enable the modem (AT+CFUN=1) when issuing
>> mmcli --simple-connect?
>>
>
> Yes, that we do by default, unless something is wrong somewhere. You can
> check the debug logs and look for that command being sent I guess.
>
> --
> Aleksander
> https://aleksander.es
___

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread Aleksander Morgado 
On Tue, Jan 19, 2016 at 4:51 PM, José  wrote:
> I have update to the last firmware (17.01.522  1  [Oct 16 2014
> 07:00:00]) and the issue is still reproducible.
>
> I am almost sure that the issue is related to power management.
>
> When the modem is in AT+CFUN=4, trying to enable it with ModemManager
> (mmcli -m 0 -e) does not work. Trying to change the power state does
> also not work (mmcli --set-power-state-on).
>
> root@ccimx6sbc:~# mmcli -m 0 --set-power-state-on
> ModemManager[791]: Couldn't reload current power state: Unhandled
> power state: 'reset' (4)
> error: couldn't set new power state in the modem:
> 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction:
> Couldn't set operating mode: QMI protocol error (60):
> 'InvalidTransaction''
> root@ccimx6sbc:~# mmcli -m 0 -e
> ModemManager[791]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: state changed (disabled ->
> enabling)
> ModemManager[791]:   (ttyUSB2): port attributes not fully set
> ModemManager[791]:   (ttyUSB3): port attributes not fully set
> ModemManager[791]: Couldn't reload current power state: Unhandled
> power state: 'reset' (4)
> ModemManager[791]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: state changed (enabling ->
> disabled)
> error: couldn't enable the modem:
> 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.InvalidTransaction:
> Couldn't set operating mode: QMI protocol error (60):
> 'InvalidTransaction''
>
> Note that a SIM card is inserted.
>
>
> I have also noticed that ModemManager uses not documented AT+CFUN modes:
>
> root@ccimx6sbc:~# mmcli -m 0 --set-power-state-off
> ModemManager[791]:   Modem powered off... may no longer be accessible
> successfully set new power state in the modem
> root@ccimx6sbc:~# microcom /dev/ttyUSB2
>
> OK
> at+cfun?
> +CFUN: 7
>
> OK
> root@ccimx6sbc:~# mmcli -m 0 --set-power-state-low
> successfully set new power state in the modem
> root@ccimx6sbc:~# microcom /dev/ttyUSB2
> at+cfun?
> +CFUN: 6
>
> OK
>
> The only documented modes are 0, 1, 4 ,5 (see
> http://www.coniugo.de/tl_files/dateien/downloads/at/AT%20Commands%20LE910.pdf,
> page 106).
>
> I have noticed that mmcli -m 0 reports that the Generic plugin is
> being used. Should it be using some specific for Telit?
>

Yes, it should be using the Telit plugin.


> Just in case this is the report of mmcli -m 0 when the modem is in low
> power state:
>
> root@ccimx6sbc:~# mmcli -m 0
>
> /org/freedesktop/ModemManager1/Modem/0 (device id
> 'dff8e6a4b1f4c5db7b0e79cea559b461ae4f450e')
>   -
>   Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
>|  model: '3'
>|   revision: '17.01.522  1  [Oct 16 2014 07:00:00]'
>|  supported: 'gsm-umts
>|  lte
>|  gsm-umts, lte'
>|current: 'gsm-umts, lte'
>|   equipment id: 'unknown'
>   -
>   System   | device:
> '/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3'
>|drivers: 'qmi_wwan, option1'
>| plugin: 'Generic'
>|   primary port: 'cdc-wdm0'
>|  ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), ttyUSB3
> (at), wwan0 (net), cdc-wdm0 (qmi)'
>   -
>   Numbers  |   own : 'unknown'
>   -
>   Status   |   lock: 'sim-pin2'
>| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10),
> sim-puk2 (10)'
>|  state: 'disabled'
>|power state: 'low'
>|access tech: 'unknown'
>| signal quality: '0' (cached)
>   -
>   Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
>|current: 'allowed: 2g, 3g, 4g; preferred: none'
>   -
>   Bands|  supported: 'cdma-bc15-aws, dcs, egsm, u2100, u800,
> u850, u900, eutran-iii, eutran-vii, eutran-xx'
>|current: 'cdma-bc15-aws, dcs, egsm, u2100, u800,
> u850, u900, eutran-iii, eutran-vii, eutran-xx'
>   -
>   IP   |  supported: 'ipv4, ipv6, ipv4v6'
>   -
>   3GPP |   imei: 'unknown'
>|  enabled locks: 'none'
>|operator id: 'unknown'
>|  operator name: 'unknown'
>|   subscription: 'unknown'
>|   registration: 'unknown'
>   -
>   SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'
>
>   -
>   Bearers  |  paths: 'none'
>



-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-19 Thread José 
Looking at 
http://cgit.freedesktop.org/ModemManager/ModemManager/tree/plugins/telit/mm-plugin-telit.c?id=1.4.12
seems like the Telit plugin only handles tty port, but I am using QMI
with the Telit LE910. Should it still be using the Telit plugin?

The following lines appear at the log (in this order):

(Telit) [wwan0] filtered by subsystem
(Telit) [ttyUSB4] filtered by udev tags
(Telit) [ttyUSB1] filtered by udev tags
(Telit) [ttyUSB2] filtered by udev tags
(Telit) [ttyUSB3] filtered by udev tags
(Telit) [ttyUSB0] filtered by udev tags
(Telit) [cdc-wdm0] filtered by subsystem

I think at least one of the ttyUSBn device nodes should NOT filter
Telit plugin, right? From the code:

/* If we didn't match any udev tag: unsupported */
if (!self->priv->udev_tags[i]) {
mm_dbg ("(%s) [%s] filtered by udev tags",
self->priv->name,
g_udev_device_get_name (port));
return TRUE;
}


I have been looking at
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=mm-1-4=0505021ac6c79c28bd28184a9daa988b0712c71f
and seems like the idProduct is not in the udev rules. Should the
idProduct 1201 be added? Looking around (for exapmle
http://www.spinics.net/lists/linux-usb/msg115457.html) seems like this
is the right productId for Telit LE910.

I attach all the relevant information (I think) for the modem.

root@ccimx6sbc:~# lsusb
Bus 001 Device 003: ID 1bc7:1201 Telit

root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB0 | head -100

  looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0':
KERNEL=="ttyUSB0"
SUBSYSTEM=="tty"
DRIVER==""

  looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0':
KERNELS=="ttyUSB0"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"

  looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.0':
KERNELS=="1-1.3:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="option"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="ff"
ATTRS{bInterfaceProtocol}=="ff"
ATTRS{bNumEndpoints}=="02"
ATTRS{supports_autosuspend}=="1"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bInterfaceNumber}=="00"

  looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3':
KERNELS=="1-1.3"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{devpath}=="1.3"
ATTRS{idVendor}=="1bc7"
ATTRS{speed}=="480"
ATTRS{bNumInterfaces}==" 7"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{busnum}=="1"
ATTRS{devnum}=="3"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="500mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="0"
ATTRS{bcdDevice}=="0232"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{serial}=="0123456789ABCDEF"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="11"
ATTRS{ltm_capable}=="no"
ATTRS{manufacturer}=="Android"
ATTRS{removable}=="removable"
ATTRS{idProduct}=="1201"
ATTRS{bDeviceClass}=="00"
ATTRS{product}=="Android"

  looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1':
KERNELS=="1-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="02"
ATTRS{devpath}=="1"
ATTRS{idVendor}=="0424"
ATTRS{speed}=="480"
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{busnum}=="1"
ATTRS{devnum}=="2"
ATTRS{configuration}==""
ATTRS{bMaxPower}=="2mA"
ATTRS{authorized}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bNumConfigurations}=="1"
ATTRS{maxchild}=="4"
ATTRS{bcdDevice}=="0bb3"
ATTRS{avoid_reset_quirk}=="0"
ATTRS{quirks}=="0x0"
ATTRS{version}==" 2.00"
ATTRS{urbnum}=="37"
ATTRS{ltm_capable}=="no"
ATTRS{removable}=="unknown"
ATTRS{idProduct}=="2514"
ATTRS{bDeviceClass}=="09"


root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB1 | head -18

  looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.3/ttyUSB1/tty/ttyUSB1':
KERNEL=="ttyUSB1"
SUBSYSTEM=="tty"
DRIVER==""

  looking at parent device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.3/ttyUSB1':
KERNELS=="ttyUSB1"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"

root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB2 | head -18

  looking at device
'/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3/1-1.3:1.4/ttyUSB2/tty/ttyUSB2':
KERNEL=="ttyUSB2"
SUBSYSTEM=="tty"
DRIVER==""

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-18 Thread José 
Is there a way to know when is late enough to issue the connect
request? Im trying to get an embedded system connected to cellular
network on boot, so the commands are getting issued as soon as
ModemManager detects the modem.

Also, you said this could be due to the SIM reading errors that appear
early in the log. I am only having problems with the Telit LE910-EUG
modem, which does not read my Movistar nor the Yoigo SIM, and reads
the Vodafone SIM with those errors. Do you know if there could be any
differences between these SIMs that could explain that? Also, do you
know if there is any limitations to which SIMs can a modem read?
(because I am using those SIM cards with other modems with no problem)

Thanks for the answers.

On Mon, Jan 18, 2016 at 4:32 PM, Aleksander Morgado
 wrote:
> On Mon, Jan 18, 2016 at 4:13 PM, José  wrote:
>> This issue happens intermitently the first time I try the mmcli -m 0
>> --simple-connect command.
>>
>> When it fails, issuing 'mmcli -m 0 --simple-connect' again properly connects.
>>
>> Is there a way to fix this?
>
> If the issue is that the modem gets unregistered during the connection
> setup, which is what was seen in the last debug log, then I guess
> there's little we can do but to fail the connection attempt :/ Maybe
> you're issuing the Connect request too early while the modem is still
> getting registered properly in the network?
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-18 Thread Aleksander Morgado 
On Mon, Jan 18, 2016 at 4:39 PM, José  wrote:
> Is there a way to know when is late enough to issue the connect
> request? Im trying to get an embedded system connected to cellular
> network on boot, so the commands are getting issued as soon as
> ModemManager detects the modem.
>

In theory the Simple.Connect() command can be issued as soon as you
want; that command will enable, request auto register, wait for the
registration, and once registered get the modem connected. But, maybe
the modem is reporting being registered even if it internally needs
some more time? Just guessing here really. Maybe you can watch the
registration details and once it gets operator ID and name, launch the
connection? Your debug logs showed that the modem was getting into a
"limited" registration state, that could be problematic itself for the
connection.


> Also, you said this could be due to the SIM reading errors that appear
> early in the log. I am only having problems with the Telit LE910-EUG
> modem, which does not read my Movistar nor the Yoigo SIM, and reads
> the Vodafone SIM with those errors. Do you know if there could be any
> differences between these SIMs that could explain that? Also, do you
> know if there is any limitations to which SIMs can a modem read?
> (because I am using those SIM cards with other modems with no problem)
>

Oh, that I don't know. Are they all USIMs? Is there any error reported
by the modem when the Movistar or Yoigo SIMs are used?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2016-01-18 Thread Dan Williams 
On Mon, 2016-01-18 at 16:55 +0100, José  wrote:
> I was not sure what caused the 'limited' registration state... I am
> going to check if there is any firmware updates available and try
> that.
> 
> They all are nanoSIM. Not sure if there is any errors when using
> Movistar and Yoigo SIMs, I will try it out and check the logs as soon
> as I can.

Yes, some SIMs cannot be read by some modems.

For example, there is a bug in older Icera-based modems (Nokia 21M-02,
Samsung Y3300 and Y3400, T-Mobile Rocket 2, Option GIO-322) that
refuses to read T-Mobile USA SIMs that have Isis/Softcard mobile wallet
capabilities.  Other, non-Isis-branded T-Mobile USA SIMs do not have
this problem.  These Icera devices will never receive a firmware update
to fix the problem, so they will remain incompatible forever.

For the Telit device, your only recourse would be to ask Telit if it is
a known bug, and request an updated firmware to fix the issue.  Or use
a different SIM :(

Dan
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager using QMI doesnt always work in the first attemp.

2015-11-18 Thread Aleksander Morgado 
On Wed, Nov 18, 2015 at 9:14 AM, José  wrote:
> Seems like the log I gave was not complete. Here is a better one:
>
> http://pastebin.com/Y24a9Y8W
>
> At line 1849 seems like ModemManager decides to abort the connection, I am
> not sure why.

During the connection attempt the modem gets unregistered from the
network and ends up in "limited service" state; ModemManager detects
that and cancels the connection request with an Abort QMI message. Are
you in a place with low coverage? You're only getting GSM/EDGE
registrations, no 3G or 4G.

>> QMI:
>>   flags   = "indication"
>>   transaction = 0
>>   tlv_length  = 21
>>   message = "Serving System" (0x0024)
>> TLV:
>>   type   = "Detailed Service Status" (0x22)
>>   length = 5
>>   value  = 01:01:04:01:00
>>   translated = [ status = 'limited' capability = 'cs' hdr_status = 
>> 'power-save' hdr_hybrid = 'yes' forbidden = 'no' ]
>> TLV:
>>   type   = "Data Service Capability" (0x11)
>>   length = 1
>>   value  = 00
>>   translated = {}
>> TLV:
>>   type   = "Serving System" (0x01)
>>   length = 6
>>   value  = 02:02:02:02:01:04
>>   translated = [ registration_state = 'not-registered-searching' 
>> cs_attach_state = 'detached' ps_attach_state = 'detached' 
>> selected_network = '3gpp' radio_interfaces = '{ [0] = 'gsm '}' ]
 Processing 3GPP info...
  Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP
Registration state changed (home -> idle)
 Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location
updated (MCC: '0', MNC: '0', Location area code: '1072', Cell ID:
'39CC')
 Bearer not allowed to connect, not registered in 3GPP network
 Forcing disconnection of bearer
'/org/freedesktop/ModemManager1/Bearer/0'
 Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP location
updated (MCC: '0', MNC: '0', Location area code: '0', Cell ID: '0')
[/dev/cdc-wdm0] Sent message...
<< RAW:
<<   length = 18
<<   data   = 01:11:00:00:01:0A:00:02:00:02:00:05:00:01:02:00:01:00
[/dev/cdc-wdm0] Sent message (translated)...
<< QMUX:
<<   length  = 17
<<   flags   = 0x00
<<   service = "wds"
<<   client  = 10
<< QMI:
<<   flags   = "none"
<<   transaction = 2
<<   tlv_length  = 5
<<   message = "Abort" (0x0002)


-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel