Best approach (using python app) to link system os (ubuntu) to the bearer connected to the network (Quectel 5G modem)

2022-07-20 Thread Francisco José Arroyo Valle 
Hi, 

I have been doing a little python app based on GObject Introspection using
libmm-glib for configured and connected a Quectel (5G) modem to the Vodafone
Spain network …

---

mmcli -m 0

  ---

  General  |path: /org/freedesktop/ModemManager1/Modem/0

   |   device id:
a72005907e3dffab644853164b7098cb203e4d84

  ---

  Hardware |manufacturer: Quectel

   |   model: RM510QGLHA_VB

   |   firmware revision: RM510QGLHAR11A03M4G

   |  carrier config: Germany-VoLTE-Vodafone

   | carrier config revision: 0A010449

   |h/w revision: 2

   |   supported: gsm-umts, lte, 5gnr

   | current: gsm-umts, lte, 5gnr

   |equipment id: 867034040029614

  ---

  System   |  device:
/sys/devices/pci:00/:00:14.0/usb2/2-1/2-1.1

   | drivers: option, qmi_wwan

   |  plugin: quectel

   |primary port: cdc-wdm0

   |   ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm),
ttyUSB1 (gps),

   |  ttyUSB2 (at), ttyUSB3 (at), wwan0
(net)

  ---

  Status   |lock: sim-pin2

   |  unlock retries: sim-pin (3), sim-puk (10), sim-pin2
(3), sim-puk2 (10)

   |   state: connected

   | power state: on

   | access tech: lte

   |  signal quality: 100% (cached)

  ---

  Modes|   supported: allowed: 3g; preferred: none

…

   | current: allowed: 3g, 4g, 5g; preferred: 5g

  ---

  Bands|   supported: utran-1, utran-3, utran-4, utran-6,
utran-5, utran-8,

   |  utran-9, utran-2, eutran-1, eutran-2,
eutran-3, eutran-4, eutran-5,

   |  eutran-7, eutran-8, eutran-12,
eutran-13, eutran-14, eutran-17,

   |  eutran-18, eutran-19, eutran-20,
eutran-25, eutran-26, eutran-28,

   |  eutran-29, eutran-30, eutran-32,
eutran-34, eutran-38, eutran-39,

   |  eutran-40, eutran-41, eutran-42,
eutran-43, eutran-46, eutran-48,

   |  eutran-66, eutran-71, utran-19

   | current: utran-1, utran-3, utran-4, utran-6,
utran-5, utran-8,

   |  utran-2, eutran-1, eutran-2, eutran-3,
eutran-4, eutran-5, eutran-7,

   |  eutran-8, eutran-12, eutran-13,
eutran-14, eutran-17, eutran-18,

   |  eutran-19, eutran-20, eutran-25,
eutran-26, eutran-28, eutran-29,

   |  eutran-30, eutran-32, eutran-34,
eutran-38, eutran-39, eutran-40,

   |  eutran-41, eutran-42, eutran-43,
eutran-46, eutran-48, eutran-66,

   |  eutran-71, utran-19

  ---

  IP   |   supported: ipv4, ipv6, ipv4v6

  ---

  3GPP |imei: 867034040029614

   |   enabled locks: fixed-dialing

   | operator id: 21401

   |   operator name: vodafone ES

   |registration: home

  ---

  3GPP EPS |ue mode of operation: csps-2

   | initial bearer path:
/org/freedesktop/ModemManager1/Bearer/0

   |  initial bearer ip type: ipv4v6

  ---

  SIM  |primary sim path: /org/freedesktop/ModemManager1/SIM/0

   |  sim slot paths: slot 1:
/org/freedesktop/ModemManager1/SIM/0 (active)

   |  slot 2: none

  ---

  Bearer   |   paths:
/org/freedesktop/ModemManager1/Bearer/2

mmcli -m 0 --bearer 2

  

  General|   path:
/org/freedesktop/ModemManager1/Bearer/2

 |   type: default

  

  Status |  connected: yes

 |  suspended: no

 |multiplexed: no

 |  interface: wwan0

 | ip timeout: 20

  

  Properties |apn: airtelwap.es

 |roaming: allowed

 |ip type: ipv4v6

  

  IPv4

Re: GPS support using Quectel EC21

2018-07-19 Thread José 
On Thu, Jul 19, 2018 at 11:42 AM, Aleksander Morgado
 wrote:
> Hey José
>
>
> libqmi/qmicli git master now has QMI LOC support, and there is a
> ModemManager branch with QMI LOC support as well, in case you want to
> test it, see:
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/10
>

Thank you for notifying!

Loads of things going on, but I will try to get some time to check this.

Thanks again!

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

Re: GPS support using Quectel EC21

2017-09-11 Thread José 
> Maybe this modem supports the LOC service instead of PDS?  I started
> stubbing that out in libqmi a while back but haven't done the actual
> "where am I" calls.
>
> Dan

It does!

ModemManager[800]: [/dev/cdc-wdm0] loc (2.0)

Is there something in qmicli that I can use to get NMEA sentences or
the location?

Thanks!
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

2017-08-08 Thread José 
On Tue, Aug 8, 2017 at 4:40 PM, Aleksander Morgado
 wrote:
> Not really, no. LTE is 3GPP, so the LE866-SV is 3GPP, regardless of
> operator, we cannot change that or it wouldn't work in MM. What we
> need is a way to "switch to 3GPP2 SMS messaging" in 3GPP-only modems,
> either automagically (maybe flagging this specific modem to do so via
> a udev tag) or via a user-requested option when creating the SMS.
>

Umh, a udev tag will also work for us.

>> It is my understanding that this modem can only be used with Verizon SIM 
>> cards.
>
> Is the modem locked to Verizon in any way?
>

I am not sure, my mate in US was telling me that. I also found that
they list 'Verizon' as the only provider in some documents, like
second page of this PDF:

http://www.telit.com/fileadmin/user_upload/media/products/cellular/4_G/LE866/Telit_LE866_Datasheet_AG.pdf
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

2017-08-04 Thread José 
On Fri, Aug 4, 2017 at 4:14 PM, Daniele Palmas  wrote:
>
> as far as I remember 3GPP pdu should be supported, but maybe this
> could depend on firmware customizations.
>
Just in case, this is the information for the Modem I am using:

  -
  Hardware |   manufacturer: 'Telit'
   |  model: 'LE866-SV1'
   |   revision: '23.00.002 (M0A.00020)'
   |  supported: 'lte'
   |current: 'lte'
   |   equipment id: '352613070097419'
  -
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

2017-08-04 Thread José 
On Fri, Aug 4, 2017 at 3:24 PM, Aleksander Morgado
 wrote:
> Hum I totally believe I did send SMS in PDU mode with the Telit
> LE866 a while back... What is the error you're getting, and which is
> the actual PDU you're trying to send?
>

Sorry, I forgot to include that. Here are the commands I tried and the output:

root@ccimx6ulsbc:~# mmcli -m 0 --messaging-create-sms="text='Hello
world',number='+197'"
Successfully created new SMS:
/org/freedesktop/ModemManager1/SMS/3 (unknown)

 [1501854124.113201] [../../git/src/mm-iface-modem.c:1206]
update_signal_quality(): Modem /org/freedesktop/ModemManager1/Modem/0:
signal quality updated (6)

root@ccimx6ulsbc:~# mmcli -s 3 --send
error: couldn't send the SMS:
'GDBus.Error:org.freedesktop.ModemManager1.Error.Message.Unknown:
Unknown error'

 [1501854251.236624] [../../git/src/mm-base-sms.c:178]
generate_3gpp_submit_pdus():   Processing chunk '0' of text with '11'
bytes
 [1501854251.238542] [../../git/src/mm-base-sms.c:208]
generate_3gpp_submit_pdus(): Created SMS part for singlepart SMS
 [1501854251.241746] [../../git/src/mm-sms-part-3gpp.c:805]
mm_sms_part_3gpp_get_submit_pdu(): Creating PDU for part...
 [1501854251.243373] [../../git/src/mm-sms-part-3gpp.c:892]
mm_sms_part_3gpp_get_submit_pdu():   using GSM7 encoding...
 [1501854251.244973] [../../git/src/mm-sms-part-3gpp.c:957]
mm_sms_part_3gpp_get_submit_pdu():   user data length is '11' septets
(without UDH)
 [1501854251.246756] [../../git/src/mm-port-serial.c:1250]
mm_port_serial_open(): (ttymxc1) device open count is 2 (open)
 [1501854251.248551] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): --> 'AT+CMGS=23'
 [1501854251.262761] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): <-- 'AT'
 [1501854251.274812] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): <-- '+CMGS=23'
 [1501854251.284741] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): <-- '> '
 [1501854251.286704] [../../git/src/mm-port-serial.c:1250]
mm_port_serial_open(): (ttymxc1) device open count is 3 (open)
 [1501854251.288503] [../../git/src/mm-port-serial.c:1307]
_close_internal(): (ttymxc1) device open count is 2 (close)
 [1501854251.290317] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): -->
'0001000B91910700F00BC8329BFD06DDDF723619\26'
 [1501854251.345394] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): <-- '0'
 [1501854251.370661] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc1): <-- '+CMS ERROR: 41'
 [1501854251.373089] [../../git/src/mm-error-helpers.c:218]
mm_message_error_for_code(): Invalid message error code: 41
 [1501854251.374966] [../../git/src/mm-serial-parsers.c:364]
mm_serial_parser_v1_parse(): Got failure code 500: Unknown error
 [1501854251.376918] [../../git/src/mm-port-serial.c:1307]
_close_internal(): (ttymxc1) device open count is 1 (close)


Same setup if I use microcom to send the SMS using text mode, it works fine.

>> I have been told that "Telit's PDU mode doesn't use the standard GSM
>> PDUs" but I am checking the AT Reference sheet and this is not clear
>> to me. Does anyone know about this? Would it be possible to make the
>> Telit plugin from ModemManager to use Text mode for the LE866-SV1?
>>
>
> Carlo, Daniele, do you have any comment on that statement regarding
> Telit's PDU mode?
>

Some extra information:

One thing that’s not described in the PDF is that encoding value 0x09
indicates GSM 7-bit (i.e. what you’d normally put into a PDU), and
that while “7-bit ASCII” and “GSM 7-bit” septets are packed into
octets differently. I don’t remember off the top of my head which
encoding leads to which packing order, but it’s easy enough to figure
out if you send the module an SMS and just look at the bits.


I also got this example: http://i.imgur.com/WJYRFiv.png
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

2017-08-04 Thread José 
I am trying the same thing with the Telit LE866. With that modem I am
able to send SMSs in Text mode using AT commands, but no in PDU mode.

I have been told that "Telit's PDU mode doesn't use the standard GSM
PDUs" but I am checking the AT Reference sheet and this is not clear
to me. Does anyone know about this? Would it be possible to make the
Telit plugin from ModemManager to use Text mode for the LE866-SV1?

On Thu, Aug 3, 2017 at 6:53 PM, José <josedd...@gmail.com> wrote:
> I was not register in the network : (
>
> Working now, thanks!
>
> I think I have a different problem with the XBee US version, but I
> will let you know if I cannot solve that.
>
> On Thu, Aug 3, 2017 at 1:13 PM, Aleksander Morgado
> <aleksan...@aleksander.es> wrote:
>> On 03/08/17 11:04, José  wrote:
>>> I am using the 3G XBee Cellular (uses U-Blox SARA-U200 modem) and
>>> ModemManager from master (d41d717112e6a183a0df510c210e80a86fc11060).
>>>
>>> I am trying to send an SMS with the following commands:
>>>
>>> $ mmcli -m 0 --messaging-create-sms="text='Hello world',number='+627XX"
>>> Successfully created new SMS:
>>> /org/freedesktop/ModemManager1/SMS/10 (unknown)
>>>
>>> $ mmcli -s 10 --send
>>> error: couldn't send the SMS:
>>> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Message.Unknown:
>>> Unknown error'
>>>
>>>
>>> The log shows:
>>>
>>>  [1501676070.461276]
>>> [../../git/src/mm-iface-modem-messaging.c:511] sms_added(): Added
>>> local SMS at '/org/freedesktop/ModemManager1/SMS/8'
>>>  [1501676078.360084] [../../git/src/mm-base-sms.c:178]
>>> generate_3gpp_submit_pdus():   Processing chunk '0' of text with '11'
>>> bytes
>>>  [1501676078.371070] [../../git/src/mm-base-sms.c:208]
>>> generate_3gpp_submit_pdus(): Created SMS part for singlepart SMS
>>>  [1501676078.374057] [../../git/src/mm-sms-part-3gpp.c:805]
>>> mm_sms_part_3gpp_get_submit_pdu(): Creating PDU for part...
>>>  [1501676078.377048] [../../git/src/mm-sms-part-3gpp.c:892]
>>> mm_sms_part_3gpp_get_submit_pdu():   using GSM7 encoding...
>>>  [1501676078.379982] [../../git/src/mm-sms-part-3gpp.c:957]
>>> mm_sms_part_3gpp_get_submit_pdu():   user data length is '11' septets
>>> (without UDH)
>>>  [1501676078.382961] [../../git/src/mm-port-serial.c:1250]
>>> mm_port_serial_open(): (ttymxc4) device open count is 2 (open)
>>>  [1501676078.386006] [../../git/src/mm-port-serial-at.c:459]
>>> debug_log(): (ttymxc4): --> 'AT+CMGS=22'
>>>  [1501676078.431257] [../../git/src/mm-port-serial-at.c:459]
>>> debug_log(): (ttymxc4): <-- '> '
>>>  [1501676078.435569] [../../git/src/mm-port-serial.c:1250]
>>> mm_port_serial_open(): (ttymxc4) device open count is 3 (open)
>>>  [1501676078.438554] [../../git/src/mm-port-serial.c:1307]
>>> _close_internal(): (ttymxc4) device open count is 2 (close)
>>>  [1501676078.441551] [../../git/src/mm-port-serial-at.c:459]
>>> debug_log(): (ttymxc4): -->
>>> '00010009912637F10BC8329BFD06DDDF723619\26'
>>>  [1501676078.573891] [../../git/src/mm-port-serial-at.c:459]
>>> debug_log(): (ttymxc4): <-- '+CMS ERROR: 38'
>>>  [1501676078.597195] [../../git/src/mm-error-helpers.c:218]
>>> mm_message_error_for_code(): Invalid message error code: 38
>>>  [1501676078.600884] [../../git/src/mm-serial-parsers.c:364]
>>> mm_serial_parser_v1_parse(): Got failure code 500: Unknown error
>>>  [1501676078.604622] [../../git/src/mm-port-serial.c:1307]
>>> _close_internal(): (ttymxc4) device open count is 1 (close)
>>>
>>> However if I use a serial console and the following AT commands, the
>>> SMS is properly sent:
>>>
>>> ATZ
>>> OK
>>> AT+CMGF=1
>>> OK
>>> AT+CMGS="+627XX"
>>>> Hello world
>>> +CMGS: 193
>>>
>>> OK
>>>
>>>
>>> a) Could you give any information about why is PDU mode failing?
>>> According to U-Blox documentation (1) it should be working
>>>
>>
>> I'm assuming that if you send the PDU manually using a serial console it 
>> also doesn't work, did you try that?
>> +CMS error 38 is "Network out of order", but I'm not sure why text mode 
>> would work without error while PDU mode gives error 38.
>>
>>> b) Is there a way to tell ModemManager to use text mode when sending SMSs?
>>
>> No; text mode is only used by default when PDU mode isn't supported. PDU 
>> mode is always preferred really.
>>
>> Also, which are your SMSC settings? E.g.:
>>   AT+CSCA?
>>
>> --
>> Aleksander
>> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Sending SMS in PDU mode fails.

2017-08-03 Thread José 
I was not register in the network : (

Working now, thanks!

I think I have a different problem with the XBee US version, but I
will let you know if I cannot solve that.

On Thu, Aug 3, 2017 at 1:13 PM, Aleksander Morgado
<aleksan...@aleksander.es> wrote:
> On 03/08/17 11:04, José  wrote:
>> I am using the 3G XBee Cellular (uses U-Blox SARA-U200 modem) and
>> ModemManager from master (d41d717112e6a183a0df510c210e80a86fc11060).
>>
>> I am trying to send an SMS with the following commands:
>>
>> $ mmcli -m 0 --messaging-create-sms="text='Hello world',number='+627XX"
>> Successfully created new SMS:
>> /org/freedesktop/ModemManager1/SMS/10 (unknown)
>>
>> $ mmcli -s 10 --send
>> error: couldn't send the SMS:
>> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Message.Unknown:
>> Unknown error'
>>
>>
>> The log shows:
>>
>>  [1501676070.461276]
>> [../../git/src/mm-iface-modem-messaging.c:511] sms_added(): Added
>> local SMS at '/org/freedesktop/ModemManager1/SMS/8'
>>  [1501676078.360084] [../../git/src/mm-base-sms.c:178]
>> generate_3gpp_submit_pdus():   Processing chunk '0' of text with '11'
>> bytes
>>  [1501676078.371070] [../../git/src/mm-base-sms.c:208]
>> generate_3gpp_submit_pdus(): Created SMS part for singlepart SMS
>>  [1501676078.374057] [../../git/src/mm-sms-part-3gpp.c:805]
>> mm_sms_part_3gpp_get_submit_pdu(): Creating PDU for part...
>>  [1501676078.377048] [../../git/src/mm-sms-part-3gpp.c:892]
>> mm_sms_part_3gpp_get_submit_pdu():   using GSM7 encoding...
>>  [1501676078.379982] [../../git/src/mm-sms-part-3gpp.c:957]
>> mm_sms_part_3gpp_get_submit_pdu():   user data length is '11' septets
>> (without UDH)
>>  [1501676078.382961] [../../git/src/mm-port-serial.c:1250]
>> mm_port_serial_open(): (ttymxc4) device open count is 2 (open)
>>  [1501676078.386006] [../../git/src/mm-port-serial-at.c:459]
>> debug_log(): (ttymxc4): --> 'AT+CMGS=22'
>>  [1501676078.431257] [../../git/src/mm-port-serial-at.c:459]
>> debug_log(): (ttymxc4): <-- '> '
>>  [1501676078.435569] [../../git/src/mm-port-serial.c:1250]
>> mm_port_serial_open(): (ttymxc4) device open count is 3 (open)
>>  [1501676078.438554] [../../git/src/mm-port-serial.c:1307]
>> _close_internal(): (ttymxc4) device open count is 2 (close)
>>  [1501676078.441551] [../../git/src/mm-port-serial-at.c:459]
>> debug_log(): (ttymxc4): -->
>> '00010009912637F10BC8329BFD06DDDF723619\26'
>>  [1501676078.573891] [../../git/src/mm-port-serial-at.c:459]
>> debug_log(): (ttymxc4): <-- '+CMS ERROR: 38'
>>  [1501676078.597195] [../../git/src/mm-error-helpers.c:218]
>> mm_message_error_for_code(): Invalid message error code: 38
>>  [1501676078.600884] [../../git/src/mm-serial-parsers.c:364]
>> mm_serial_parser_v1_parse(): Got failure code 500: Unknown error
>>  [1501676078.604622] [../../git/src/mm-port-serial.c:1307]
>> _close_internal(): (ttymxc4) device open count is 1 (close)
>>
>> However if I use a serial console and the following AT commands, the
>> SMS is properly sent:
>>
>> ATZ
>> OK
>> AT+CMGF=1
>> OK
>> AT+CMGS="+627XX"
>>> Hello world
>> +CMGS: 193
>>
>> OK
>>
>>
>> a) Could you give any information about why is PDU mode failing?
>> According to U-Blox documentation (1) it should be working
>>
>
> I'm assuming that if you send the PDU manually using a serial console it also 
> doesn't work, did you try that?
> +CMS error 38 is "Network out of order", but I'm not sure why text mode would 
> work without error while PDU mode gives error 38.
>
>> b) Is there a way to tell ModemManager to use text mode when sending SMSs?
>
> No; text mode is only used by default when PDU mode isn't supported. PDU mode 
> is always preferred really.
>
> Also, which are your SMSC settings? E.g.:
>   AT+CSCA?
>
> --
> Aleksander
> https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Sending SMS in PDU mode fails.

2017-08-03 Thread José 
I am using the 3G XBee Cellular (uses U-Blox SARA-U200 modem) and
ModemManager from master (d41d717112e6a183a0df510c210e80a86fc11060).

I am trying to send an SMS with the following commands:

$ mmcli -m 0 --messaging-create-sms="text='Hello world',number='+627XX"
Successfully created new SMS:
/org/freedesktop/ModemManager1/SMS/10 (unknown)

$ mmcli -s 10 --send
error: couldn't send the SMS:
'GDBus.Error:org.freedesktop.ModemManager1.Error.Message.Unknown:
Unknown error'


The log shows:

 [1501676070.461276]
[../../git/src/mm-iface-modem-messaging.c:511] sms_added(): Added
local SMS at '/org/freedesktop/ModemManager1/SMS/8'
 [1501676078.360084] [../../git/src/mm-base-sms.c:178]
generate_3gpp_submit_pdus():   Processing chunk '0' of text with '11'
bytes
 [1501676078.371070] [../../git/src/mm-base-sms.c:208]
generate_3gpp_submit_pdus(): Created SMS part for singlepart SMS
 [1501676078.374057] [../../git/src/mm-sms-part-3gpp.c:805]
mm_sms_part_3gpp_get_submit_pdu(): Creating PDU for part...
 [1501676078.377048] [../../git/src/mm-sms-part-3gpp.c:892]
mm_sms_part_3gpp_get_submit_pdu():   using GSM7 encoding...
 [1501676078.379982] [../../git/src/mm-sms-part-3gpp.c:957]
mm_sms_part_3gpp_get_submit_pdu():   user data length is '11' septets
(without UDH)
 [1501676078.382961] [../../git/src/mm-port-serial.c:1250]
mm_port_serial_open(): (ttymxc4) device open count is 2 (open)
 [1501676078.386006] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc4): --> 'AT+CMGS=22'
 [1501676078.431257] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc4): <-- '> '
 [1501676078.435569] [../../git/src/mm-port-serial.c:1250]
mm_port_serial_open(): (ttymxc4) device open count is 3 (open)
 [1501676078.438554] [../../git/src/mm-port-serial.c:1307]
_close_internal(): (ttymxc4) device open count is 2 (close)
 [1501676078.441551] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc4): -->
'00010009912637F10BC8329BFD06DDDF723619\26'
 [1501676078.573891] [../../git/src/mm-port-serial-at.c:459]
debug_log(): (ttymxc4): <-- '+CMS ERROR: 38'
 [1501676078.597195] [../../git/src/mm-error-helpers.c:218]
mm_message_error_for_code(): Invalid message error code: 38
 [1501676078.600884] [../../git/src/mm-serial-parsers.c:364]
mm_serial_parser_v1_parse(): Got failure code 500: Unknown error
 [1501676078.604622] [../../git/src/mm-port-serial.c:1307]
_close_internal(): (ttymxc4) device open count is 1 (close)

However if I use a serial console and the following AT commands, the
SMS is properly sent:

ATZ
OK
AT+CMGF=1
OK
AT+CMGS="+627XX"
> Hello world
+CMGS: 193

OK


a) Could you give any information about why is PDU mode failing?
According to U-Blox documentation (1) it should be working

b) Is there a way to tell ModemManager to use text mode when sending SMSs?

Thanks


(1) 
https://www.u-blox.com/sites/default/files/u-blox-ATCommands_Manual_(UBX-13002752).pdf
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Modem index increment

2017-07-26 Thread José 
I have noticed that when unplugging and plugging a modem, ModemManager
increases its index by one. This can be annoying when you are trying
to script something.

Would it make sense to assign the same index to the same modem? Maybe
something like using the  "equipment id" field to detect a plugged
modem is not new and use the previous index, instead of increasing it.

Has this been consider before? Are there any arguments for or against it?
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Signal quality

2017-03-21 Thread José 
ModemManager reports look like this:

Status | lock: 'none'
| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
| state: 'connected'
| power state: 'on'
| access tech: 'hsdpa'
| signal quality: '38' (recent)

I have some questinos about the signal quality quantity:

* Which units does the 'signal quality' use?
* Is it the same for any technology/modem?
* How does it relate to RSSI and dbm?

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

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-12 Thread José 
I don't know why the pastebin was deleted. Here is the log:
http://pastebin.com/9VLq7p6L

I am trying to use udhcpc (busybox v1.32.2 implementation) to
configure the network interface. Without the kernel patches for raw ip
support, udhcpc seems to work fine and configure the network
interface:

root@c:~# udhcpc -iwwan0
udhcpc (v1.23.2) started
Sending discover...
Sending select for 100.109.179.23...
Lease of 100.109.179.23 obtained, lease time 7200
/etc/udhcpc.d/50default: Adding DNS 80.58.61.250
/etc/udhcpc.d/50default: Adding DNS 80.58.61.254

root@c:~# ifconfig
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:32 errors:0 dropped:0 overruns:0 frame:0
  TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:2304 (2.2 KiB)  TX bytes:2304 (2.2 KiB)

wwan0 Link encap:Ethernet  HWaddr FE:BC:A8:93:97:10
  inet addr:100.109.179.23  Bcast:100.109.179.31  Mask:255.255.255.240
  inet6 addr: fe80::fcbc:a8ff:fe93:9710/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:612 (612.0 B)  TX bytes:4226 (4.1 KiB)

After applying the kernel patches, udhcpc stops working. It keeps
sending discovers and does not progress any further. I am guessing
udhcpc can't work with raw ip, or maybe I need to patch it?

On Fri, Sep 9, 2016 at 6:33 PM, Dan Williams <d...@redhat.com> wrote:
> On Fri, 2016-09-09 at 17:34 +0200, José  wrote:
>> Thanks for the patch Dan. The modem seems to connect, it gets an IP
>> address and DNS servers, but there is no connectiviy. I cannot
>> resolve
>> any names, I cannot even ping the gateway (I can ping my own ip
>> address)
>
> What tools are you using to apply the MM-returned IP configuration to
> the modem ethernet device?
>
> It looks like the EC21 only supports raw-ip mode, so you'll need to
> make sure your qmi_wwan drivers are up-to-date for raw-ip support,
> which means using a v4.5 or later kernel, or backporting the necessary
> patches to whatever kernel you're using.  The commits you'd need to
> backport are:
>
> 32f7adf633b9f99ad5089901bc7ebff57704aaa9
> 6c730080e663b1d629f8aa89348291fbcdc46cd9
>
> and maybe 93725149794d3d418cf1eddcae60c7b536c5faa1 too.
>
>> There are also some warnings and errors that may be important. Find
>> here the log: http://pastebin.com/JC9BALPs
>
> Looks like that's been removed?
>
> Dan
>
>> Thanks
>>
>> On Fri, Sep 9, 2016 at 4:31 PM, Dan Williams <d...@redhat.com> wrote:
>> >
>> > On Fri, 2016-09-09 at 10:36 +0200, José  wrote:
>> > >
>> > > Hi Dan,
>> > >
>> > > thanks for the patch! Unfortunately it is not working. Here is
>> > > the
>> > > log: http://pastebin.com/A5H3mnPh
>> > Could you try the following patch against ModemManager?  There are
>> > two
>> > ways to get the UIM/SIM status, one with the "DMS" service that
>> > works
>> > on most devices from 2015 and earlier, and a new way with the "UIM"
>> > service that works on many 2015+ devices.  Perhaps the EC21 is new
>> > enough that it requires the UIM service, but ModemManager doesn't
>> > recognize the error code that it's returning.  This patch will do
>> > that.
>> >
>> > You'll still need the libqmi patch I posted earlier too.
>> >
>> > diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-
>> > qmi.c
>> > index bc13925..f60d0f4 100644
>> > --- a/src/mm-broadband-modem-qmi.c
>> > +++ b/src/mm-broadband-modem-qmi.c
>> > @@ -1740,7 +1740,10 @@ dms_uim_get_pin_status_ready (QmiClientDms
>> > *client,
>> >  /* We get InvalidQmiCommand on newer devices which don't
>> > like the legacy way */
>> >  if (g_error_matches (error,
>> >   QMI_PROTOCOL_ERROR,
>> > - QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAN
>> > D)) {
>> > + QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAN
>> > D) ||
>> > +g_error_matches (error,
>> > + QMI_PROTOCOL_ERROR,
>> > + QMI_PROTOCOL_ERROR_NOT_SUPPORTED)) {
>> >  g_error_free (error);
>> >  qmi_message_dms_uim_get_pin_status_output_unref
>>

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-09 Thread José 
Thanks for the patch Dan. The modem seems to connect, it gets an IP
address and DNS servers, but there is no connectiviy. I cannot resolve
any names, I cannot even ping the gateway (I can ping my own ip
address)

There are also some warnings and errors that may be important. Find
here the log: http://pastebin.com/JC9BALPs

Thanks

On Fri, Sep 9, 2016 at 4:31 PM, Dan Williams <d...@redhat.com> wrote:
> On Fri, 2016-09-09 at 10:36 +0200, José  wrote:
>> Hi Dan,
>>
>> thanks for the patch! Unfortunately it is not working. Here is the
>> log: http://pastebin.com/A5H3mnPh
>
> Could you try the following patch against ModemManager?  There are two
> ways to get the UIM/SIM status, one with the "DMS" service that works
> on most devices from 2015 and earlier, and a new way with the "UIM"
> service that works on many 2015+ devices.  Perhaps the EC21 is new
> enough that it requires the UIM service, but ModemManager doesn't
> recognize the error code that it's returning.  This patch will do that.
>
> You'll still need the libqmi patch I posted earlier too.
>
> diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
> index bc13925..f60d0f4 100644
> --- a/src/mm-broadband-modem-qmi.c
> +++ b/src/mm-broadband-modem-qmi.c
> @@ -1740,7 +1740,10 @@ dms_uim_get_pin_status_ready (QmiClientDms *client,
>  /* We get InvalidQmiCommand on newer devices which don't like the 
> legacy way */
>  if (g_error_matches (error,
>   QMI_PROTOCOL_ERROR,
> - QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND)) {
> + QMI_PROTOCOL_ERROR_INVALID_QMI_COMMAND) ||
> +g_error_matches (error,
> + QMI_PROTOCOL_ERROR,
> + QMI_PROTOCOL_ERROR_NOT_SUPPORTED)) {
>  g_error_free (error);
>  qmi_message_dms_uim_get_pin_status_output_unref (output);
>  /* Flag that the command is unsupported, and try with the new 
> way */
>
> Dan
>
>> Still trying to contact with Quectel tech support.
>>
>> On Thu, Sep 8, 2016 at 9:55 PM, Dan Williams <d...@redhat.com> wrote:
>> >
>> > On Thu, 2016-09-08 at 19:05 +0200, José  wrote:
>> > >
>> > > Ok, thanks. I am also trying to contact QUECTEL technical
>> > > support, so
>> > > I will let them now about this.
>> > >
>> > > Find the log here: http://pastebin.com/bGr6bAt0
>> > Thanks; the errors are due to SIM lock state.  Try backing out your
>> > changes to libqmi and then apply the attached patch.  Does that
>> > make
>> > things work?
>> >
>> > Dan
>> >
>> > >
>> > > On Thu, Sep 8, 2016 at 6:31 PM, Dan Williams <d...@redhat.com>
>> > > wrote:
>> > > >
>> > > >
>> > > > On Thu, 2016-09-08 at 17:56 +0200, José  wrote:
>> > > > >
>> > > > >
>> > > > > Sure:
>> > > > >
>> > > > > root:~# qmicli -d /dev/cdc-wdm0 --get-service-version-info
>> > > > > [/dev/cdc-wdm0] Supported versions:
>> > > > > ctl (1.5)
>> > > > > wds (1.67)
>> > > > > dms (1.0)
>> > > > > nas (1.25)
>> > > > > qos (1.12)
>> > > > Thanks, I'll post a patch to work around the DMS stupidity.
>> > > >
>> > > > >
>> > > > >
>> > > > > Also, if I patch libqmi to get rid of both ModemManager
>> > > > > errors,
>> > > > > the
>> > > > > modem still does not work.
>> > > > Can you post ModemManager --debug logs when you've patched
>> > > > libqmi
>> > > > to
>> > > > get past this issue?
>> > > >
>> > > > Dan
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > > On Thu, Sep 8, 2016 at 4:47 PM, Dan Williams <d...@redhat.com
>> > > > > >
>> > > > > wrote:
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Thu, 2016-09-08 at 10:31 +0200, José  wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > This is the output of those commands:
>> &

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-08 Thread José 
Ok, thanks. I am also trying to contact QUECTEL technical support, so
I will let them now about this.

Find the log here: http://pastebin.com/bGr6bAt0

On Thu, Sep 8, 2016 at 6:31 PM, Dan Williams <d...@redhat.com> wrote:
> On Thu, 2016-09-08 at 17:56 +0200, José  wrote:
>> Sure:
>>
>> root:~# qmicli -d /dev/cdc-wdm0 --get-service-version-info
>> [/dev/cdc-wdm0] Supported versions:
>> ctl (1.5)
>> wds (1.67)
>> dms (1.0)
>> nas (1.25)
>> qos (1.12)
>
> Thanks, I'll post a patch to work around the DMS stupidity.
>
>> Also, if I patch libqmi to get rid of both ModemManager errors, the
>> modem still does not work.
>
> Can you post ModemManager --debug logs when you've patched libqmi to
> get past this issue?
>
> Dan
>
>
>> On Thu, Sep 8, 2016 at 4:47 PM, Dan Williams <d...@redhat.com> wrote:
>> >
>> > On Thu, 2016-09-08 at 10:31 +0200, José  wrote:
>> > >
>> > > This is the output of those commands:
>> > >
>> > > qmicli -d /dev/cdc-wdm0 --dms-read-user-data
>> > > [/dev/cdc-wdm0] User data read:
>> > > Size: '0' bytes
>> > > Contents:
>> > >
>> > > qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
>> > > error: couldn't get UIM state: QMI protocol error (94):
>> > > 'NotSupported'
>> > So the device lies about the DMS service version.  If it didn't
>> > actually support them, it would return "InvalidQmiCommand" to both
>> > of
>> > those requests.
>> >
>> > Could you grab:
>> >
>> > qmicli -d /dev/cdc-wdm0 --get-service-version-info
>> >
>> > for me?
>> >
>> > Thanks,
>> > Dan
>> >
>> > >
>> > > On Wed, Sep 7, 2016 at 6:32 PM, Dan Williams <d...@redhat.com>
>> > > wrote:
>> > > >
>> > > >
>> > > > On Wed, 2016-09-07 at 17:05 +0200, José  wrote:
>> > > > >
>> > > > >
>> > > > > Hi Dan,
>> > > > >
>> > > > > thanks for your answer.
>> > > > >
>> > > > > I compiled libqmi-1.12.6-r0.1.cortexa9hf_vfp_neon.rpm (notice
>> > > > > that it
>> > > > > is an older version, it was just simpler on my environment)
>> > > > > with
>> > > > > the
>> > > > > change you proposed. After that, the command seems to work:
>> > > > >
>> > > > > # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
>> > > > > [/dev/cdc-wdm0] Operating mode retrieved:
>> > > > > Mode: 'online'
>> > > > > HW restricted: 'no'
>> > > > >
>> > > > > So is the problem in the modem firmware reporting an older
>> > > > > DMS
>> > > > > that
>> > > > > what it is really using, or is it in libqmi?
>> > > > It depends.  There are two options:
>> > > >
>> > > > 1) The device lies about its supported DMS version and it
>> > > > actually
>> > > > supports a newer DMS version, but mis-reports it.  Firmware
>> > > > bug,
>> > > > but
>> > > > something we probably have to work around.
>> > > >
>> > > > 2) The command is actually supported in DMS 1.0 but the
>> > > > information
>> > > > we
>> > > > had indicated it's only supported in 1.1.  libqmi bug, and we
>> > > > can
>> > > > fix
>> > > > this.
>> > > >
>> > > > To figure this out, let's modify an existing message that
>> > > > clearly
>> > > > isn't
>> > > > supported in very early DMS versions.  So change the version in
>> > > > data/qmi-service-dms.json for the "Read User Data" and "UIM Get
>> > > > State"
>> > > > messages to "1.0" and rebuild/reinstall.
>> > > >
>> > > > Then, what is the result of:
>> > > >
>> > > > qmicli -d /dev/cdc-wdm0 --dms-read-user-data
>> > > > qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
>> > > >
>> > > > Dan
>> > > >
>> > > > >
>> > > > >
>> > > > > However, ModemManager still does not wor

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-08 Thread José 
Sure:

root:~# qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'
root:~#
root:~# qmicli -d /dev/cdc-wdm0 --dms-read-user-data
[/dev/cdc-wdm0] User data read:
Size: '0' bytes
Contents:
rootc:~# qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
error: couldn't get UIM state: QMI protocol error (94): 'NotSupported'
root:~# qmicli -d /dev/cdc-wdm0 --get-service-version-info
[/dev/cdc-wdm0] Supported versions:
ctl (1.5)
wds (1.67)
dms (1.0)
nas (1.25)
qos (1.12)
wms (1.10)
auth (1.3)
at (1.2)
voice (2.1)
cat2 (2.24)
uim (1.46)
pbm (1.4)
test (1.0)
loc (2.0)
sar (1.0)
ts (1.0)
tmd (1.0)
wda (1.16)
csvt (1.1)
coex (1.0)
pdc (1.0)
rfrpe (1.0)
dsd (1.0)
unknown [0x30] (1.0)
unknown [0x36] (1.0)

By the way, I didn't need to patch libqmi to get those output...

Also, if I patch libqmi to get rid of both ModemManager errors, the
modem still does not work.

On Thu, Sep 8, 2016 at 4:47 PM, Dan Williams <d...@redhat.com> wrote:
> On Thu, 2016-09-08 at 10:31 +0200, José  wrote:
>> This is the output of those commands:
>>
>> qmicli -d /dev/cdc-wdm0 --dms-read-user-data
>> [/dev/cdc-wdm0] User data read:
>> Size: '0' bytes
>> Contents:
>>
>> qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
>> error: couldn't get UIM state: QMI protocol error (94):
>> 'NotSupported'
>
> So the device lies about the DMS service version.  If it didn't
> actually support them, it would return "InvalidQmiCommand" to both of
> those requests.
>
> Could you grab:
>
> qmicli -d /dev/cdc-wdm0 --get-service-version-info
>
> for me?
>
> Thanks,
> Dan
>
>> On Wed, Sep 7, 2016 at 6:32 PM, Dan Williams <d...@redhat.com> wrote:
>> >
>> > On Wed, 2016-09-07 at 17:05 +0200, José  wrote:
>> > >
>> > > Hi Dan,
>> > >
>> > > thanks for your answer.
>> > >
>> > > I compiled libqmi-1.12.6-r0.1.cortexa9hf_vfp_neon.rpm (notice
>> > > that it
>> > > is an older version, it was just simpler on my environment) with
>> > > the
>> > > change you proposed. After that, the command seems to work:
>> > >
>> > > # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
>> > > [/dev/cdc-wdm0] Operating mode retrieved:
>> > > Mode: 'online'
>> > > HW restricted: 'no'
>> > >
>> > > So is the problem in the modem firmware reporting an older DMS
>> > > that
>> > > what it is really using, or is it in libqmi?
>> > It depends.  There are two options:
>> >
>> > 1) The device lies about its supported DMS version and it actually
>> > supports a newer DMS version, but mis-reports it.  Firmware bug,
>> > but
>> > something we probably have to work around.
>> >
>> > 2) The command is actually supported in DMS 1.0 but the information
>> > we
>> > had indicated it's only supported in 1.1.  libqmi bug, and we can
>> > fix
>> > this.
>> >
>> > To figure this out, let's modify an existing message that clearly
>> > isn't
>> > supported in very early DMS versions.  So change the version in
>> > data/qmi-service-dms.json for the "Read User Data" and "UIM Get
>> > State"
>> > messages to "1.0" and rebuild/reinstall.
>> >
>> > Then, what is the result of:
>> >
>> > qmicli -d /dev/cdc-wdm0 --dms-read-user-data
>> > qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
>> >
>> > Dan
>> >
>> > >
>> > > However, ModemManager still does not work because of the other
>> > > message
>> > > (I recompiled it against the patched libqmi library):
>> > >
>> > > ModemManager[710]:   couldn't load Supported Bands: 'QMI
>> > > operation failed: Cannot send message: QMI service 'dms' version
>> > > '1.3'
>> > > required, got version '1.0''
>> > > ModemManager[710]:   Modem couldn't be initialized:
>> > > Couldn't
>> > > check unlock status: Couldn't get SIM lock status after 6 retries
>> > > ModemManager[710]:   Modem: state changed (unknown ->
>> > > failed)
>> > >
>> > > Will this allow a similar fix?
>> > >
>> > > On Wed, Sep 7, 2016 at 4:

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-08 Thread José 
This is the output of those commands:

qmicli -d /dev/cdc-wdm0 --dms-read-user-data
[/dev/cdc-wdm0] User data read:
Size: '0' bytes
Contents:

qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
error: couldn't get UIM state: QMI protocol error (94): 'NotSupported'

On Wed, Sep 7, 2016 at 6:32 PM, Dan Williams <d...@redhat.com> wrote:
> On Wed, 2016-09-07 at 17:05 +0200, José  wrote:
>> Hi Dan,
>>
>> thanks for your answer.
>>
>> I compiled libqmi-1.12.6-r0.1.cortexa9hf_vfp_neon.rpm (notice that it
>> is an older version, it was just simpler on my environment) with the
>> change you proposed. After that, the command seems to work:
>>
>> # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
>> [/dev/cdc-wdm0] Operating mode retrieved:
>> Mode: 'online'
>> HW restricted: 'no'
>>
>> So is the problem in the modem firmware reporting an older DMS that
>> what it is really using, or is it in libqmi?
>
> It depends.  There are two options:
>
> 1) The device lies about its supported DMS version and it actually
> supports a newer DMS version, but mis-reports it.  Firmware bug, but
> something we probably have to work around.
>
> 2) The command is actually supported in DMS 1.0 but the information we
> had indicated it's only supported in 1.1.  libqmi bug, and we can fix
> this.
>
> To figure this out, let's modify an existing message that clearly isn't
> supported in very early DMS versions.  So change the version in
> data/qmi-service-dms.json for the "Read User Data" and "UIM Get State"
> messages to "1.0" and rebuild/reinstall.
>
> Then, what is the result of:
>
> qmicli -d /dev/cdc-wdm0 --dms-read-user-data
> qmicli -d /dev/cdc-wdm0 --dms-uim-get-state
>
> Dan
>
>> However, ModemManager still does not work because of the other
>> message
>> (I recompiled it against the patched libqmi library):
>>
>> ModemManager[710]:   couldn't load Supported Bands: 'QMI
>> operation failed: Cannot send message: QMI service 'dms' version
>> '1.3'
>> required, got version '1.0''
>> ModemManager[710]:   Modem couldn't be initialized: Couldn't
>> check unlock status: Couldn't get SIM lock status after 6 retries
>> ModemManager[710]:   Modem: state changed (unknown -> failed)
>>
>> Will this allow a similar fix?
>>
>> On Wed, Sep 7, 2016 at 4:29 PM, Dan Williams <d...@redhat.com> wrote:
>> >
>> > On Wed, 2016-09-07 at 15:33 +0200, José  wrote:
>> > >
>> > > Maybe I was wrong. I am trying now with the last versions but it
>> > > is
>> > > still not working:
>> > >
>> > > ModemManager 1.6.0
>> > > libqmi-1.16.0-r0.4.cortexa9hf_vfp_neon
>> > >
>> > > The problem is still reproducible:
>> > Interesting; even though it's a recent device, it's still
>> > advertising
>> > DMS 1.0.
>> >
>> > It may be that Get Operating Mode was present in DMS 1.0 and we
>> > simply
>> > don't have any examples of that.  So you could try to modify libqmi
>> > and
>> > see if that works.
>> >
>> > Look in data/qmi-service-dms.json and look for "Get Operating
>> > Mode".
>> >  Change the "1.1" there to "1.0", rebuild, and reinstall
>> > libqmi.  Then
>> > see if you can run "qmicli -d /dev/cdc-wdm0 --dms-get-operating-
>> > mode".
>> >  Does that work?
>> >
>> > Dan
>> >
>> > >
>> > > ModemManager[995]:   ModemManager (version 1.6.0) starting
>> > > in
>> > > system bus...
>> > > ModemManager[995]: [/dev/cdc-wdm0] Opening device with flags
>> > > 'version-info, proxy'...
>> > > ModemManager[995]: cannot connect to proxy: Could not connect:
>> > > Connection refused
>> > > ModemManager[995]: spawning new qmi-proxy (try 1)...
>> > > ModemManager[995]: [/dev/cdc-wdm0] Checking version info (10
>> > > retries)...
>> > > ModemManager[995]: [/dev/cdc-wdm0] QMI Device supports 25
>> > > services:
>> > > ModemManager[995]: [/dev/cdc-wdm0]ctl (1.5)
>> > > ModemManager[995]: [/dev/cdc-wdm0]wds (1.67)
>> > > ModemManager[995]: [/dev/cdc-wdm0]dms (1.0)
>> > > ModemManager[995]: [/dev/cdc-wdm0]nas (1.25)
>> > > ModemManager[995]: [/dev/cdc-wdm0]qos (1.12)
>> > > ModemManager[995]: [/dev/cdc-wdm0]wms (1.10)
>> > > ModemManager[995]: [/dev/cdc-wdm0]au

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-07 Thread José 
Hi Dan,

thanks for your answer.

I compiled libqmi-1.12.6-r0.1.cortexa9hf_vfp_neon.rpm (notice that it
is an older version, it was just simpler on my environment) with the
change you proposed. After that, the command seems to work:

# qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
Mode: 'online'
HW restricted: 'no'

So is the problem in the modem firmware reporting an older DMS that
what it is really using, or is it in libqmi?

However, ModemManager still does not work because of the other message
(I recompiled it against the patched libqmi library):

ModemManager[710]:   couldn't load Supported Bands: 'QMI
operation failed: Cannot send message: QMI service 'dms' version '1.3'
required, got version '1.0''
ModemManager[710]:   Modem couldn't be initialized: Couldn't
check unlock status: Couldn't get SIM lock status after 6 retries
ModemManager[710]:   Modem: state changed (unknown -> failed)

Will this allow a similar fix?

On Wed, Sep 7, 2016 at 4:29 PM, Dan Williams <d...@redhat.com> wrote:
> On Wed, 2016-09-07 at 15:33 +0200, José  wrote:
>> Maybe I was wrong. I am trying now with the last versions but it is
>> still not working:
>>
>> ModemManager 1.6.0
>> libqmi-1.16.0-r0.4.cortexa9hf_vfp_neon
>>
>> The problem is still reproducible:
>
> Interesting; even though it's a recent device, it's still advertising
> DMS 1.0.
>
> It may be that Get Operating Mode was present in DMS 1.0 and we simply
> don't have any examples of that.  So you could try to modify libqmi and
> see if that works.
>
> Look in data/qmi-service-dms.json and look for "Get Operating Mode".
>  Change the "1.1" there to "1.0", rebuild, and reinstall libqmi.  Then
> see if you can run "qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode".
>  Does that work?
>
> Dan
>
>> ModemManager[995]:   ModemManager (version 1.6.0) starting in
>> system bus...
>> ModemManager[995]: [/dev/cdc-wdm0] Opening device with flags
>> 'version-info, proxy'...
>> ModemManager[995]: cannot connect to proxy: Could not connect:
>> Connection refused
>> ModemManager[995]: spawning new qmi-proxy (try 1)...
>> ModemManager[995]: [/dev/cdc-wdm0] Checking version info (10
>> retries)...
>> ModemManager[995]: [/dev/cdc-wdm0] QMI Device supports 25 services:
>> ModemManager[995]: [/dev/cdc-wdm0]ctl (1.5)
>> ModemManager[995]: [/dev/cdc-wdm0]wds (1.67)
>> ModemManager[995]: [/dev/cdc-wdm0]dms (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]nas (1.25)
>> ModemManager[995]: [/dev/cdc-wdm0]qos (1.12)
>> ModemManager[995]: [/dev/cdc-wdm0]wms (1.10)
>> ModemManager[995]: [/dev/cdc-wdm0]auth (1.3)
>> ModemManager[995]: [/dev/cdc-wdm0]at (1.2)
>> ModemManager[995]: [/dev/cdc-wdm0]voice (2.1)
>> ModemManager[995]: [/dev/cdc-wdm0]cat2 (2.24)
>> ModemManager[995]: [/dev/cdc-wdm0]uim (1.46)
>> ModemManager[995]: [/dev/cdc-wdm0]pbm (1.4)
>> ModemManager[995]: [/dev/cdc-wdm0]test (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]loc (2.0)
>> ModemManager[995]: [/dev/cdc-wdm0]sar (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]ts (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]tmd (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]wda (1.16)
>> ModemManager[995]: [/dev/cdc-wdm0]csvt (1.1)
>> ModemManager[995]: [/dev/cdc-wdm0]coex (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]pdc (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]rfrpe (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]dsd (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]unknown [0x30] (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]unknown [0x36] (1.0)
>> ModemManager[995]:   Creating modem with plugin 'Generic' and
>> '2' ports
>> ModemManager[995]:   Modem for device at
>> '/sys/devices/soc0/soc.0/210.aips-
>> bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3'
>> successfully created
>> ModemManager[995]: [/dev/cdc-wdm0] Opening device with flags
>> 'version-info, proxy'...
>> ModemManager[995]: [/dev/cdc-wdm0] Checking version info (10
>> retries)...
>> ModemManager[995]: [/dev/cdc-wdm0] QMI Device supports 25 services:
>> ModemManager[995]: [/dev/cdc-wdm0]ctl (1.5)
>> ModemManager[995]: [/dev/cdc-wdm0]wds (1.67)
>> ModemManager[995]: [/dev/cdc-wdm0]dms (1.0)
>> ModemManager[995]: [/dev/cdc-wdm0]nas (1.25)
>> ModemManager[995]: [/dev/cdc-wdm0]qos (1.12)
>> ModemManager[995]: [/dev/cdc-wdm0]wms (1.10)
>> ModemManager[995]: [/dev/cdc-wdm0]auth (1.3)
>> ModemManager[995]: [/dev/cdc-wdm0]at (1.2)
>> ModemManager[995]: [/dev/cdc-wdm0]

Re: QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-07 Thread José 
Hi Thomas,

thanks for the advice! The EC20 is workign fine. For the EC21, I get
the following error:

'QMI operation failed: Cannot send message: QMI service 'dms' version
'1.1' required, got version '1.0''

I suspect that can be fixed but just upgrading ModemManager or libqmi
(or maybe both). Is that correct?

On Tue, Sep 6, 2016 at 9:51 PM, Thomas Schäfer <tschae...@t-online.de> wrote:
> Am Dienstag, 6. September 2016, 17:57:45 schrieb José:
>> Hi,
>>
>> I am planning to test ModemManager with QUECTEL EC20 and EC21 cellular
>> modems. These modems support the following drivers:
>> * USB Serial (option.c)
>> * CDC ACM
>> * GobiNet
>> * QMI WWAN
>>
>> What is the best approach for trying to use ModemManager?
>
> QMI WWAN, option.c
>
>
>> Should I
>> enable all drivers?
>
> No.
>
>
>>
>> Could you recommend which one of those to enable? Thanks
>
> https://sigquit.wordpress.com/2014/06/11/qmiwwan-or-gobinet/
>
>
>
> I think this blog is still valid.
>
>
> Thomas
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

QUECTEL EC20/EC21. Several drivers supported, which one is better to use?

2016-09-06 Thread José 
Hi,

I am planning to test ModemManager with QUECTEL EC20 and EC21 cellular
modems. These modems support the following drivers:
* USB Serial (option.c)
* CDC ACM
* GobiNet
* QMI WWAN

What is the best approach for trying to use ModemManager? Should I
enable all drivers? Only the newest/more advanced one?

Could you recommend which one of those to enable? Thanks
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Cinterion PLS8-X, udhcp fails

2016-03-18 Thread José 
I am trying to use a Cinterion PLS8-X with ModemManager. The modem is
properly identified and enabled, and the connection is properly
established. But when I try to use the network interfaces and get an
IP from the DHCP server, it fails to get any IP address.

This is the log:

root@ccimx6sbc:~# ModemManager &
root@ccimx6sbc:~# ModemManager[827]:   ModemManager (version
1.4.12) starting in system bus...
ModemManager[827]:   Creating modem with plugin 'Cinterion' and '7' ports
ModemManager[827]:   Could not grab port (tty/ttyACM4): 'Cannot
add port 'tty/ttyACM4', unhandled serial type'
ModemManager[827]:   Could not grab port (tty/ttyACM3): 'Cannot
add port 'tty/ttyACM3', unhandled serial type'
ModemManager[827]:   Could not grab port (tty/ttyACM2): 'Cannot
add port 'tty/ttyACM2', unhandled serial type'
ModemManager[827]:   Modem for device at
'/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.1'
successfully created
ModemManager[827]:   Modem: state changed (unknown -> disabled)

root@ccimx6sbc:~#
root@ccimx6sbc:~#
root@ccimx6sbc:~# mmcli -m 0 --simple-connect=movistar.es
Error parsing connect string: 'Couldn't find equal sign separator'
root@ccimx6sbc:~# mmcli -m 0 --simple-connect=apn=movistar.es
ModemManager[827]:   Simple connect started...
ModemManager[827]:   Simple connect state (3/8): Enable
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (disabled ->
enabling)
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
changed (unknown -> registering)
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
changed (registering -> home)
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (enabling ->
registered)
ModemManager[827]:   Simple connect state (4/8): Wait to get fully enabled
ModemManager[827]:   Simple connect state (5/8): Register
ModemManager[827]:   Simple connect state (6/8): Bearer
ModemManager[827]:   Simple connect state (7/8): Connect
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (registered ->
connecting)
ModemManager[827]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (connecting ->
connected)
ModemManager[827]:   Simple connect state (8/8): All done
successfully connected the modem
root@ccimx6sbc:~# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id
'f19bc7567e36f9fef0e5998b5f6a9f7346785ec1')
  -
  Hardware |   manufacturer: 'Cinterion'
   |  model: 'PLS8-X'
   |   revision: 'REVISION 03.003'
   |  supported: 'gsm-umts, lte'
   |current: 'gsm-umts, lte'
   |   equipment id: '004401081420651'
  -
  System   | device:
'/sys/devices/soc0/soc.0/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.1'
   |drivers: 'cdc_acm, cdc_ether'
   | plugin: 'Cinterion'
   |   primary port: 'ttyACM1'
   |  ports: 'ttyACM1 (at), ttyACM0 (at), usb0 (net),
usb1 (net)'
  -
  Numbers  |   own : 'unknown'
  -
  Status   |   lock: 'none'
   | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10),
sim-puk2 (10), ph-net-pin (10), ph-net-puk (32), ph-fsim-pin (10),
ph-fsim-puk (32)'
   |  state: 'connected'
   |power state: 'on'
   |access tech: 'edge'
   | signal quality: '20' (recent)
  -
  Modes|  supported: 'allowed: 2g; preferred: none
   |  allowed: 3g; preferred: none
   |  allowed: 2g, 3g; preferred: none
   |  allowed: 2g, 3g, 4g; preferred: none'
   |current: 'allowed: any; preferred: none'
  -
  Bands|  supported: 'egsm, dcs, pcs, g850, u1900, u850'
   |current: 'egsm, dcs, pcs, g850, u1900, u850'
  -
  IP   |  supported: 'ipv4, ipv6, ipv4v6'
  -
  3GPP |   imei: '004401081420651'
   |  enabled locks: 'none'
   |operator id: '21407'
   |  operator name: 'Movistar'
   |   subscription: 'unknown'
   |   registration: 'home'
  -
  SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'

  -
  Bearers  |  paths: '/org/freedesktop/ModemManager1/Bearer/0'

root@ccimx6sbc:~# mmcli -
root@ccimx6sbc:~# udhcpc -i usb0
udhcpc (v1.23.2) started
cdc_ether 1-1.1:1.10 usb0: CDC: unexpected notification 01!
Sending discover...
Sending discover...
^C
root@ccimx6sbc:~# udhcpc -i usb1
udhcpc (v1.23.2) started
cdc_ether 1-1.1:1.12 usb1: CDC: unexpected notification 01!
Sending discover...

Any idea why the CDC ether driver warns about that unexpected
notifications,

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 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 <d...@redhat.com> 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 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
<aleksan...@aleksander.es> 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://aleksand

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

2016-01-19 Thread José 
ot;
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==""

  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.4/ttyUSB2':
KERNELS=="ttyUSB2"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"

root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB3 | 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.5/ttyUSB3/tty/ttyUSB3':
KERNEL=="ttyUSB3"
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.5/ttyUSB3':
KERNELS=="ttyUSB3"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"

root@ccimx6sbc:~# udevadm info -a -p /sys/class/tty/ttyUSB4 | 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.6/ttyUSB4/tty/ttyUSB4':
KERNEL=="ttyUSB4"
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.6/ttyUSB4':
KERNELS=="ttyUSB4"
SUBSYSTEMS=="usb-serial"
DRIVERS=="option1"
ATTRS{port_number}=="0"

On Tue, Jan 19, 2016 at 5:34 PM, Aleksander Morgado
<aleksan...@aleksander.es> wrote:
> On Tue, Jan 19, 2016 at 4:51 PM, José <josedd...@gmail.com> 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 th

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
<aleksan...@aleksander.es> wrote:
> On Mon, Jan 18, 2016 at 4:13 PM, José <josedd...@gmail.com> 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

LOG-LEVEL not working properly

2015-10-30 Thread José 
I am using the following to launch ModemManager

ModemManager --log-level=ERR

and then connecting using mmcli -m 0 -e and mmcli -m 0 --simple-connect=...

Most of the messages, are removed. But there are some no error message
which still shows up, like these:

ModemManager[671]: opening device...
ModemManager[671]: opening device...
ModemManager[671]: cannot connect to proxy: Could not connect: Connection
refused
ModemManager[671]: cannot connect to proxy: Could not connect: Connection
refused
ModemManager[671]: spawning new mbim-proxy (try 1)...
ModemManager[671]: spawning new mbim-proxy (try 1)...
ModemManager[671]: [/dev/cdc-wdm0] Read max control message size from
descriptors file: 4096
ModemManager[671]: [/dev/cdc-wdm0] Read max control message size from
descriptors file: 4096
ModemManager[671]: opening device...
ModemManager[671]: opening device...
ModemManager[671]: [/dev/cdc-wdm0] Read max control message size from
descriptors file: 4096
ModemManager[671]: [/dev/cdc-wdm0] Read max control message size from
descriptors file: 4096

Is this a bug? Even launching with

ModemManager --log-level=ERR > /dev/null 2>&1

the messages still appear. How can I get rid of them?
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Force 2G/3G/4G modes (when they are not reported as supported)

2015-10-28 Thread José 
Hi, I am working with a Sierra MC7710, and this is a output example from
ModemManager:

root@ccimx6sbc:~# mmcli -m 0



/org/freedesktop/ModemManager1/Modem/0 (device id
'29d88ce7cabb0305731a99b422f212ed0b521c0f')

  -

  Hardware |   manufacturer: 'Generic'

   |  model: 'MBIM [1199:68A2]'

   |   revision: 'SWI9200X_03.05.23.02ap'

   |  supported: 'gsm-umts, lte'

   |current: 'gsm-umts, lte'

   |   equipment id: '358178043545302'

  -

  System   | device:
'/sys/devices/soc0/soc.1/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.3'

   |drivers: 'qcserial, cdc_mbim'

   | plugin: 'Generic'

   |   primary port: 'cdc-wdm0'

   |  ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm0
(mbim), wwan0 (net)'

  -

  Numbers  |   own : 'unknown'

  -

  Status   |   lock: 'none'

   | unlock retries: 'sim-pin2 (3)'

   |  state: 'connected'

   |power state: 'on'

   |access tech: 'lte'

   | signal quality: '54' (recent)

  -

  Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'

   |current: 'allowed: 2g, 3g, 4g; preferred: none'

  -

  Bands|  supported: 'unknown'

   |current: 'unknown'

  -

  IP   |  supported: 'ipv4, ipv6, ipv4v6'

  -

  3GPP |   imei: '358178043545302'

   |  enabled locks: 'fixed-dialing, ph-fsim, net-pers,
net-sub-pers, provider-pers, corp-pers'

   |operator id: '21407'

   |  operator name: 'Movistar'

   |   subscription: 'unknown'

   |   registration: 'home'

  -

  SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'


  -

  Bearers  |  paths: '/org/freedesktop/ModemManager1/Bearer/0'


As you can see, there is only one supported mode (allowed: 2g, 3g, 4g;
preferred: none) which (as far as I know) offers me no contl about
which network technology is being used. When using this modem with
other SIM cards or other protocols (this modem also supports QMI,
direct IP and serial) the supported modes varies.

My understanding is that the supported modes are provided by the modem
to ModemManager. Which variables affect the supported modes reported?

Is there a way to force ModemManager to use only 2g/3g/4g despite of
the supported modes reported by the modem?
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

assertion 'g_utf8_validate (string, -1, NULL)' failed

2015-10-21 Thread José 
Hi, I am working with Telit LE910. It works properly with ModemManager
using QMI, but if I disable and enable the modem again, I get the following:

root@ccimx6sbc:~# mmcli -m 0 -e

ModemManager[698]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (disabled ->
enabling)

ModemManager[698]:   (ttyUSB2): port attributes not fully set

ModemManager[698]:   (ttyUSB3): port attributes not fully set

ModemManager[698]:   Modem
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
changed (unknown -> registering)



(ModemManager:698): GLib-CRITICAL **: g_variant_new_string: assertion
'g_utf8_validate (string, -1, NULL)' failed



(ModemManager:698): GLib-CRITICAL **: g_variant_ref_sink: assertion
'value != NULL' failed

ModemManager[698]:   Modem
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
changed (registering -> home)

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(17): 'MissingArgument'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(52): 'DeviceNotReady'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(48): 'InvalidArgument'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(48): 'InvalidArgument'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(17): 'MissingArgument'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(52): 'DeviceNotReady'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(48): 'InvalidArgument'

ModemManager[698]: Couldn't read SMS messages: QMI protocol error
(48): 'InvalidArgument'

ModemManager[698]:   Modem
/org/freedesktop/ModemManager1/Modem/0: state changed (enabling ->
registered)

successfully enabled the modem


Why are those asserts coming out? How can I fix those?
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel