Bug 94093 - Sending USSD command fails on Telit HE910
Summary: Sending USSD command fails on Telit HE910
Status: RESOLVED INVALID
Alias: None
Product: ModemManager
Classification: Unclassified
Component: general (show other bugs)
Version: 1.4
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: ModemManager bug user
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-11 16:47 UTC by Aaron
Modified: 2016-02-12 16:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
ModemManager Debug Log (218.41 KB, text/plain)
2016-02-11 17:18 UTC, Aaron
Details
Network Manager Debug Log (149.51 KB, text/plain)
2016-02-11 17:18 UTC, Aaron
Details

Description Aaron 2016-02-11 16:47:49 UTC

    
Comment 1 Aaron 2016-02-11 16:48:37 UTC
sh-4.3# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id '0051f232353f540ba8a274cc77328b08efb8c84d')
  -------------------------
  Hardware |   manufacturer: 'Telit'
           |          model: 'HE910'
           |       revision: '12.00.004'
           |      supported: 'gsm-umts'
           |        current: 'gsm-umts'
           |   equipment id: '357164040972005'
  -------------------------
  System   |         device: '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4'
           |        drivers: 'cdc_acm'
           |         plugin: 'Telit'
           |   primary port: 'ttyACM3'
           |          ports: 'ttyACM3 (at)'
  -------------------------
  Numbers  |           own : '15208347546'
  -------------------------
  Status   |           lock: 'none'
           | unlock retries: 'unknown'
           |          state: 'connected'
           |    power state: 'on'
           |    access tech: 'unknown'
           | signal quality: '0' (cached)
  -------------------------
  Modes    |      supported: 'allowed: 2g, 3g; preferred: none'
           |        current: 'allowed: 2g, 3g; preferred: none'
  -------------------------
  Bands    |      supported: 'unknown'
           |        current: 'unknown'
  -------------------------
  IP       |      supported: 'ipv4, ipv6, ipv4v6'
  -------------------------
  3GPP     |           imei: '357164040972005'
           |  enabled locks: 'none'
           |    operator id: '310410'
           |  operator name: 'AT&T'
           |   subscription: 'unknown'
           |   registration: 'home'
  -------------------------
  SIM      |           path: '/org/freedesktop/ModemManager1/SIM/0'

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

sh-4.3# ping google.com
PING google.com (216.58.219.46) 56(84) bytes of data.
64 bytes from lax17s04-in-f14.1e100.net (216.58.219.46): icmp_seq=1 ttl=54 time=109 ms
64 bytes from lax17s04-in-f14.1e100.net (216.58.219.46): icmp_seq=2 ttl=54 time=329 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2001ms
rtt min/avg/max/mdev = 109.745/219.396/329.048/109.652 ms
sh-4.3# mmcli -m 0 --3gpp-ussd-initiate="*901#"
error: couldn't initiate USSD session: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Sending USSD command failed'
Comment 2 Aleksander Morgado 2016-02-11 16:57:09 UTC
Could you get us debug logs while trying to reproduce it?

https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
Comment 3 Aaron 2016-02-11 17:18:19 UTC
Created attachment 121681 [details]
ModemManager Debug Log
Comment 4 Aaron 2016-02-11 17:18:41 UTC
Created attachment 121682 [details]
Network Manager Debug Log
Comment 5 Aaron 2016-02-11 17:20:54 UTC
(In reply to Aleksander Morgado from comment #2)
> Could you get us debug logs while trying to reproduce it?
> 
> https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/

I have added the logs. One thing I will mention and I think this is probably the cause of the issue, is that for our product we had to disable ModemManager from probing port ttyACM0 because it would lock this port and we need to open this serial port in our app to send/receive AT commands to get GPS data.

If you agree that is indeed the issue, is there a better solution you know of for this card?

Thanks
Comment 6 Aleksander Morgado 2016-02-12 07:58:01 UTC
(In reply to Aaron from comment #5)
> (In reply to Aleksander Morgado from comment #2)
> > Could you get us debug logs while trying to reproduce it?
> > 
> > https://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
> 
> I have added the logs. One thing I will mention and I think this is probably
> the cause of the issue, is that for our product we had to disable
> ModemManager from probing port ttyACM0 because it would lock this port and
> we need to open this serial port in our app to send/receive AT commands to
> get GPS data.
> 
> If you agree that is indeed the issue, is there a better solution you know
> of for this card?
> 

Yes, that's the issue. With this modem you get 2 TTYs, ttyACM3 and ttyACM0; ttyACM0 is the one flagged as primary by MM, but then looks like it cannot grab it, I'm assuming that's where you added the hack. With only one TTY available, if the modem is connected you won't be able to run AT commands for USSD or other stuff, like the periodic signal quality checks.

The ideal solution would be to implement the GPS commands directly in ModemManager. I'm assuming that what you need is a port to enable/disable GPS via AT commands. If that is so, those commands could be implemented in ModemManager itself, e.g. in the "unmanaged GPS" setup where MM just acts as the one who enables/disables GPS, without taking care of the actual NMEA traces reception and management (i.e. leaving that to whatever other application you have around for that).

I'll get the bug closed as invalid.
Comment 7 Aaron 2016-02-12 16:35:03 UTC
Currently we use the port to send commands to get location information and perform resets on the GPS. These are the GPSP and GPSACP AT commands. Perhaps we can get this information directly from mmcli instead? or set the modem to have an extra TTY which MM doesn't lock?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.