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
>
2 years, 6 months
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
2 years, 6 months
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.
--
2 years, 6 months
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
2 years, 7 months
Re: [pulseaudio-discuss] Proposal for a new API and usage of
Bluetooth HSP and HFP profiles on Linux
by Denis Kenzior
Hi Pali,
<snip>
>> I think you will need to do this regardless. Otherwise I fail to see how
>> you prevent one 'agent' from consuming AT commands it shouldn't be. This is
>> a possibility you need to consider, whether it happens by accident or
>> maliciously.
>
> Some subset of AT commands are needed to parse and interpret. But not
> telephony commands and having up-to-date internal telephony state.
Please think some more about what I said. You will need to parse every
AT command in your daemon, no way around that. You are right that you
do not need to keep track of the telephony state, but that is besides
the point. So if you need an AT parser anyway, the whole reasoning for
the proposed architecture starts to look shaky.
<snip>
>
>> - The other example is more practical. HFP Service Level Connection (SLC)
>> establishment is actually quite tricky. There are certain limitations on
>> what can and cannot be done prior to SLC establishment, including how audio
>> handling is done.
>
> I know :-) I already implemented prototype implementation to check and
> see how complicated it is and if API make sense and how hard it is for
> agents (audio - pulseaudio) implement and maintain it.
>
>> Unfortunately, codec negotiation, indicator negotiation,
>> and feature negotiation are part of the SLC. oFono already solves all of
>> this and handles all of it nicely.
>
> CSR codecs are not supported nor implemented in ofono. It is more
> complicated as HFP codecs... and needs a new API for audio application.
> Another value which brings my hsphfpd is that it handles these CSR
> codecs and provide API for audio application to use them.
>
Again, you're not addressing my main point. Codec negotiation is part
of SLC establishment. SLC has both telephony and audio aspects.
They're inseparable. Your architecture fails to address this...
CSR codecs are not part of SLC and can be bolted on later. I already
told you that oFono can easily be changed to support this.
>> We have passed all relevant
>> certification testing. It is very unclear how you plan to handle this (or
>> whether you realistically even can) in your architecture when the
>> responsibilities are split between the various daemons. So again, oFono has
>> nothing to gain here...
>
> I was not thinking about certification. It is not something which I
> could do.... And also pulseaudio itself do not have certifications.
So again, no reason for us to get involved :)
Bottom line is there's no value for us in this architecture. If you
want to use the existing oFono APIs, that's fine. But we're not adding
a plugin for taking arbitrary AT commands from some other daemon :)
<snip>
>> Perhaps this can even be solved in oFono itself (since it already does 90%
>> of what you want) by making the modem requirement optional. What we could
>> do for example is to create a dummy modem if an AG connection is requested
>> and no other suitable modems are detected in the system. The resultant AG
>> wouldn't have any call control capability, it could still be used for
>> transferring audio data, battery, etc. If you want to pursue this, we can
>> brainstorm further.
>
> Well, if this would work automatically without any user interaction or
> without special setup, it seems to be usable.
>
> But what is needed from this implementation in ofono? Basically API for
> each functionality designed in hsphfod daemon. And one of it is also
> support for HSP profile (with CSR and Apple extensions).
Start a separate thread on ofono for this. I already gave you hints on
how to solve the 'AG without a real modem' use case. That would seem to
be the biggest 'win' and it should be fairly easy to make this work.
>
> I'm not against for it, but I thought that having functionality which is
> not related to telephony / modem you would not want to see in ofono
> project (like linux uinput layer for button events or API for displaying
> raw text on embedded display; or CSR audio codec negotiation).
>
> So how do you see possibility to have also HSP profile in ofono? So have
> one place which would provide audio API for SCO? Because this is a big
> requirements from audio software side, to not use 4 different APIs to
> access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> profiles.
>
HSP is a separate issue. Maybe we can handle it like the 'dundee'
daemon inside oFono (which handles Bluetooth DUN profile). In other
words have a dedicated daemon for hsp support that reuses the relevant
bits of oFono and maybe exposes the same APIs (i.e the ones documented
in doc/handsfree-audio-api.txt). That would make life for PulseAudio
pretty easy.
Regards,
-Denis
2 years, 7 months
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
2 years, 7 months
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
2 years, 7 months
