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,
1 week, 5 days
org.ofono.AllowedAccessPoints not found on the interface_list
by JH
Hi,
I am running ofono for SARA-R4 Modem, systemd show many following
messages, does it need be concerned?
Interface org.ofono.AllowedAccessPoints not found on the interface_list
Sometimes the LTE was connected but sometime the LTE was not
connected, I try to figure out if there is any issues in ofono or not.
Appreciate your comments.
Thank you.
Kind regards,
- jh
1 week, 5 days
4G LTE connection stability with USB voltage requirement
by JH
Hi,
Apologies for cross posting.
I am running Yocto build image with kernel 4.19.75 on iMX6, the device
uses uBlox SARA-R4 4G LTE modem. I have an LTE connection stability
issue, it could connect to 4G LTE, then the connection was
disconnected between half an hour to an hour randomly, the error
messages were qmi_wwan of qmi_wwan 1-1:1.3: nonzero urb status
received: -71 and qmi_wwan 1-1:1.3: wdm_int_callback - usb_submit_urb
failed with result -19 for errors of EPROTO and ENODEV, many indicated
that kind of errors usually caused by insufficient USB voltage.
To diagnose it, I changed to use a DC regulated power supply to
connect USB voltage from a stable 5V DC regulated power supply, that
did help to stabilize the 4G LTE connection, the device has been
stable to connect to 4G LTE since yesterday (26 January AEST) morning
more than 24 hours which was not able to perform that stability if the
USB connected to a laptop or connected the device internal regulated
DC voltage from AC power supply.
What cannot convince to hardware engineers and what baffling me is
that I am also testing an image built from OpenWrt using network
manager netifd, it did not have LTE connection issue and it could
connect to 4G LTE much stable to use either USB power supply from a
laptop or device internal DC voltage from AC power supply. It does not
make sense if I say to the hardware engineer that device has power
supply issues. Why OpenWrt netifd is much stable than connman / ofono
in the same power supply conditions?
It seems to me there are subtle differences between connman / ofono
and OpenWrt netifd, could the connman / ofono require more rigid
stable USB voltage than OpenWrt netifd? Or could the OpenWrt netifd be
more superior than connman / ofono in terms of 4G LTE connections?
Appreciate your insight comments and advice.
Thank you.
Kind regards,
- jh
3 weeks, 2 days
Re: Why the mwifiex_sdio frequently disconnected and connected?
by JH
Hi Justin,
Thanks for the response.
On 1/25/20, Justin Capella <justincapella(a)gmail.com> wrote:
> I am not familiar with this device or its source, but the negative
> numbers correspond to errors EPROTO and ENODEV, the 34:08:03 seems to
> be off-by-one from the BSSID you connect to...
Right, but I can see the drivers:
# ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jan 25 09:06 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Jan 25 09:06 /dev/ttyUSB1
> It would be helpful to know the kernel version, and model/versions of
> the hardware and firmware-- likely you can get the info by grepping
> dmesg/kmsg for qmi and mwifi. lspci and lsusb -vt might also be useful
> info.
Kernel 4.19.75
# lsusb -vt
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
|__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 4, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 1: Dev 4, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 1: Dev 4, If 3, Class=Vendor Specific Class, Driver=qmi_wwan, 480M
> Seems like the modem is a subsystem of the 1-1:1.0 device that is though.
>
> I have a qmi modem and it changes bConfigurationValue parameter which
> causes it to reset and present different interfaces (qmi vs mbim if i
> recall correctly), perhaps something is making that change...
> ModemManager?
>
> Have a look in /sys/kernel/modules/ there should be some sort of
> *qmi*/parameters/ where you can maybe change the debug flag
> (alternatively you could modinfo qmi_wwan, assuming that is the right
> module, and rmmod it, and modprobe the_qmi-module
> the_debug_parameter=0xfffffff)
I don't have /sys/kernel/modules/ in the Yocto built file system, nor
can I find in my Ubuntu 18 laptop, my system is different from yours.
> Sorry this is sort of a generic response, and I know not the most
> useful, but others would likely benefit from additional info too, and
> time allowing I'll poke around in the code to try and come up with
> some ideas
I changed to connect 5V DC power from a DC power supply, at first, the
error messages continually displayed, then it got more stable. As I
also stopped some applications, not quite sure which one make the
difference. Will have to spend more time to check it.
Thank you.
Kind regards,
- jh
>
> On Fri, Jan 24, 2020 at 5:10 PM JH <jupiter.hce(a)gmail.com> wrote:
>>
>> Hi,
>>
>> I have been running mwifiex_sdio for a uBlox 4G LTE SARA-R4 and Lily
>> WiFi module, it seems that WiFi connection is stable, but the LTE
>> connection is often connected and disconnected.
>>
>> Looking into the kernel messages, there were many messages to
>> disconnect and connect it again every half of an hour. The device did
>> not set IPv6 which is understandably that IPv6: ADDRCONF(NETDEV_UP)
>> link is not ready, but why it often doing mwifiex_sdio mmc0:0001:1:
>> info: successfully disconnected from 34:08:03 and what that means?
>>
>> root@solar:/var/backups# [ 2045.955013] mwifiex_sdio mmc0:0001:1:
>> CMD_RESP: cmd 0x23f error, result=0x2
>>
>> root@solar:/var/backups# [ 2250.000008] mwifiex_sdio mmc0:0001:1:
>> info: successfully disconnected from 34:08:03
>> [ 2250.081497] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
>> [ 2250.206977] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
>> [ 2251.417295] mwifiex_sdio mmc0:0001:1: info: trying to associate to
>> 'JupiterIoT' bssid 34:08:04:12:b1:a2
>> [ 2251.521866] mwifiex_sdio mmc0:0001:1: info: associated to bssid
>> 34:08:04:12:b1:a2 successfully
>> [ 2251.666834] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
>> [ 2251.743352] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error,
>> result=0x2
>>
>>
>> Also, the 4G LTE SARA-R4 uses USB interface and protocol, but it seems
>> to me that mwifiex_sdio managers both LTE and WiFi connections, right?
>>
>> I am currently debugging the LTE connection stability issues, it
>> ofoten connected to LTE, then in half hours or hours randomly, lose
>> the LTE connection. I try to narrow down the cause, whether the USB
>> interface or from mwifiex_sdio caused LTE connection stability. When
>> the LTE lost connection there were following errors which I am not
>> clear if related to the mwifiex_sdio or not. Appreciate your advise
>> and comments to diagnostic the issue and to fix the LTE connection
>> problems.
>>
>> 1019.130834] option 1-1:1.0: device disconnected
>> [ 1019.142012] qmi_wwan 1-1:1.3: nonzero urb status received: -71
>> [ 1019.147909] qmi_wwan 1-1:1.3: wdm_int_callback - 0 bytes
>> [ 1019.153254] qmi_wwan 1-1:1.3: wdm_int_callback - usb_submit_urb
>> failed with result -19
>> [ 1019.228197] option1 ttyUSB1: GSM modem (1-port) converter now
>> disconnected from ttyUSB1
>>
>> Thank you.
>>
>> Kind regards,
>>
>> - jh
>
3 weeks, 5 days
Where are ofono dbus paths for RSRQ and RSRP?
by JH
Hi,
I have been looking for getting RSRQ and RSRP values from ofono dbus
commands, but I could not find much information how to get RSRQ and
RSRP in debus-send commands, which following interface contains RSRQ
and RSRP? And how could I access thos RSRQ and RSRP in debus-send?
dict entry(
string "Interfaces"
variant array [
string "org.ofono.SmartMessaging"
string "org.ofono.PushNotification"
string "org.ofono.MessageManager"
string "org.ofono.LongTermEvolution"
string "org.ofono.NetworkRegistration"
string "org.ofono.ConnectionManager"
string "org.ofono.NetworkMonitor"
string "org.ofono.RadioSettings"
string "org.ofono.MessageWaiting"
string "org.ofono.AllowedAccessPoints"
string "org.ofono.SimManager"
]
Thank you very much for you kind clues.
Kind regards,
- jh
4 weeks
GPRS - SIGABRT after context down - (SIMCOM 7600E)
by Viallard Anthony
Hi,
I have found a problem with ofono and the modem SIMCOM7600E. In a context with
a weak signal, sometimes ofono stops on signal 6 (SIGNAL ABORT).
I use the last version from git (commit
d90cfdd71cb9eb2b533a20e4aea6bbf79e79fd2e). I have some custom patches but it
should not play a role in the problem.
I have a little program that listen dbus signals from ofono and
controls it. The problem always occurs in the same way. A GPRS detach is detected by ofono
and it sends a PropertyChanged signal on org.ofono.ConnectionManager interface with
"Attached" set to false. Right after, the Attached property change to true and a DBUS signal is sent
by ofono. Therefore, my program sends SetProperty DBUS message on org.ofono.ConnectionContext interface with Active set to
true to enable the data connection again. But there, a signal SIGABRT is raised
in ofono. It is the layer DBUS that call abort() because an argument is NULL as you
can see below (in the stack #5, message is 0x0).
---
(gdb) bt
#0 0xb6c7d2e0 in raise () from ./output/staging/lib/libc.so.0
#1 0xb6c776c0 in abort () from ./output/staging/lib/libc.so.0
#2 0xb6c1fa88 in _dbus_abort () at dbus-sysdeps.c:91
#3 0xb6c17964 in _dbus_warn_check_failed (
format=0xb6c266fc "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:275
#4 0xb6c0c550 in dbus_message_new_error (reply_to=reply_to@entry=0x0,
error_name=error_name@entry=0x121086 "org.ofono.Error.Failed", error_message=0xb6c6148c <vsnprintf+132> "",
error_message@entry=0xbedf2688 "Operation failed") at dbus-message.c:1478
#5 0x000fc44c in g_dbus_create_error_valist (message=0x0, name=name@entry=0x121086 "org.ofono.Error.Failed",
format=format@entry=0x149bb8 <__ofono_debug_desc.22176> "", args=..., args@entry=...) at gdbus/object.c:1420
#6 0x000fc46c in g_dbus_create_error (message=<optimized out>, name=name@entry=0x121086 "org.ofono.Error.Failed",
format=0x12109d "Operation failed") at gdbus/object.c:1431
#7 0x000b3438 in __ofono_error_failed (msg=<optimized out>) at src/dbus.c:312
#8 0x000dcd98 in pri_activate_callback (error=0xbedf2b60, data=0x161048) at src/gprs.c:838
#9 0x0007149c in at_cgdcont_cb (ok=0, result=0xbedf2bb8, user_data=0x1602c8) at drivers/atmodem/gprs-context.c:229
#10 0x000a39d4 in at_chat_finish_command (p=p@entry=0x153b90, ok=0, final=final@entry=0x15e1a0 "NO CARRIER")
at gatchat/gatchat.c:459
#11 0x000a4368 in at_chat_handle_command_response (line=<optimized out>, cmd=<optimized out>, p=<optimized out>)
at gatchat/gatchat.c:529
#12 have_line (str=0x15e1a0 "NO CARRIER", p=0x153b90) at gatchat/gatchat.c:600
#13 new_bytes (rbuf=0x14fe18, user_data=user_data@entry=0x153b90) at gatchat/gatchat.c:759
#14 0x000a62e8 in g_at_io_set_read_handler (io=0x153c08, read_handler=read_handler@entry=0xa41c8 <new_bytes>,
---Type <return> to continue, or q <return> to quit---
user_data=user_data@entry=0x153b90) at gatchat/gatio.c:260
#15 0x000a4874 in at_chat_resume (chat=0x153b90) at gatchat/gatchat.c:955
#16 g_at_chat_resume (chat=<optimized out>) at gatchat/gatchat.c:1449
#17 0x00071704 in ppp_disconnect (reason=G_AT_PPP_REASON_PEER_CLOSED, user_data=0x1602c8)
at drivers/atmodem/gprs-context.c:134
#18 0x000ab850 in ppp_dead (userdata=0x166cf8) at gatchat/gatppp.c:108
#19 0xb6e3db84 in g_main_dispatch (context=0x14f038) at gmain.c:3111
#20 g_main_context_dispatch (context=context@entry=0x14f038) at gmain.c:3710
#21 0xb6e3de28 in g_main_context_iterate (context=0x14f038, block=block@entry=1, dispatch=dispatch@entry=1,
self=<optimized out>) at gmain.c:3781
#22 0xb6e3e1f8 in g_main_loop_run (loop=0x150fb8) at gmain.c:3975
#23 0x0001de5c in main (argc=0, argv=0x0) at src/main.c:293
---
With DBG enabled, we can see this in the log:
---
Jan 15 11:01:42 box ofonod[5828]: AT< \r\n+CREG: 2\r\n\r\n+CGREG: 2\r\n
Jan 15 11:01:42 box ofonod[5828]: AT< \r\n+CREG: 5,FFFE,13D6204\r\n\r\n+CGREG: 5,FFFE,9C40\r\n
Jan 15 11:01:42 box ofonod[5828]: src/network.c:ofono_netreg_status_notify() /sim7x00_0 status 2 tech -1 lac -1 ci -1
Jan 15 11:01:42 box ofonod[5828]: src/network.c:current_operator_callback() 0x160c00, 0x153e70
Jan 15 11:01:42 box ofonod[5828]: src/gprs.c:netreg_status_changed() 2 (searching)
Jan 15 11:01:42 box ofonod[5828]: src/gprs.c:gprs_netreg_update() attach: 0, driver_attached: 1
Jan 15 11:01:42 box ofonod[5828]: src/gprs.c:netreg_status_changed() 2 (searching)
Jan 15 11:01:42 box ofonod[5828]: src/gprs.c:gprs_netreg_update() attach: 0, driver_attached: 0
Jan 15 11:01:42 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status searching (2)
Jan 15 11:01:42 box ofonod[5828]: src/network.c:ofono_netreg_status_notify() /sim7x00_0 status 5 tech 7 lac -1 ci -1
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:netreg_status_changed() 5 (roaming)
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:gprs_netreg_update() attach: 1, driver_attached: 0
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status roaming (5)
Jan 15 11:01:43 box ofonod[5828]: AT> AT+CGATT=0\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+CME ERROR: 30\r\n\r\n+CGEV: NW DETACH\r\n
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:gprs_attach_callback() /sim7x00_0 error = 1
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_detached_notify() /sim7x00_0
Jan 15 11:01:43 box ofonod[5828]: AT> AT+COPS=3,2\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\nOK\r\n\r\nNO CARRIER\r\n\r\n+PPPD: DISCONNECTED\r\n
Jan 15 11:01:43 box ofonod[5828]: AT> AT+COPS?\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+COPS: 0,2,"22802",7\r\n\r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: drivers/atmodem/network-registration.c:cops_numeric_cb() Cops numeric got mcc: 228, mnc: 02
Jan 15 11:01:43 box ofonod[5828]: AT> AT+CSQ\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+CSQ: 20,7\r\n\r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: drivers/atmodem/network-registration.c:csq_cb() csq_cb: 20
Jan 15 11:01:43 box ofonod[5828]: src/network.c:ofono_netreg_strength_notify() strength 64
Jan 15 11:01:43 box ofonod[5828]: AT> AT+CGREG?\r
Jan 15 11:01:43 box ofonod[5828]: plugins/udevng.c:remove_device() /sys/devices/virtual/net/ppp0
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+CGREG: 2,5,9C40,13D6204\r\n\r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:registration_status_cb() /sim7x00_0 error 0 status 5
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status roaming (5)
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:gprs_netreg_update() attach: 1, driver_attached: 1
Jan 15 11:01:43 box ofonod[5828]: AT> AT+CLCC\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+CGEV: ME DETACH\r\n
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+CGREG: 2\r\n\r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_detached_notify() /sim7x00_0
Jan 15 11:01:43 box ofonod[5828]: drivers/atmodem/gprs-context.c:at_gprs_detach_shutdown() cid 1
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status searching (2)
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:ofono_gprs_detached_notify() /sim7x00_0
Jan 15 11:01:43 box ofonod[5828]: AT> AT+COPS=3,0\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: AT> AT+COPS?\r
Jan 15 11:01:43 box ofonod[5828]: AT< \r\n+COPS: 0,0,"Sunrise Tele2 IoT",7\r\n\r\nOK\r\n
Jan 15 11:01:43 box ofonod[5828]: drivers/atmodem/network-registration.c:cops_cb() cops_cb: Sunrise Tele2 IoT, 228 02 7
Jan 15 11:01:43 box ofonod[5828]: src/network.c:current_operator_callback() 0x160c00, (nil)
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:netreg_status_changed() 5 (roaming)
Jan 15 11:01:43 box ofonod[5828]: src/gprs.c:gprs_netreg_update() attach: 1, driver_attached: 0
Jan 15 11:01:43 box ofonod[5828]: AT> AT+CGATT=1\r
Jan 15 11:01:44 box ofonod[5828]: AT< \r\n+CGREG: 5,FFFE,9C40\r\n\r\nOK\r\n
Jan 15 11:01:44 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status roaming (5)
Jan 15 11:01:44 box ofonod[5828]: src/gprs.c:gprs_attach_callback() /sim7x00_0 error = 0
Jan 15 11:01:44 box ofonod[5828]: AT> AT+CGREG?\r
Jan 15 11:01:44 box ofonod[5828]: AT< \r\n+CGREG: 2,5,9C40,13D6204\r\n\r\nOK\r\n
Jan 15 11:01:44 box ofonod[5828]: src/gprs.c:registration_status_cb() /sim7x00_0 error 0 status 5
Jan 15 11:01:44 box ofonod[5828]: src/gprs.c:ofono_gprs_status_notify() /sim7x00_0 status roaming (5)
Jan 15 11:01:44 box ofonod[5828]: drivers/atmodem/gprs-context.c:at_gprs_activate_primary() cid 1
Jan 15 11:01:46 box ofonod[5828]: drivers/atmodem/gprs-context.c:ppp_disconnect() Reason: 4
Jan 15 11:01:46 box ofonod[5828]: src/gprs.c:pri_activate_callback() 0x15e760
Jan 15 11:01:46 box ofonod[5828]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type
Jan 15 11:01:46 box ofonod[5828]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 0
Jan 15 11:01:46 box ofonod[5828]: src/gprs.c:pri_activate_callback() 0x15e760
Jan 15 11:01:46 box ofonod[5828]: src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type
---
The line above is the last before ofono gets killed.
I can guess with the log and the code that there is a double hit of pri_activate_callback() whereas there is
only one DBUS request coming from my program (modemd):
---
Jan 15 10:57:06 box modemd[1131]: /sim7x00_0/context1: PPP is up (ipaddr=100.77.207.2)
Jan 15 11:01:42 box modemd[1131]: Network status changed: searching
Jan 15 11:01:43 box modemd[1131]: Network status changed: roaming
Jan 15 11:01:43 box modemd[1131]: packet domain is non-attached
Jan 15 11:01:43 box modemd[1131]: /sim7x00_0/context1: PPP is down (lost packet domain)
Jan 15 11:01:44 box modemd[1131]: packet domain is attached
Jan 15 11:01:44 box modemd[1131]: /sim7x00_0/context1: enabling context...
Jan 15 11:01:46 box modemd[1131]: gprs.c:307 gprs_enable_context() Set 'Active' to '1' failed
Jan 15 11:01:46 box modemd[1131]: gprs.c:636 gprs_sm_conduct() /sim7x00_0/context1: enabling context failed
---
Is there anyone have an idea to explain why this problem occur and how to fix it ?
Best regards,
Anthony V.
--
4 weeks, 1 day
Re: HSP/HFP ofono bluetooth support for Linux desktop
by Denis Kenzior
Hi Pali,
> Do you have a reasonable solution also for second issue?
>
HSP profile has always been a problem child. It isn't really all that
useful as a profile, and given how minimal it is, the right place for it
always seemed to be inside Pulse Audio itself. This is what Marcel & I
agreed upon back about 8-9 years ago anyway.
You are advocating that HSP is still useful, particularly with vendor
extensions. Which is fair enough, but now you have to figure out how
and where to put this support.
As mentioned earlier, one idea you can explore is to create a small
daemon (or maybe it can even be part of ofonod itself) that will handle
HSP client/server roles. See for example the dundee daemon that is part
of ofono.git. dundee handles Bluetooth DUN profile and might be a good
model / starting point for what you're trying to accomplish.
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...),
which would make PulseAudio's job much easier, since the audio stream
aspects would be essentially identical to HFP. If you're part of
oFono's tree, then in theory many implementation aspects could be reused.
If you want to provide some higher-level APIs for external applications,
then HSP specific interfaces (APIs) can be added as needed.
If you decide this is something you want to pursue, then I'm happy to
host this in the oFono tree.
Regards,
-Denis
1 month, 1 week
Re: connman settings for modem APN
by Daniel Wagner
Hi,
On 07.01.20 17:38, nick83ola wrote:
> I have to manage a modem with connman through dbus and I'm willing to
> work on the ofono plugin to add the APN handling but I'm not familiar
> with connman code.
>
> Connman is already creating a ofono internet context by default for
> the modem but it doesn't offer the possibility to configure the APN
> (and user/password) for the connection.
Correct.
> Where you would put the dbus method to set the APN for a particular
> connection?
See oFono documentation on Connection Context.
> I would prefer if possible only to connect to connman not
> connman/ofono.
/*
* The way this plugin works is following:
*
* powered -> SubscriberIdentity or Online = True -> gprs, context ->
* attached -> netreg -> ready
*
* Depending on the modem type, this plugin will behave differently.
*
* GSM working flow:
*
* When a new modem appears, the plugin always powers it up. This
* allows the plugin to create a connman_device. The core will call
* modem_enable() if the technology is enabled. modem_enable() will
* then set the modem online. If the technology is disabled then
* modem_disable() will just set the modem offline. The modem is
* always kept powered all the time.
*
* After setting the modem online the plugin waits for the
* ConnectionManager and ConnectionContext to appear. When the context
* signals that it is attached and the NetworkRegistration interface
* appears, a new Service will be created and registered at the core.
*
* When asked to connect to the network (network_connect()) the plugin
* will set the Active property on the context. If this operation is
* successful the modem is connected to the network. oFono will inform
* the plugin about IP configuration through the updating the context's
* properties.
[...]
I have only a vague memory on this topic, but I think to remember that
oFono will only show the CM if the APN was provisioned in oFono. Maybe I
have false memory on it.
Thanks,
Daniel
1 month, 1 week
How to stop ofono forcing default at+cgdcont?
by JH
Hi,
What is the default setting in ofono for at+cgdcont?
+CGDCONT: 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
I tried to add APN, every time I changed at+cgdcont, it reversed back
to 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0 by ofono?
That is weird, please advise how to fix it.
Thank you.
Kind regards,
- jh
1 month, 2 weeks