Telit ME910C1-WW not detected
by Dresdo Gabriele
Hello,
I'm new to oFono, I'm trying to setup a Telit ME910C1 with oFono 1.18 in our embedded system (ARMHF) with Debian stretch kernel 4.9.11 but list-modems returns no results.
I installed ofono packet using apt-get
I can send and receive AT commands to the modem using a terminal connected to /dev/ttyUSB1
I paste Log from ofonod -dn.
Any suggestion will be useful
Thanks
Gabriele
ofonod[592]: oFono version 1.18
ofonod[592]: src/plugin.c:__ofono_plugin_init()
ofonod[592]: plugins/push-notification.c:push_notification_init()
ofonod[592]: plugins/smart-messaging.c:smart_messaging_init()
ofonod[592]: src/cdma-provision.c:ofono_cdma_provision_driver_register() driver: 0x54c3f868 name: CDMA provisioning
ofonod[592]: src/gprs-provision.c:ofono_gprs_provision_driver_register() driver: 0x54c3f83c name: Provisioning
ofonod[592]: plugins/upower.c:upower_init() upower init
ofonod[592]: src/handsfree-audio.c:ofono_handsfree_card_driver_register() driver: 0x54c3f7e8
ofonod[592]: plugins/dun_gw_bluez5.c:dun_gw_init()
ofonod[592]: src/handsfree-audio.c:ofono_handsfree_card_driver_register() driver: 0x54c3f74c
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f760, name: hfp
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f704, name: ublox
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f6ac, name: quectel
ofonod[592]: plugins/he910.c:he910_init()
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f65c, name: he910
ofonod[592]: plugins/connman.c:connman_init()
ofonod[592]: src/private-network.c:ofono_private_network_driver_register() driver: 0x54c3f630, name: ConnMan Private Network
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f5e8, name: sim900
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f5a0, name: samsung
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f558, name: speedupcdma
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f508, name: speedup
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f4c0, name: alcatel
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f468, name: icera
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f420, name: linktop
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f3d8, name: nokiacdma
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f390, name: nokia
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f348, name: cinterion
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f2c0, name: ste
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f268, name: ifx
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f220, name: palmpre
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f1d0, name: novatel
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f188, name: sierra
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f110, name: huawei
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f0c8, name: zte
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f068, name: hso
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3f018, name: mbm
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3efc8, name: calypso
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ef80, name: wavecom
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ef38, name: g1
ofonod[592]: src/cdma-voicecall.c:ofono_cdma_voicecall_driver_register() driver: 0x54c3eedc, name: cdmamodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ef04, name: cdmamodem
ofonod[592]: src/cdma-connman.c:ofono_cdma_connman_driver_register() driver: 0x54c3ef24, name: cdmamodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ee3c, name: phonesim
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ee6c, name: localhfp
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3ee20, name: phonesim
ofonod[592]: src/ctm.c:ofono_ctm_driver_register() driver: 0x54c3ee0c, name: phonesim
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3ede4, name: phonesim
ofonod[592]: plugins/phonesim.c:parse_config() filename /etc/ofono/phonesim.conf
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3edc8, name: ubloxmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3ed8c, name: speedupmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3ec48, name: hfpmodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ecec, name: hfpmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3eca0, name: hfpmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3ecd4, name: hfpmodem
ofonod[592]: src/handsfree.c:ofono_handsfree_driver_register() driver: 0x54c3ed1c, name: hfpmodem
ofonod[592]: src/siri.c:ofono_siri_driver_register() driver: 0x54c3ed54, name: hfpmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3ebc0, name: dunmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3ebe4, name: dunmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3eaf0, name: stemodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3eb7c, name: stemodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3eb40, name: stemodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e9cc, name: ifxmodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3ea24, name: ifxmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3ea38, name: ifxmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3ea70, name: ifxmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3ea9c, name: ifxmodem
ofonod[592]: src/ctm.c:ofono_ctm_driver_register() driver: 0x54c3eabc, name: ifxmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e958, name: hsomodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e97c, name: hsomodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e918, name: telitmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e88c, name: mbmmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e8b0, name: mbmmodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e8d0, name: mbmmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e7f4, name: calypsomodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e844, name: calypsomodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e6f8, name: huaweimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e70c, name: huaweimodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3e75c, name: huaweimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e794, name: huaweimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e770, name: huaweimodem
ofonod[592]: src/cdma-netreg.c:ofono_cdma_netreg_driver_register() driver: 0x54c3e7c4, name: huaweimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e67c, name: iceramodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e6a8, name: iceramodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e624, name: ztemodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e5e0, name: swmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e598, name: nwmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3e40c, name: atmodem
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3e4a4, name: atmodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3e45c, name: atmodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3e1e4, name: atmodem
ofonod[592]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x54c3e224, name: atmodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3e130, name: atmodem
ofonod[592]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x54c3e48c, name: atmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e3e8, name: atmodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3e1a0, name: atmodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3e328, name: atmodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3e370, name: atmodem-noef
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3e3c0, name: atmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3e288, name: atmodem
ofonod[592]: src/cbs.c:ofono_cbs_driver_register() driver: 0x54c3e1c8, name: atmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3e4d4, name: atmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3e504, name: atmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e518, name: atmodem
ofonod[592]: src/sim-auth.c:ofono_sim_auth_driver_register() driver: 0x54c3e53c, name: atmodem
ofonod[592]: src/gnss.c:ofono_gnss_driver_register() driver: 0x54c3e55c, name: atmodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3e090, name: gobi
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3ded0, name: qmimodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3df38, name: qmimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3def0, name: qmimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3df5c, name: qmimodem-legacy
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dfa4, name: qmimodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3dfec, name: qmimodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3e00c, name: qmimodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3e020, name: qmimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3e034, name: qmimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3e050, name: qmimodem
ofonod[592]: src/location-reporting.c:ofono_location_reporting_driver_register() driver: 0x54c3e078, name: qmimodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3de68, name: u8500
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3de48, name: u8500
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3de00, name: n900
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3ddb8, name: isiusb
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3db60, name: isimodem
ofonod[592]: src/phonebook.c:ofono_phonebook_driver_register() driver: 0x54c3db50, name: isimodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3db80, name: isimodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3dba4, name: isimodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3dbec, name: isimodem
ofonod[592]: src/cbs.c:ofono_cbs_driver_register() driver: 0x54c3dc0c, name: isimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dc20, name: isimodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3dc68, name: isimodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3dc7c, name: isimodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3dc9c, name: isimodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3dccc, name: isimodem
ofonod[592]: src/call-meter.c:ofono_call_meter_driver_register() driver: 0x54c3dce4, name: isimodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3dd0c, name: isimodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3dd34, name: isimodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3dd48, name: isimodem
ofonod[592]: src/audio-settings.c:ofono_audio_settings_driver_register() driver: 0x54c3dd64, name: isimodem
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3dd70, name: wgmodem2.5
ofonod[592]: drivers/rilmodem/rilmodem.c:rilmodem_init()
ofonod[592]: src/modem.c:ofono_devinfo_driver_register() driver: 0x54c3d928, name: rilmodem
ofonod[592]: drivers/rilmodem/sim.c:ril_sim_init()
ofonod[592]: src/sim.c:ofono_sim_driver_register() driver: 0x54c3d9fc, name: rilmodem
ofonod[592]: src/voicecall.c:ofono_voicecall_driver_register() driver: 0x54c3d96c, name: rilmodem
ofonod[592]: src/sms.c:ofono_sms_driver_register() driver: 0x54c3da44, name: rilmodem
ofonod[592]: src/network.c:ofono_netreg_driver_register() driver: 0x54c3d948, name: rilmodem
ofonod[592]: src/call-volume.c:ofono_call_volume_driver_register() driver: 0x54c3d9b4, name: rilmodem
ofonod[592]: src/gprs.c:ofono_gprs_driver_register() driver: 0x54c3d9cc, name: rilmodem
ofonod[592]: src/gprs.c:ofono_gprs_context_driver_register() driver: 0x54c3d9e0, name: rilmodem
ofonod[592]: src/ussd.c:ofono_ussd_driver_register() driver: 0x54c3da64, name: rilmodem
ofonod[592]: src/call-settings.c:ofono_call_settings_driver_register() driver: 0x54c3da78, name: rilmodem
ofonod[592]: src/call-forwarding.c:ofono_call_forwarding_driver_register() driver: 0x54c3daa8, name: rilmodem
ofonod[592]: src/radio-settings.c:ofono_radio_settings_driver_register() driver: 0x54c3dac8, name: rilmodem
ofonod[592]: src/call-barring.c:ofono_call_barring_driver_register() driver: 0x54c3daf0, name: rilmodem
ofonod[592]: src/netmon.c:ofono_netmon_driver_register() driver: 0x54c3db08, name: rilmodem
ofonod[592]: src/stk.c:ofono_stk_driver_register() driver: 0x54c3db18, name: rilmodem
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d8c0, name: ril_sofia3gr
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d878, name: infineon
ofonod[592]: src/modem.c:ofono_modem_driver_register() driver: 0x54c3d830, name: ril
ofonod[592]: plugins/udevng.c:udev_start()
ofonod[592]: plugins/udevng.c:enumerate_devices()
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() usb [0424:2514]
ofonod[592]: plugins/udevng.c:check_usb_device() usb [1bc7:1101]
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.0/ttyUSB0/tty/ttyUSB0
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB0 (telit) 255/255/255 [00] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.1/ttyUSB1/tty/ttyUSB1
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB1 (telit) 255/255/255 [01] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.2/ttyUSB2/tty/ttyUSB2
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB2 (telit) 255/254/255 [02] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() option [(null):(null)]
ofonod[592]: plugins/udevng.c:check_usb_device() option [1bc7:1101]
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:add_device() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3/2-1.3:1.3/ttyUSB3/tty/ttyUSB3
ofonod[592]: plugins/udevng.c:add_device() /dev/ttyUSB3 (telit) 255/255/255 [03] ==> (null) (null)
ofonod[592]: plugins/udevng.c:check_usb_device() hub [(null):(null)]
ofonod[592]: plugins/udevng.c:create_modem() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:create_modem() driver=telit
ofonod[592]: src/modem.c:ofono_modem_create() name: (null), type: telit
ofonod[592]: plugins/udevng.c:setup_telit() /sys/devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.3
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB0 255/255/255 00 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB1 255/255/255 01 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB2 255/254/255 02 (null)
ofonod[592]: plugins/udevng.c:setup_telit() /dev/ttyUSB3 255/255/255 03 (null)
ofonod[592]: plugins/udevng.c:setup_telit() modem=/dev/ttyUSB0 aux=/dev/ttyUSB3 gps=(null) diag=/dev/ttyUSB1
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property Modem
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property Aux
ofonod[592]: src/modem.c:set_modem_property() modem 0x55d8e3d8 property GPS
ofonod[592]: src/modem.c:ofono_modem_register() 0x55d8e3d8
7 months, 3 weeks
[PATCH] quectel: detect missing sim-cards
by Martin Hundebøll
The unsolicited +CPIN: NOT INSERTED is lost on the M95 and MC60 modems
during CMUX setup, and the CPIN? query responds with an unhandled
CME ERROR: 10.
Use at_util_sim_state_query_new() to detect SIM presence/pin-state
during power-on. (M95 / MC60 don't support hotplug of sim card).
---
Philip: This patch removes the CFUN? query that is apparently needed for
UC15 modems, but I don't have such a modem to test on. Are you still
working with this and can you test this?
plugins/quectel.c | 90 ++++++-----------------------------------------
1 file changed, 11 insertions(+), 79 deletions(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index bddf6a17..741aced6 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -59,7 +59,6 @@
#include <drivers/atmodem/vendor.h>
static const char *cfun_prefix[] = { "+CFUN:", NULL };
-static const char *cpin_prefix[] = { "+CPIN:", NULL };
static const char *cbc_prefix[] = { "+CBC:", NULL };
static const char *qinistat_prefix[] = { "+QINISTAT:", NULL };
static const char *cgmm_prefix[] = { "UC15", "Quectel_M95", "Quectel_MC60",
@@ -87,12 +86,12 @@ enum quectel_model {
struct quectel_data {
GAtChat *modem;
GAtChat *aux;
- guint cpin_ready;
guint call_ready;
bool have_sim;
enum ofono_vendor vendor;
enum quectel_model model;
struct l_timeout *sms_ready_timer;
+ struct at_util_sim_state_query *sim_state_query;
/* used by quectel uart driver */
GAtChat *uart;
@@ -182,9 +181,6 @@ static void quectel_remove(struct ofono_modem *modem)
DBG("%p", modem);
- if (data->cpin_ready != 0)
- g_at_chat_unregister(data->aux, data->cpin_ready);
-
ofono_modem_set_data(modem, NULL);
l_gpio_writer_free(data->gpio);
g_at_chat_unref(data->aux);
@@ -523,68 +519,25 @@ static void dbus_hw_enable(struct ofono_modem *modem)
ofono_modem_add_interface(modem, dbus_hw_interface);
}
-static void cpin_notify(GAtResult *result, gpointer user_data)
+static void sim_state_cb(gboolean present, gpointer user_data)
{
struct ofono_modem *modem = user_data;
struct quectel_data *data = ofono_modem_get_data(modem);
- const char *sim_inserted;
- GAtResultIter iter;
DBG("%p", modem);
- g_at_result_iter_init(&iter, result);
-
- if (!g_at_result_iter_next(&iter, "+CPIN:"))
- return;
-
- g_at_result_iter_next_unquoted_string(&iter, &sim_inserted);
-
- if (g_strcmp0(sim_inserted, "NOT INSERTED") != 0)
- data->have_sim = true;
-
- ofono_modem_set_powered(modem, TRUE);
-
- /* Turn off the radio. */
- g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix, NULL, NULL, NULL);
-
- g_at_chat_unregister(data->aux, data->cpin_ready);
- data->cpin_ready = 0;
+ if (!present)
+ ofono_warn("%s sim not present", ofono_modem_get_path(modem));
+ data->have_sim = present;
dbus_hw_enable(modem);
+ ofono_modem_set_powered(modem, TRUE);
}
-static void cpin_query(gboolean ok, GAtResult *result, gpointer user_data)
-{
- DBG("%p ok %d", user_data, ok);
-
- if (ok)
- cpin_notify(result, user_data);
-}
-
-static void cfun_enable(gboolean ok, GAtResult *result, gpointer user_data)
-{
- struct ofono_modem *modem = user_data;
- struct quectel_data *data = ofono_modem_get_data(modem);
-
- DBG("%p ok %d", modem, ok);
-
- if (!ok) {
- close_serial(modem);
- return;
- }
-
- data->cpin_ready = g_at_chat_register(data->aux, "+CPIN", cpin_notify,
- FALSE, modem, NULL);
- g_at_chat_send(data->aux, "AT+CPIN?", cpin_prefix, cpin_query, modem,
- NULL);
-}
-
-static void cfun_query(gboolean ok, GAtResult *result, gpointer user_data)
+static void cfun_cb(gboolean ok, GAtResult *result, gpointer user_data)
{
struct ofono_modem *modem = user_data;
struct quectel_data *data = ofono_modem_get_data(modem);
- GAtResultIter iter;
- int cfun;
DBG("%p ok %d", modem, ok);
@@ -593,30 +546,9 @@ static void cfun_query(gboolean ok, GAtResult *result, gpointer user_data)
return;
}
- g_at_result_iter_init(&iter, result);
-
- if (g_at_result_iter_next(&iter, "+CFUN:") == FALSE) {
- close_serial(modem);
- return;
- }
-
- g_at_result_iter_next_number(&iter, &cfun);
-
- /*
- * The modem firmware powers up in CFUN=1 but will respond to AT+CFUN=4
- * with ERROR until some amount of time (which varies with temperature)
- * passes. Empirical evidence suggests that the firmware will report an
- * unsolicited +CPIN: notification when it is ready to be useful.
- *
- * Work around this feature by only transitioning to CFUN=4 if the
- * modem is not in CFUN=1 or until after we've received an unsolicited
- * +CPIN: notification.
- */
- if (cfun != 1)
- g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix, cfun_enable,
- modem, NULL);
- else
- cfun_enable(TRUE, NULL, modem);
+ data->sim_state_query = at_util_sim_state_query_new(data->aux, 2, 20,
+ sim_state_cb,
+ modem, NULL);
}
static void cgmm_cb(int ok, GAtResult *result, void *user_data)
@@ -651,7 +583,7 @@ static void cgmm_cb(int ok, GAtResult *result, void *user_data)
data->model = QUECTEL_UNKNOWN;
}
- g_at_chat_send(data->aux, "AT+CFUN?", cfun_prefix, cfun_query, modem,
+ g_at_chat_send(data->aux, "AT+CFUN=4", none_prefix, cfun_cb, modem,
NULL);
}
--
2.22.0
1 year
[PATCH v2 1/3] gprs: Check for LTE in gprs_attached_update
by richard.rojfors＠gmail.com
From: Richard Röjfors <richard(a)puffinpack.se>
Since we have a different condition for the attach state
when running on LTE, we should consider it in gprs_attached_update.
Previously it's done in some instances. But for instance if
the driver got detached from GPRS but now running on LTE with a
context up, we would be deattached.
---
src/gprs.c | 51 ++++++++++++++++++++++++++++-----------------------
1 file changed, 28 insertions(+), 23 deletions(-)
diff --git a/src/gprs.c b/src/gprs.c
index bba482cb..5829a577 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -1571,13 +1571,34 @@ static void release_active_contexts(struct ofono_gprs *gprs)
}
}
+static gboolean on_lte(struct ofono_gprs *gprs)
+{
+ if (ofono_netreg_get_technology(gprs->netreg) ==
+ ACCESS_TECHNOLOGY_EUTRAN && have_read_settings(gprs))
+ return TRUE;
+
+ return FALSE;
+}
+
static void gprs_attached_update(struct ofono_gprs *gprs)
{
ofono_bool_t attached;
+ int status = gprs->status;
- attached = gprs->driver_attached &&
- (gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
- gprs->status == NETWORK_REGISTRATION_STATUS_ROAMING);
+ if (on_lte(gprs))
+ /*
+ * For LTE we attached status reflects successful context
+ * activation.
+ * Since we in gprs_netreg_update not even try to attach
+ * to GPRS if we are running on LTE, we can on some modems
+ * expect the gprs status to be unknown. That must not
+ * result in detaching...
+ */
+ attached = have_active_contexts(gprs);
+ else
+ attached = gprs->driver_attached &&
+ (status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
+ status == NETWORK_REGISTRATION_STATUS_ROAMING);
if (attached == gprs->attached)
return;
@@ -1591,11 +1612,13 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
if (attached == FALSE) {
release_active_contexts(gprs);
gprs->bearer = -1;
- } else if (have_active_contexts(gprs) == TRUE) {
+ } else if (have_active_contexts(gprs) == TRUE && !on_lte(gprs)) {
/*
* Some times the context activates after a detach event and
* right before an attach. We close it to avoid unexpected open
* contexts.
+ * Skip that for LTE since the condition to be attached on LTE
+ * is that a context gets activated
*/
release_active_contexts(gprs);
gprs->flags |= GPRS_FLAG_ATTACHED_UPDATE;
@@ -1660,15 +1683,6 @@ static void gprs_netreg_removed(struct ofono_gprs *gprs)
gprs_attached_update(gprs);
}
-static gboolean on_lte(struct ofono_gprs *gprs)
-{
- if (ofono_netreg_get_technology(gprs->netreg) ==
- ACCESS_TECHNOLOGY_EUTRAN && have_read_settings(gprs))
- return TRUE;
-
- return FALSE;
-}
-
static void gprs_netreg_update(struct ofono_gprs *gprs)
{
ofono_bool_t attach;
@@ -2573,16 +2587,7 @@ void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status)
if (status != NETWORK_REGISTRATION_STATUS_REGISTERED &&
status != NETWORK_REGISTRATION_STATUS_ROAMING) {
- /*
- * For LTE we attached status reflects successful context
- * activation.
- * Since we in gprs_netreg_update not even try to attach
- * to GPRS if we are running on LTE, we can on some modems
- * expect the gprs status to be unknown. That must not
- * result in detaching...
- */
- if (!on_lte(gprs))
- gprs_attached_update(gprs);
+ gprs_attached_update(gprs);
return;
}
--
2.20.1
1 year, 2 months
[PATCH 1/4] gprs: Check for LTE in gprs_attached_update
by richard.rojfors＠gmail.com
From: Richard Röjfors <richard(a)puffinpack.se>
Since we have a different condition for the attach state
when running on LTE, we should consider it in gprs_attached_update.
Previously it's done in some instances. But for instance if
the driver got detached from GPRS but now running on LTE with a
context up, we would be deattached.
---
src/gprs.c | 52 +++++++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/src/gprs.c b/src/gprs.c
index bba482cb..94d13f82 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -1571,13 +1571,34 @@ static void release_active_contexts(struct ofono_gprs *gprs)
}
}
+static gboolean on_lte(struct ofono_gprs *gprs)
+{
+ if (ofono_netreg_get_technology(gprs->netreg) ==
+ ACCESS_TECHNOLOGY_EUTRAN && have_read_settings(gprs))
+ return TRUE;
+
+ return FALSE;
+}
+
static void gprs_attached_update(struct ofono_gprs *gprs)
{
ofono_bool_t attached;
+ int status = gprs->status;
- attached = gprs->driver_attached &&
- (gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
- gprs->status == NETWORK_REGISTRATION_STATUS_ROAMING);
+ if (on_lte(gprs))
+ /*
+ * For LTE we attached status reflects successful context
+ * activation.
+ * Since we in gprs_netreg_update not even try to attach
+ * to GPRS if we are running on LTE, we can on some modems
+ * expect the gprs status to be unknown. That must not
+ * result in detaching...
+ */
+ attached = have_active_contexts(gprs);
+ else
+ attached = gprs->driver_attached &&
+ (status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
+ status == NETWORK_REGISTRATION_STATUS_ROAMING);
if (attached == gprs->attached)
return;
@@ -1591,11 +1612,14 @@ static void gprs_attached_update(struct ofono_gprs *gprs)
if (attached == FALSE) {
release_active_contexts(gprs);
gprs->bearer = -1;
- } else if (have_active_contexts(gprs) == TRUE) {
+ } else if (have_active_contexts(gprs) == TRUE &&
+ !on_lte(gprs)) {
/*
* Some times the context activates after a detach event and
* right before an attach. We close it to avoid unexpected open
* contexts.
+ * Skip that for LTE since the condition to be attached on LTE
+ * is that a context gets activated
*/
release_active_contexts(gprs);
gprs->flags |= GPRS_FLAG_ATTACHED_UPDATE;
@@ -1660,15 +1684,6 @@ static void gprs_netreg_removed(struct ofono_gprs *gprs)
gprs_attached_update(gprs);
}
-static gboolean on_lte(struct ofono_gprs *gprs)
-{
- if (ofono_netreg_get_technology(gprs->netreg) ==
- ACCESS_TECHNOLOGY_EUTRAN && have_read_settings(gprs))
- return TRUE;
-
- return FALSE;
-}
-
static void gprs_netreg_update(struct ofono_gprs *gprs)
{
ofono_bool_t attach;
@@ -2573,16 +2588,7 @@ void ofono_gprs_status_notify(struct ofono_gprs *gprs, int status)
if (status != NETWORK_REGISTRATION_STATUS_REGISTERED &&
status != NETWORK_REGISTRATION_STATUS_ROAMING) {
- /*
- * For LTE we attached status reflects successful context
- * activation.
- * Since we in gprs_netreg_update not even try to attach
- * to GPRS if we are running on LTE, we can on some modems
- * expect the gprs status to be unknown. That must not
- * result in detaching...
- */
- if (!on_lte(gprs))
- gprs_attached_update(gprs);
+ gprs_attached_update(gprs);
return;
}
--
2.20.1
1 year, 2 months
Handle broken AT command process
by Martin Hundebøll
Hi,
Does ofono have a way to handle lacking OK/error messages? I seems like
my modem (Quectel M95) is buggy when it comes to unsolicited indications
and (as far as I have seen) SIM commands:
> AT+CRSM=178,28614,3,4,8
< +CRSM: 144,0,"FFFFFFFFFFFFFFFF"
< OK
> AT+CRSM=178,28614,4,4,8
< Call Ready
< +CREG: 5,"0119","04EA"
The "Call Ready" indication causes a lacking "OK" from the preceding
"AT+CRSM" command. This has happened with other CRSM commands, and can
also be caused by an unsolicited +CREG indication.
I guess one way handle it, is to to glue op the URC listeners to peek
into the AT command queue and check if a command is pending for
OK/errors, and retry it if so.
But that could cause unexpected side effects depending on the retried
command...
// Martin
1 year, 2 months
[rfc] Motorola Droid 4 voice: integrate into atmodem or completely separate?
by Pavel Machek
Hi!
Droid 4 has ... something similar to AT commands, but not quite. For
voice calls, I modified atmodem... but I guess there are so many
changes that creating separate motorolamodem/voicecall.c might be
an option? (send_clcc() changes make sense as a cleanup, and were sent
in separate mail.)
Any ideas?
Best regards,
Pavel
diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index d55cf00..e22d412 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -1,4 +1,4 @@
-/*
+/* -*- linux-c -*-
*
* oFono - Open Source Telephony
*
@@ -264,14 +264,18 @@ poll_again:
poll_clcc, vc);
}
+static void send_clcc(struct voicecall_data *vd, struct ofono_voicecall *vc)
+{
+ if (vd->vendor != OFONO_VENDOR_MOTMDM)
+ g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix, clcc_poll_cb, vc, NULL);
+}
+
static gboolean poll_clcc(gpointer user_data)
{
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, vc, NULL);
-
+ send_clcc(vd, vc);
vd->clcc_source = 0;
return FALSE;
@@ -297,8 +301,7 @@ static void generic_cb(gboolean ok, GAtResult *result, gpointer user_data)
}
}
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, req->vc, NULL);
+ send_clcc(vd, req->vc);
/* We have to callback after we schedule a poll if required */
req->cb(&error, req->data);
@@ -316,8 +319,7 @@ static void release_id_cb(gboolean ok, GAtResult *result,
if (ok)
vd->local_release = 1 << req->id;
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, req->vc, NULL);
+ send_clcc(vd, req->vc);
/* We have to callback after we schedule a poll if required */
req->cb(&error, req->data);
@@ -408,16 +410,17 @@ static void at_dial(struct ofono_voicecall *vc,
switch (clir) {
case OFONO_CLIR_OPTION_INVOCATION:
- strcat(buf, "I");
+ strcat(buf, (vd->vendor != OFONO_VENDOR_MOTMDM) ? "I" : ",0");
break;
case OFONO_CLIR_OPTION_SUPPRESSION:
- strcat(buf, "i");
+ strcat(buf, (vd->vendor != OFONO_VENDOR_MOTMDM) ? "i" : ",1");
break;
default:
break;
}
- strcat(buf, ";");
+ if (vd->vendor != OFONO_VENDOR_MOTMDM)
+ strcat(buf, ";");
if (g_at_chat_send(vd->chat, buf, atd_prefix,
atd_cb, cbd, g_free) > 0)
@@ -462,8 +465,13 @@ static void at_answer(struct ofono_voicecall *vc,
static void at_hangup(struct ofono_voicecall *vc,
ofono_voicecall_cb_t cb, void *data)
{
+ struct voicecall_data *vd = ofono_voicecall_get_data(vc);
+
/* Hangup active call */
- at_template("AT+CHUP", vc, generic_cb, 0x3f, cb, data);
+ if (vd->vendor != OFONO_VENDOR_MOTMDM)
+ at_template("AT+CHUP", vc, generic_cb, 0x3f, cb, data);
+ else
+ at_template("ATH", vc, generic_cb, 0x3f, cb, data);
}
static void clcc_cb(gboolean ok, GAtResult *result, gpointer user_data)
@@ -745,6 +753,8 @@ static void clip_notify(GAtResult *result, gpointer user_data)
GSList *l;
struct ofono_call *call;
+ printf("got clip, searching for incoming calls\n");
+
l = g_slist_find_custom(vd->calls,
GINT_TO_POINTER(CALL_STATUS_INCOMING),
at_util_call_compare_by_status);
@@ -759,7 +769,10 @@ static void clip_notify(GAtResult *result, gpointer user_data)
g_at_result_iter_init(&iter, result);
- if (!g_at_result_iter_next(&iter, "+CLIP:"))
+ printf("Got clip...\n");
+
+ if (/* !g_at_result_iter_next(&iter, "+CLIP:") && */
+ !g_at_result_iter_next(&iter, "~+CLIP="))
return;
if (!g_at_result_iter_next_string(&iter, &num))
@@ -962,8 +975,7 @@ static void no_carrier_notify(GAtResult *result, gpointer user_data)
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, vc, NULL);
+ send_clcc(vd, vc);
}
static void no_answer_notify(GAtResult *result, gpointer user_data)
@@ -971,8 +983,7 @@ static void no_answer_notify(GAtResult *result, gpointer user_data)
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, vc, NULL);
+ send_clcc(vd, vc);
}
static void busy_notify(GAtResult *result, gpointer user_data)
@@ -984,8 +995,7 @@ static void busy_notify(GAtResult *result, gpointer user_data)
* or UDUB on the other side
* TODO: Handle UDUB or other conditions somehow
*/
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
- clcc_poll_cb, vc, NULL);
+ send_clcc(vd, vc);
}
static void cssi_notify(GAtResult *result, gpointer user_data)
@@ -1063,6 +1073,61 @@ static void vtd_query_cb(gboolean ok, GAtResult *result, gpointer user_data)
vd->tone_duration = duration * 100;
}
+
+static void ciev_notify(GAtResult *result, gpointer user_data)
+{
+ struct ofono_voicecall *vc = user_data;
+ struct voicecall_data *vd = ofono_voicecall_get_data(vc);
+ int strength, ind;
+ GAtResultIter iter;
+ struct ofono_call *call;
+ enum ofono_disconnect_reason reason;
+
+ g_at_result_iter_init(&iter, result);
+
+ printf("Got ciev...\n");
+ if (!g_at_result_iter_next(&iter, "~+CIEV="))
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &ind))
+ return;
+
+ if (ind != 1)
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &strength))
+ return;
+
+ printf("Got ciev 1,%d...: \n", strength);
+
+ switch (strength) {
+ case 7: /* outgoing call starts */
+ printf("Outgoing notification, but ATD should have created it for us\n");
+ break;
+ case 4: /* call incoming ringing */
+ printf("Call ringing\n");
+ call = create_call(vc, 9, 1, CALL_STATUS_INCOMING, NULL, 128, 2);
+ if (call == NULL) {
+ ofono_error("Couldn't create call, call management is fubar!");
+ return;
+ }
+ call->type = 0;
+ vd->flags = FLAG_NEED_CLIP;
+ /* FIXME: we should really do that at +CLIP callback .. when that works */
+ //ofono_voicecall_notify(vc, call);
+ break;
+ case 0: /* call ends */
+ call = vd->calls->data;
+
+ reason = OFONO_DISCONNECT_REASON_REMOTE_HANGUP;
+ if (!call->type)
+ ofono_voicecall_disconnected(vc, call->id, reason, NULL);
+
+ printf("Call ends\n"); break;
+ }
+}
+
+
static void at_voicecall_initialized(gboolean ok, GAtResult *result,
gpointer user_data)
{
@@ -1074,6 +1139,9 @@ static void at_voicecall_initialized(gboolean ok, GAtResult *result,
g_at_chat_register(vd->chat, "RING", ring_notify, FALSE, vc, NULL);
g_at_chat_register(vd->chat, "+CRING:", cring_notify, FALSE, vc, NULL);
g_at_chat_register(vd->chat, "+CLIP:", clip_notify, FALSE, vc, NULL);
+ g_at_chat_register(vd->chat, "~+CLIP=", clip_notify, FALSE, vc, NULL);
+ g_at_chat_register(vd->chat, "~+CIEV=", ciev_notify, FALSE, vc, NULL);
+
g_at_chat_register(vd->chat, "+CDIP:", cdip_notify, FALSE, vc, NULL);
g_at_chat_register(vd->chat, "+CNAP:", cnap_notify, FALSE, vc, NULL);
g_at_chat_register(vd->chat, "+CCWA:", ccwa_notify, FALSE, vc, NULL);
@@ -1093,7 +1161,8 @@ static void at_voicecall_initialized(gboolean ok, GAtResult *result,
ofono_voicecall_register(vc);
/* Populate the call list */
- g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix, clcc_cb, vc, NULL);
+ if (vd->vendor != OFONO_VENDOR_MOTMDM)
+ g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix, clcc_cb, vc, NULL);
}
static int at_voicecall_probe(struct ofono_voicecall *vc, unsigned int vendor,
@@ -1112,12 +1181,18 @@ static int at_voicecall_probe(struct ofono_voicecall *vc, unsigned int vendor,
ofono_voicecall_set_data(vc, vd);
- g_at_chat_send(vd->chat, "AT+CRC=1", NULL, NULL, NULL, NULL);
+ if (vd->vendor != OFONO_VENDOR_MOTMDM) {
+ g_at_chat_send(vd->chat, "AT+CRC=1", NULL, NULL, NULL, NULL);
+ }
g_at_chat_send(vd->chat, "AT+CLIP=1", NULL, NULL, NULL, NULL);
- g_at_chat_send(vd->chat, "AT+CDIP=1", NULL, NULL, NULL, NULL);
- g_at_chat_send(vd->chat, "AT+CNAP=1", NULL, NULL, NULL, NULL);
+ if (vd->vendor != OFONO_VENDOR_MOTMDM) {
+ g_at_chat_send(vd->chat, "AT+CDIP=1", NULL, NULL, NULL, NULL);
+ g_at_chat_send(vd->chat, "AT+CNAP=1", NULL, NULL, NULL, NULL);
+ }
switch (vd->vendor) {
+ case OFONO_VENDOR_MOTMDM:
+ break;
case OFONO_VENDOR_QUALCOMM_MSM:
case OFONO_VENDOR_SIMCOM:
g_at_chat_send(vd->chat, "AT+COLP=0", NULL, NULL, NULL, NULL);
@@ -1127,9 +1202,11 @@ static int at_voicecall_probe(struct ofono_voicecall *vc, unsigned int vendor,
break;
}
- g_at_chat_send(vd->chat, "AT+CSSN=1,1", NULL, NULL, NULL, NULL);
- g_at_chat_send(vd->chat, "AT+VTD?", NULL,
- vtd_query_cb, vc, NULL);
+ if (vd->vendor != OFONO_VENDOR_MOTMDM) {
+ g_at_chat_send(vd->chat, "AT+CSSN=1,1", NULL, NULL, NULL, NULL);
+ g_at_chat_send(vd->chat, "AT+VTD?", NULL,
+ vtd_query_cb, vc, NULL);
+ }
g_at_chat_send(vd->chat, "AT+CCWA=1", NULL,
at_voicecall_initialized, vc, NULL);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
1 year, 2 months
Re: Unsalble cellular connection
by JH
Hi Michael,
On 8/18/19, Michael Nazzareno Trimarchi <michael(a)amarulasolutions.com> wrote:
> Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
> number 5 using ci_hdrc
> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
> idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=3
> Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
> Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
> Technologies MSM
> Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
>
> Here seems that reboot in bootloader mode. I have couple of disconnect
> and reconnect and I don't know if connman
> send some power on/off at command and make this strange behavior. The
> fact that start in bootloader mode can be a power
> issue? can you try to connect using a powered HUB?
I did a couple of restarting ofonod and connmand during the debug, one
or two times power recycling manually, not clear if it was me to cause
those reboot or not.
Like Daniel said, it was unlikely that connman would run reboot, it
might just record some messages from kernel.
Just talked to the hardware engineer, he said who is very concerning
we are using kernel 5.1.0, he said we should use kernel 4.9.123, could
the kernel 5.1.0 cause that issue? Jonas what is your comments?
Let me further clarify it, the issue did not occur very often, it
occurred randomly between hours to many days, that is a big worry, LTE
should be 100% stable.
Thank you.
Kind regards,
- jh
1 year, 2 months
Re: Unsalble cellular connection
by Jonas Bonn
Hi Michael,
Re-adding JH and mailing lists to conversation...
On 19/08/2019 10:00, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Mon, Aug 19, 2019 at 9:51 AM Jonas Bonn <jonas(a)norrbonn.se> wrote:
>>
>>
>>
>> On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
>>> Can be chattering and rush current? Even are you sure that you don't have
>>> some reset our of the ofono service that send an at command that
>>> restart the modem?
>>
>> Just to try to prevent us from going down the wrong rabbit hole here:
>> i) The modem is a QMI device so there are no AT commands being sent
>
> Ok, so the uart used as ttyUSB0 and ttyUSB1 they don't support any AT command?
> Is qmi part only the network interface?
ttyUSB0 and ttyUSB1 _do_ support AT commands, but are complementary to
the QMI interface which is a complete communication channel to the modem
in itself. The network interface is _only_ for the QMI channel: the
network packets are carried on a dedicated endpoint of the USB interface
supporting QMI.
I think the question of QMI vs AT is moot here. Internally the modem
does pretty much the same thing; it's just the interface that looks a
bit different.
In JH's case, only the 'qmimisc' device and the 'network' interface are
in play via ofono. These are separate endpoints on a single USB
interface, all managed by the qmi-wwan driver in the kernel.
/Jonas
1 year, 2 months
Re: Unsalble cellular connection
by Jonas Bonn
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
> Hi
>
> On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn <jonas(a)norrbonn.se> wrote:
>> The kernel log has this:
>>
>> Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
>> Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
>> converter now disconnected from ttyUSB0
>> Aug 17 08:51:46 solar kernel: option 1-1:1.0: device disconnected
>> Aug 17 08:51:46 solar kernel: option1 ttyUSB1: GSM modem (1-port)
>> converter now disconnected from ttyUSB1
>> Aug 17 08:51:46 solar kernel: option 1-1:1.2: device disconnected
>> Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status
>> received: -71
>>
>> That's a USB communication failure!
>>
>> Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
>> Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback -
>> usb_submit_urb failed with result -19
>> Aug 17 08:51:46 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister
>> 'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device
>>
>> Below, the device (modem) is reenumerated, which would indicate to me
>> that it has restarted. I don't think the kernel automatically sends a
>> reset to a device on comm failures...??? This explains the
>> communication failure, at least.
>
> Can be chattering and rush current? Even are you sure that you don't have
> some reset our of the ofono service that send an at command that
> restart the modem?
Just to try to prevent us from going down the wrong rabbit hole here:
i) The modem is a QMI device so there are no AT commands being sent
ii) The ofono log should show any such command if it were being
transmitted (unfortunately, JH hasn't been able to produce a proper log
around this event, yet)
iii) I'm pretty certain that the QMI (gobi) driver in ofono doesn't
support any 'reset' command
My inclination would be to look elsewhere.
i) figure out what reset signalling the modem does and put a scope on it.
ii) try to eliminate ofono and connman from the picture entirely by
running the modem manually... what's the utility called, qmictl? comes
with libqmi, in any case. Presumably, if it's a hardware issue, the
problem will show itself under these circumstances, as well.
/Jonas
>
> Michael
>
>>
>> Aug 17 08:51:49 solar kernel: usb 1-1: new high-speed USB device number
>> 4 using ci_hdrc
>> Aug 17 08:51:50 solar kernel: usb 1-1: New USB device found,
>> idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
>> Aug 17 08:51:50 solar kernel: usb 1-1: New USB device strings: Mfr=3,
>> Product=2, SerialNumber=4
>> Aug 17 08:51:50 solar kernel: usb 1-1: Product: Qualcomm CDMA
>> Technologies MSM
>> Aug 17 08:51:50 solar kernel: usb 1-1: Manufacturer: Qualcomm, Incorporated
>> Aug 17 08:51:50 solar kernel: usb 1-1: SerialNumber: 5ff10299
>> Aug 17 08:51:50 solar kernel: option 1-1:1.0: GSM modem (1-port)
>> converter detected
>> Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now
>> attached to ttyUSB0
>> Aug 17 08:51:50 solar kernel: option 1-1:1.2: GSM modem (1-port)
>> converter detected
>> Aug 17 08:51:50 solar kernel: usb 1-1: GSM modem (1-port) converter now
>> attached to ttyUSB1
>> Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3: cdc-wdm0: USB WDM device
>> Aug 17 08:51:50 solar kernel: qmi_wwan 1-1:1.3 wwan0: register
>> 'qmi_wwan' at usb-ci_hdrc.1-1, WWAN/QMI device, f6:0d:90:fa:af:24
>>
>> ofono should _definitely_ show this device reenumeration in its logs.
>> Why is that not there???
>>
>> -----------------------
>>
>> Subsequently, the kernel log shows:
>>
>> Aug 17 11:32:43 solar kernel: usb 1-1: USB disconnect, device number 4
>> Aug 17 11:32:43 solar kernel: option1 ttyUSB0: GSM modem (1-port)
>> converter now disconnected from ttyUSB0
>> Aug 17 11:32:43 solar kernel: option 1-1:1.0: device disconnected
>> Aug 17 11:32:43 solar kernel: option1 ttyUSB1: GSM modem (1-port)
>> converter now disconnected from ttyUSB1
>> Aug 17 11:32:43 solar kernel: option 1-1:1.2: device disconnected
>> Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: nonzero urb status
>> received: -71
>>
>> Again, comm error.
>>
>> Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
>> Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3: wdm_int_callback -
>> usb_submit_urb failed with result -19
>> Aug 17 11:32:44 solar kernel: qmi_wwan 1-1:1.3 wwan0: unregister
>> 'qmi_wwan' usb-ci_hdrc.1-1, WWAN/QMI device
>>
>> Modem has rebooted and is reenumerated below.
>>
>> Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device number
>> 5 using ci_hdrc
>> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
>> idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
>> Aug 17 11:32:45 solar kernel: usb 1-1: New USB device strings: Mfr=1,
>> Product=2, SerialNumber=3
>> Aug 17 11:32:45 solar kernel: usb 1-1: Product: QHSUSB__BULK
>> Aug 17 11:32:45 solar kernel: usb 1-1: Manufacturer: Qualcomm CDMA
>> Technologies MSM
>> Aug 17 11:32:45 solar kernel: usb 1-1: SerialNumber: 5ff10299
>> Aug 17 11:32:45 solar kernel: option 1-1:1.0: GSM modem (1-port)
>> converter detected
>> Aug 17 11:32:45 solar kernel: usb 1-1: GSM modem (1-port) converter now
>> attached to ttyUSB0
>>
>> Here, however, the modem isn't booting up into normal operational state,
>> but rather into some other configuration that, presumably, is intended
>> for doing device firmware updates...
>>
>> So you have a couple of things to figure out:
>> i) Why is the modem restarting (crashing) spontaneously?
>> ii) What are the conditions for entering the bootloader/firmware update
>> state? How are you managing to meet these conditions?
>> iii) Why is ofono not showing the device reenumeration... it should,
>> and it should show the modem being taken down and brought back up again.
>> (I suspect it's just a matter of your logs being out of sync... it's
>> probably there if you look, again).
>>
>>>
>>> Let me further clarify it, the issue did not occur very often, it
>>> occurred randomly between hours to many days, that is a big worry, LTE
>>> should be 100% stable.
>>
>> The issue doesn't seem to have anything to do with the radio link. The
>> LTE is probably stable; the issue lies elsewhere.
>>
>> /Jonas
>>
>>>
>>> Thank you.
>>>
>>> Kind regards,
>>>
>>> - jh
>>>
>
>
>
1 year, 2 months
Re: Unsalble cellular connection
by Jonas Bonn
CC: ofono mailing list.
Please don't drop the mailing list from the conversation.
On 13/08/2019 13:51, JH wrote:
> Hi Jonas,
>
> On 8/13/19, Jonas Bonn <jonas(a)norrbonn.se> wrote:
>> Hi JH,
>>> Aug 01 08:09:39 connmand[181]: wwan0 {add} route 0.0.0.0 gw
>>> 10.114.23.146 scope 0 <UNIVERSE>
>>> Aug 01 08:09:45 connmand[181]: Online check failed for 0xa71cf8 Telstra
>
>> Online check failed... was the network connection ever working?
>
> Yes, it usually in good LTE connection when power up, then it dropped
> connection in about 1 - 2 hours.
>
>>> Aug 01 09:34:11 connmand[181]: Time request for server 10.114.23.146
>>> failed (101/Network is unreachable)
>
>> Is this attempt to check the time server causing the modem to discover that the connection
>> isn't working? Who sets the network interface DOWN here... the QMI Linux driver? Why
>> doesn't the modem signal something on the QMI communication channel when this
>> happens... maybe it does but the message is just being silently ignored?
>
> $ ping 10.114.23.146
> --- 10.114.23.146 ping statistics ---
> 5 packets transmitted, 0 packets received, 100% packet loss
>
> Cannot reache that IP address??
That address is the gateway address for that link... there's unlikely a
timeserver running there. Why does connman think there's a timeserver
there?
>
>> There's very little traffic on the link... is the PDP context silently expiring due to inactivity?
> > What happens if you ping something every minute or so when the link
> is active?
>
> That because all traffic went to WiFi, the application is sending a
> message to Cloud every minitue, should that be better than to ping?
So you have no traffic over the LTE link? How do you know that it goes
down after 1-2 hours... maybe it went down after 5 minutes?
Cloud messages are as good as a ping... a packet's a packet.
>
>>> Aug 01 09:34:11 connmand[181]: wwan0 {del} address 10.114.23.145/30 label wwan0
>>> Aug 01 09:34:11 connmand[181]: Skipping disconnect of
>>> /ubloxqmi_0/context1, network is connecting.
>
>> Here I think ofono and connman just get out of sync because connman seems to know that
>> the network is down while ofono doesn't...
>
> Does that alude it is not the ofono caused link down?
The link is configured by connman, not ofono. ofono just publishes the
address details so that connman can set it up.
>
>> Sure... there's not much to go on in the logs you've posted, just an
>> assertion that the LTE connection was silently dropped. It would be
>> better if you could show the behaviour with more complete debug output:
>>
>> ofonod -d
>>
>> The issue could be (perhaps) that there's a QMI message that ofono
>> doesn't handle and is silently ignoring... dumping the QMI communication
>> might useful:
>>
>> OFONO_QMI_DEBUG=1 ofonod -d
>
> Before running following commands, the LTE connection dropped, after
> running following commands, LTE connection came back, it is wired that
> the LTE is more stable than running by system service where
> ExecStart=/usr/sbin/ofonod -u", LTE connection has not been dropped
> for more than 6 hours, I'll run it over night and let you know if the
> connection will be dropped or not. Why running OFONO_QMI_DEBUG=1
> ofonod -d makes it more stable? Can I say that LTE drop off is caused
> by the ofono?
>
> # systemctl stop ofono
> # OFONO_QMI_DEBUG=1 ofonod -d
> # ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 3: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
> link/ether d4:ca:6e:64:e3:61 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.101/24 brd 192.168.0.255 scope global mlan0
> valid_lft forever preferred_lft forever
> inet6 fe80::d6ca:6eff:fe64:e361/64 scope link
> valid_lft forever preferred_lft forever
> 4: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast q0
> link/[65534]
> inet 10.114.34.107/29 brd 10.114.34.111 scope global wwan0
> valid_lft forever preferred_lft forever
>
> The LTE connection came up with IP address:
>
> wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0
> inet addr:10.114.34.107 P-t-P:10.114.34.107 Mask:255.255.255.248
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:253 errors:0 dropped:0 overruns:0 frame:0
> TX packets:348 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:28788 (28.1 KiB) TX bytes:37777 (36.8 KiB)
>
>
> There is not much about the dump message:
>
> # journalctl -u ofono
> -- Logs begin at Fri 2019-07-05 05:07:43 UTC, end at Tue 2019-08-13 09:15:10 UT-
> Aug 11 12:07:12 systemd[1]: Starting Telephony service...
> Aug 11 12:07:13 ofonod[189]: oFono version 1.24
> Aug 11 12:07:14 systemd[1]: Started Telephony service.
> Aug 11 12:07:19 ofonod[189]: Interface org.ofono.AllowedAccessPoints not t
> Aug 11 12:07:21 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:30:19 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:32:24 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:33:28 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:56:03 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:56:06 ofonod[189]: LTE attach IP type: 0
> Aug 12 06:56:10 ofonod[189]: LTE attach IP type: 0
> Aug 13 08:49:09 ofonod[189]: Terminating
> Aug 13 08:49:09 systemd[1]: Stopping Telephony service...
> Aug 13 08:49:09 ofonod[189]: Exit
> Aug 13 08:49:09 systemd[1]: Stopped Telephony service.
> Aug 13 08:56:22 systemd[1]: Starting Telephony service...
> Aug 13 08:56:22 ofonod[3315]: oFono version 1.24
> Aug 13 08:56:22 ofonod[3315]: Unable to hop onto D-Bus: Name already in ue
> Aug 13 08:56:22 ofonod[3315]: Exit
> Aug 13 08:56:22 systemd[1]: Started Telephony service.
> Aug 13 08:57:29 systemd[1]: /lib/systemd/system/ofono.service:8: Executab"
> Aug 13 09:00:30 systemd[1]: Starting Telephony service...
> Aug 13 09:00:30 systemd[1]: Started Telephony service.
>
>>>> # ofono/test/list-contexts
>>>> [ /ubloxqmi_0 ]
>>>> [ /ubloxqmi_0/context1 ]
>>>> Name = Internet
>>>> Type = internet
>>>> AuthenticationMethod = chap
>>>> Settings = { Method=static Gateway=10.116.103.22
>>>> Netmask=255.255.255.25}
>>
>> No Address? No Interface? Running ofono with debug output will
>> probably shed some light on what's going on here.
>
> I think that could be because I only ran it once, if I ran
> list-contexts 4 times consecutively, every time it displayed different
> results included address and interface, is it the normal behaviour of
> list-contexts?
Sounds broken...???
>
> # /usr/lib/ofono/test/list-contexts
> [ /ubloxqmi_0 ]
> [ /ubloxqmi_0/context1 ]
> AuthenticationMethod = chap
> Active = 1
> Protocol = ip
> Username =
> Name = Internet
> Type = internet
> IPv6.Settings = { }
> Password =
> AccessPointName = telstra.m2m
> Settings = { Gateway=10.114.34.108 Method=static
> Interface=wwan0 Do UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
> Metric:1
> RX packets:253 errors:0 dropped:0 overruns:0 frame:0
> TX packets:348 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:28788 (28.1 KiB) TX bytes:37777 (36.8 KiB)
> main}
>
> # /usr/lib/ofono/test/list-contexts
> [ /ubloxqmi_0 ]
> [ /ubloxqmi_0/context1 ]
> AccessPointName = telstra.m2m
> Protocol = ip
> IPv6.Settings = { }
> Active = 1
> Name = Internet
> Type = internet
> Settings = { Method=static Gateway=10.114.34.108 Netmask=255.255.255.24}
> Password =
> AuthenticationMethod = chap
> Username =
>
> # /usr/lib/ofono/test/list-contexts
> [ /ubloxqmi_0 ]
> [ /ubloxqmi_0/context1 ]
> Type = internet
> AccessPointName = telstra.m2m
> Settings = { Netmask=255.255.255.248 Interface=wwan0 Address=10.114.34.}
> Name = Internet
> Username =
> Password =
> Protocol = ip
> Active = 1
> IPv6.Settings = { }
> AuthenticationMethod = chap
>
>> static is correct. ofono configures the local network interface
>> appropriately for the established context.
>>
>> Given that ofono isn't reporting either an address nor interface above,
>> I wonder what the network interface has been configured to. What do 'ip
>> link' and 'ip addr' show?
>
> Since it is running in good status, debug may not make sense, but I
> include here anyway:
>
> # ip link
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 3: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
> link/ether d4:ca:6e:64:e3:61 brd ff:ff:ff:ff:ff:ff
> 4: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast q0
> link/[65534]
>
> # ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: sit0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
> link/sit 0.0.0.0 brd 0.0.0.0
> 3: mlan0: <BROADCAST,MULTICAST,UP,LOWER_UP8000> mtu 1500 qdisc mq qlen 1000
> link/ether d4:ca:6e:64:e3:61 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.101/24 brd 192.168.0.255 scope global mlan0
> valid_lft forever preferred_lft forever
> inet6 fe80::d6ca:6eff:fe64:e361/64 scope link
> valid_lft forever preferred_lft forever
> 4: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast q0
> link/[65534]
> inet 10.114.34.107/29 brd 10.114.34.111 scope global wwan0
> valid_lft forever preferred_lft forever
>
> I'll send you debug information when it is in bad connection status.
>
> Thank you all for you kind help.
>
> Kind regards,
>
> - jupiter
>
/Jonas
1 year, 2 months