Re: [PATCH] udevng: Add support for Quectel BG96 modem
by Martin Hundebøll
Hi Sean,
On 11/25/19 9:26 AM, Sean Nyekjaer wrote:
> Signed-off-by: Sean Nyekjaer <sean(a)geanix.com>
No signoff when submitting to ofono.
// Martin
> ---
> plugins/udevng.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/plugins/udevng.c b/plugins/udevng.c
> index 40ed2b02..cc294c94 100644
> --- a/plugins/udevng.c
> +++ b/plugins/udevng.c
> @@ -1790,6 +1790,8 @@ static struct {
> { "quectelqmi", "qcserial", "2c7c", "0121" },
> { "quectelqmi", "qmi_wwan", "2c7c", "0125" },
> { "quectelqmi", "qcserial", "2c7c", "0125" },
> + { "quectelqmi", "qmi_wwan", "2c7c", "0296" },
> + { "quectelqmi", "qcserial", "2c7c", "0296" },
> { "ublox", "cdc_acm", "1546", "1010" },
> { "ublox", "cdc_ncm", "1546", "1010" },
> { "ublox", "cdc_acm", "1546", "1102" },
>
3 weeks, 5 days
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
5 months, 1 week
Extending driver
by Mattias Månsson
In earlier projects we have copied/renamed and extended modem drivers with our own changes in ofono. But now we have a new project where we're thinking of extending the qmimodem driver, but I feel that there must be a nicer way to to this than copy/rename. We probably only want to change a few things and maybe add an extra interface or two. Is there a better way to design this in ofono and only extend the files we want to change?
5 months, 1 week
Option to not power off radio during start ofono
by Richard Röjfors
Hi,
Ofono (at least for ublox) is always powering off the radio during start.
This can of course be handy of programmatic reasons to bring the modem to a
known state.
Some configuration requires the radio to be turned off; for instance the
LTE auto connect APN. But on the other hand these are stored in
non-volatile memory and could be configured before hand.
The big drawback with turning it off is that it might take time to register
again when the radio is on. I have seen it taking more than 10 minutes in
extreme cases.
In embedded systems this can be a big issue.
I'm thinking of adding a configuration option to keep the radio on during
start.
Whats the general thought about this?
BR
--Richard
5 months, 1 week
[PATCH v2] ublox: network-registration: Handle UREG unsolicited during poll
by richard.rojfors＠gmail.com
From: Richard Röjfors <richard(a)puffinpack.se>
In the case a unsolicited indication for UREG was received
while the status was polled. The poll response failed to parse.
This since the unsolicited indication only carries one
parameter, while the poll response is expected to carry two.
Update the code to loop until the response is found.
The log below shows a case where this happened.
10:07:55 ofonod[520]: Aux: > AT+UREG?\r
10:07:55 ofonod[520]: Aux: < \r\n+CGREG: 4\r\n\r\n+UREG: 0\r\n\r\n+CIEV: 9,1\r\n
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_status_notify() /ublox_0 status unknown (4)
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_detached_notify() /ublox_0
10:07:55 ofonod[520]: Aux: < \r\n+UREG: 1,0\r\n
10:07:55 ofonod[520]: Aux: < \r\nOK\r\n
---
drivers/ubloxmodem/network-registration.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/ubloxmodem/network-registration.c b/drivers/ubloxmodem/network-registration.c
index 6a524f47..662453b4 100644
--- a/drivers/ubloxmodem/network-registration.c
+++ b/drivers/ubloxmodem/network-registration.c
@@ -279,7 +279,7 @@ static void ublox_ureg_cb(gboolean ok, GAtResult *result,
struct netreg_data *nd = ofono_netreg_get_data(tq->netreg);
GAtResultIter iter;
gint enabled, state;
- int tech = tq->tech;
+ int tech = -1;
nd->updating_status = false;
@@ -288,21 +288,22 @@ static void ublox_ureg_cb(gboolean ok, GAtResult *result,
g_at_result_iter_init(&iter, result);
- if (!g_at_result_iter_next(&iter, "+UREG:"))
- return;
+ while (g_at_result_iter_next(&iter, "+UREG:")) {
+ if (!g_at_result_iter_next_number(&iter, &enabled))
+ return;
- if (!g_at_result_iter_next_number(&iter, &enabled))
- return;
+ /* Sometimes we get an unsolicited UREG here, skip it */
+ if (!g_at_result_iter_next_number(&iter, &state))
+ continue;
- if (!g_at_result_iter_next_number(&iter, &state))
- return;
+ tech = ublox_ureg_state_to_tech(state);
+ break;
+ }
- tech = ublox_ureg_state_to_tech(state);
+error:
if (tech < 0)
/* No valid UREG status, we have to trust CREG... */
tech = tq->tech;
-
-error:
ofono_netreg_status_notify(tq->netreg,
tq->status, tq->lac, tq->ci, tech);
}
--
2.20.1
5 months, 3 weeks
[PATCH] ublox: network-registration: Handle UREG unsolicited during poll
by richard.rojfors＠gmail.com
From: Richard Röjfors <richard(a)puffinpack.se>
In the case a unsolicited indication for UREG was received
while the status was polled. The poll response failed to parse.
This since the unsolicited indication only carries one
parameter, while the poll response is expected to carry two.
Update the code to loop until the response is found.
The log below shows a case where this happened.
10:07:55 ofonod[520]: Aux: > AT+UREG?\r
10:07:55 ofonod[520]: Aux: < \r\n+CGREG: 4\r\n\r\n+UREG: 0\r\n\r\n+CIEV: 9,1\r\n
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_status_notify() /ublox_0 status unknown (4)
10:07:55 ofonod[520]: src/gprs.c:ofono_gprs_detached_notify() /ublox_0
10:07:55 ofonod[520]: Aux: < \r\n+UREG: 1,0\r\n
10:07:55 ofonod[520]: Aux: < \r\nOK\r\n
---
drivers/ubloxmodem/network-registration.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/ubloxmodem/network-registration.c b/drivers/ubloxmodem/network-registration.c
index 6a524f47..2c6358e3 100644
--- a/drivers/ubloxmodem/network-registration.c
+++ b/drivers/ubloxmodem/network-registration.c
@@ -288,15 +288,21 @@ static void ublox_ureg_cb(gboolean ok, GAtResult *result,
g_at_result_iter_init(&iter, result);
- if (!g_at_result_iter_next(&iter, "+UREG:"))
- return;
+ while (g_at_result_iter_next(&iter, "+UREG:")) {
+ if (!g_at_result_iter_next_number(&iter, &enabled))
+ return;
- if (!g_at_result_iter_next_number(&iter, &enabled))
- return;
+ /* Sometimes we get an unsolicited UREG here, skip it */
+ if (!g_at_result_iter_next_number(&iter, &state))
+ continue;
- if (!g_at_result_iter_next_number(&iter, &state))
- return;
+ goto parsed_state;
+ }
+
+ /* In case we get here, the response was not parsed */
+ goto error;
+parsed_state:
tech = ublox_ureg_state_to_tech(state);
if (tech < 0)
/* No valid UREG status, we have to trust CREG... */
--
2.20.1
5 months, 3 weeks
Re: HSP/HFP ofono bluetooth support for Linux desktop
by Denis Kenzior
Hi Pali,
On 2/13/20 12:32 PM, Pali Rohár wrote:
>> At the time this was all done in software.
>
> CVSD was never done in software. Always in hardware. As said, even now I
> was not able to find bluetooth HW which would allow to do CVSD in software.
>
I don't remember the exact details. I seem to remember that for mSBC
the conversion was being done on the host and no 'on-the-fly' conversion
was done in hardware. Thus this host codec negotiation was not needed /
considered.
https://lists.ofono.org/hyperkitty/list/ofono@ofono.org/message/6CUFGDPUJ...
>> So how do you negotiate the 'AgentCodec'? Does BlueZ expose this
>> information? If so, how? SCO socket option or ...?
>
> It is done by HCI commands, therefore by kernel. There is discussion for
> exporting userspace <--> kernel API to allow setting arbitrary
> configurations for codecs supported by bluetooth HW.
>
> Getting list of supported codecs can be done by this script:
> https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl
> (needs to be run as root)
So you might want to get BlueZ guys to expose this info properly first.
oFono is not in the business of opening raw hci sockets.
>> Isn't the MTU obtained from the SCO socket itself? How is oFono at fault
>> here?
>
> Yes, via some ioctl it can be done. But bluez for other bluetooth
> profiles provides this information via dbus API. As bluez does not
> support HSP/HFP it expects that software which implement it, provide
> needed info
Only PA (or whatever implements the audio agent) really cares about this
info and it can obtain it via getsockopt. So I really don't see why the
MTU should be exposed via D-Bus. And this is why it wasn't. I don't
see an issue here...?
>>
>> This seems to be a kernel / device driver / firmware issue and should be
>> solved at that level.
>
> Why??? It is up to the application which owns SLC socket and this
> application needs to provide API for it. Codecs are negotiated via AT
> commands, so again only HFP / HSP daemon can do it.
So in my opinion it is really up to the kernel to tell us whether a
given hardware supports wideband speech. So any quirks need to go into
the kernel. Then userspace can select the best available codec
automatically without resorting to having the user twiddle some settings.
> So, why should I even consider to use ofono at all? It does not support
> none of above desktop feature, it does not support extended codecs, it
> does not support HSP profile and also it does not support HFP profile
> without physical modem (majority of desktops and laptops).
Your initial proposal wanted to use oFono as some sort of helper for
your daemon, and that is just not going to be accepted by oFono
upstream. I gave you a few alternatives, including how to extend oFono
to do what you want. If you want to roll your own, go for it.
Regards,
-Denis
5 months, 3 weeks
Re: HSP/HFP ofono bluetooth support for Linux desktop
by Denis Kenzior
Hi Pali,
> Used by who? Gateway role is fully broken and client (hfp) role is used
I guess that depends on your perspective. I've already pointed out that
the desktop 'AG' use case was never something we needed to implement.
If you want to fix oFono to do that, great. If you want to write your
own daemon to do this, also great.
> probably only by some power users. Also there is no support for mSBC in
> pusleaudio.
Why is oFono at fault for this? Genuine question. What are the
roadblocks to mSBC support?
>
> So, no, really it is not used.
>
>>> Main objection for handsfree-audio-api.txt is that it does not provide
>>> information about locally used codec and somehow mixes air codec and
>>> local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth
>>> local codec and term "AirCodec" for bluetooth air codec format.
>>
>> Okay. But, just FYI, at the time there was no hw that could do such
>> on-the-fly conversions, so this use case wasn't considered/implemented.
>
> This cannot be truth as probably every bluetooth HW is doing on-the-fly
> conversion between CVSD and PCM. I was not able to find HW which allows
> me to send raw CVSD samples...
At the time this was all done in software. Alternatively, the hardware
was directly wired between the sound card / modem and the bluetooth
chip. So just opening the SCO socket was enough.
>> True. In retrospect we probably should have used strings. But it was
>> assumed that vendor extensions would go via the Bluetooth SIG Assigned
>> Numbers facility. Anyhow, we can always add a 'Register2' method that could
>> take codecs as a string array or a combination of strings & ints. And if
>> Register2 was used, then use 'NewConnection2' with a signature that supports
>> passing in vendor codecs and whatever else that might be needed.
>
> This is still not enough. Audio application (e.g. pulseaudio) need to
> register AgentCodec, not AirCodec. And current API is somehow mixed.
> Audio application needs to know what is the format which bluetooth chip
> sends to userspace (PCM? mSBC? CVSD? PCMA? AuriStream?) and which format
> bluetooth chip expects. I named this AgentCodec.
So how do you negotiate the 'AgentCodec'? Does BlueZ expose this
information? If so, how? SCO socket option or ...?
>>> And also API does not provide socket MTU information or ability to
>>> change/specify which codec would be used.
>>
>> There was no need, we automatically defaulted to using Wide band if
>> available. Third party codecs are a new use case (for oFono HFP), so would
>> require an API extension.
>
> MTU is needed also for mSBC codec if encoding is done in software
> (pulseaudio). Without it, this wide band support in ofono is unusable
> for pulseaudio.
Isn't the MTU obtained from the SCO socket itself? How is oFono at
fault here?
>
> And also API extension for choosing codec. Also for choosing if software
> of hardware encoding would be used. We know that there are lot of broken
> devices in different way and it is really needed for either blacklist
> some codec or switch between hw and sw encoding if something strange
> happen. Without it pulseaudio is not going to support more codes then
> default required (CVSD).
This seems to be a kernel / device driver / firmware issue and should
be solved at that level.
>
>>>
>>> Non-audio APIs which are needed to export (for both HSP and HFP profiles):
>>>
>>> * battery level (0% - 100%)
>>> * power source (external, battery, unknown)
>>> * ability to send "our laptop" battery level and power source to remote device
>>> * send text message to embedded display
>>> * process button press event (exported via linux kernel uinput)
>>>
>>
>> I think all of these are feasible to support under the current oFono
>> structure, either via plugins or API extensions.
>
> Ok. Are you going to implement them?
> I think that all of these are missing parts in ofono and something which
> is needed to be implemented for desktop/laptop HSP and HFP profile
> support.
>
There are no plans to do this at the moment.
Regards,
-Denis
5 months, 3 weeks
Re: HSP/HFP ofono bluetooth support for Linux desktop
by Denis Kenzior
Hi Pali,
On 1/8/20 3:25 PM, Pali Rohár wrote:
> Hello!
>
Somehow this went straight to my Junk folder, so I didn't see this
message at all until now.
>
> Audio application (e.g. pulseaudio) really do not want to handle two
> separate services to monitor and process HSP/HFP devices. >
> For audio application are HSP and HFP devices equivalent, they provide
> same features: SCO socket, API for controlling microphone and speaker
> gain; plus optionally specify used codec.
>
> So having two separate services which fully divided for audio
> application purpose does not make sense.
>
> So it is possible that both HSP and HFP audio cards would be available
> via one audio API? Because I do not see how it could be done via design
> like dundee.
>
One API sure. Maybe on multiple services. Honestly, I don't see why
this would be such a burden for PA to watch 2 dbus services instead of
1. From oFono perspective it would make more sense to keep the HSP part
a separate daemon. I could be convinced otherwise if it is indeed a big
burden for PA...
>> You can then implement the same API interfaces for setting up the HSP audio
>> stream as oFono does today (i.e. https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree...),
>
> This API is unusable for both HSP and HFP audio streams. In pulseaudio
> it is somehow used, but it is not suitable.
>
Funny. "It is used but not suitable"?
> Main objection for handsfree-audio-api.txt is that it does not provide
> information about locally used codec and somehow mixes air codec and
> local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth
> local codec and term "AirCodec" for bluetooth air codec format.
Okay. But, just FYI, at the time there was no hw that could do such
on-the-fly conversions, so this use case wasn't considered/implemented.
There's really no reason why we couldn't extend our APIs to handle this.
>
> Another objection against handsfree-audio-api.txt API is that it is
> bound to HF codecs (via number) and does not support for pass e.g. CSR
> codecs.
True. In retrospect we probably should have used strings. But it was
assumed that vendor extensions would go via the Bluetooth SIG Assigned
Numbers facility. Anyhow, we can always add a 'Register2' method that
could take codecs as a string array or a combination of strings & ints.
And if Register2 was used, then use 'NewConnection2' with a signature
that supports passing in vendor codecs and whatever else that might be
needed.
>
> What is completely missing in that API is controlling volume level.
>
It is there on the CallVolume interface
> And also API does not provide socket MTU information or ability to
> change/specify which codec would be used.
There was no need, we automatically defaulted to using Wide band if
available. Third party codecs are a new use case (for oFono HFP), so
would require an API extension.
>
> Non-audio APIs which are needed to export (for both HSP and HFP profiles):
>
> * battery level (0% - 100%)
> * power source (external, battery, unknown)
> * ability to send "our laptop" battery level and power source to remote device
> * send text message to embedded display
> * process button press event (exported via linux kernel uinput)
>
I think all of these are feasible to support under the current oFono
structure, either via plugins or API extensions.
Regards,
-Denis
5 months, 3 weeks
AuthenticationMethod can't be set to none
by jagernicolas＠legtux.org
Hi,
I have a device with a Quectel EC21 module. I have to make `ofono` working to connect internet using the lte. In the past, another company use `pppd` to connect internet. Using their scripts, I can connect internet when the module is set to avoid authentication (`noauth`). Now I try to do the same with `ofono` (I have no prior knowledge of ofono/connman and even the use of cell module).
According to `connman-api.txt`,
```
string AuthenticationMethod [readwrite]
Holds the PPP authentication method to use. Valid values are "pap", "chap" and "none".
Defaults to "chap".
```
I could set the value of AuthenticationMethod to "pap, "chap" and "none". For example,
```
context.SetProperty("AuthenticationMethod", dbus.String("pap"), timeout = 100)
```
will set the value. but,
```
context.SetProperty("AuthenticationMethod", dbus.String("none"), timeout = 100)
```
I got the following error,
```
org.ofono.Error.InvalidFormat: Argument format is not recognized
```
According to `lte-api.txt`,
```
string AuthenticationMethod [readwrite, experimental]
Sets the Method used for the authentication
for the default APN.
Available values are "none", "pap" and "chap".
Default is "none".
If the AuthenticationMethod is set to 'none',
no authentication is performed for the default attach
APN. Username and Password properties are ignored,
even if containing a valid value. If Username or
Password are empty, AuthenticationMethod is implicitly
assumed to be set to 'none'.
```
we can read that `If Username or Password are empty, AuthenticationMethod is implicitly assumed to be set to 'none'.`. I try that using the `connman-api`, but yet no internet.
Using the `lte-api` don't work much, It seems the field `AuthenticationMethod` is not present. When I print what come from `lte.GetProperties()` I got only the field `DefaultAccessPointName`,
```
DefaultAccessPointName
dbus.Dictionary({dbus.String('DefaultAccessPointName'): dbus.String('', variant_level=1)}, signature=dbus.Signature('sv'))
```
I don't see how I could solve this. Help would be appreciated.
Additionnal informations:
versions:
```
# ofonod -v
1.24
# connmand -v
1.35
```
regards,
5 months, 4 weeks
