This patch adds the initial Handsfree Audio Manager "Register"
method implementation. It adds the parsing of the arguments included
in the message and checks if there is an agent registered already.
Adds the initial implementation of new experimental Handsfree Audio
Manager interface. This patch adds the interface registration and
the declaration of it's methods.
Set Up Call with extra DTMF characters after the phone number should be
set up with only the dialed number. Otherwise we get a sequence like
this:
{VoiceCallManager} [CallAdded] /ifx_0/voicecall01 { LineIdentification =
+012340123456c1c2, Name = , Emergency = False, Multiparty = False,
RemoteHeld = False, State = alerting, RemoteMultiparty = False }
ofonod[32055]: ++++++++ backtrace ++++++++
ofonod[32055]: #0 0x7f6af0ee3b30 in /lib64/libc.so.6
ofonod[32055]: #1 0x4c2466 in __ofono_watchlist_remove_item() at
src/watch.c:57
ofonod[32055]: #2 0x4b5b73 in ofono_sim_remove_spn_watch() at
src/sim.c:2715
ofonod[32055]: #3 0x497c30 in netreg_unregister() at src/network.c:1817
ofonod[32055]: #4 0x4912e1 in __ofono_atom_unregister() at
src/modem.c:277
ofonod[32055]: #5 0x491387 in flush_atoms() at src/modem.c:425
ofonod[32055]: #6 0x4b6cb8 in __ofono_sim_refresh() at src/sim.c:3154
ofonod[32055]: #7 0x4b8c41 in handle_command_refresh() at
src/stk.c:2302
ofonod[32055]: #8 0x4baf0d in
ofono_stk_proactive_command_handled_notify() at src/stk.c:3048
ofonod[32055]: #9 0x46c60f in satn_notify() at
drivers/ifxmodem/stk.c:229
ofonod[32055]: #10 0x7f6af1711455 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #11 0x43e729 in at_chat_match_notify() at
gatchat/gatchat.c:421
ofonod[32055]: #12 0x440da8 in received_data() at gatchat/gatio.c:125
ofonod[32055]: #13 0x441834 in dispatch_sources() at
gatchat/gatmux.c:157
ofonod[32055]: #14 0x441bbd in received_data() at gatchat/gatmux.c:215
ofonod[32055]: #15 0x7f6af173dfc3 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #16 0x7f6af16ef065 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #17 0x7f6af16efd0f in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #18 0x7f6af16efef9 in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #19 0x7f6af16f032f in /usr/lib64/libglib-2.0.so.0
ofonod[32055]: #20 0x48f5f8 in main() at src/main.c:249
ofonod[32055]: #21 0x7f6af0ed04bd in /lib64/libc.so.6
ofonod[32055]: +++++++++++++++++++++++++++
When modem is brought online, then sim removed and re-inserted. We
crash when going online again due to the spn related data-structures not
being initialized properly
When the SIM is being refreshed, we try to access the SIM too fast after
the SIM REFRESH proactive command is received. Instead set the sim atom
into the 'RESETTING' state and wait until the modem driver signals the
sim insertion again.
The spec explicitly mentions continuous or repeatable tones. 02.40 only
mentions the RP-ACK tone as a single tone, all other tones seem to be
repeatable
By default, both stderr and syslog messages go to the systemd journal,
which results in duplicate messages being logged.
Thanks to Vinicius Costa Gomes for pointing out this problem.
src/smsutil.c: In function ‘cbs_decode_text’:
src/smsutil.c:4116:16: error: comparison between signed and unsigned
integer expressions [-Werror=sign-compare]
The previous commit fixed the bug, however performing a linear-search
through the entire tx-queue is quite wasteful. The current usage
pattern is to always modify the entry at the tail of the queue, so
optimize.
GCF test cases 31.2.1.6.1/2 are asking to make a query according a
specific class. The default class is applied in the query form when
no class is specified in the SS code.
Some SIMs contain an EFspn with the contents all set to 'filler'
characters, e.g. 0xFF. We mistakenly do not handle these strings
correctly.
Aug 8 11:40:00 mx31tt01 daemon.info ofonod[622]: Aux: >
AT+CRSM=176,28486,0,0,17\r
Aug 8 11:40:00 mx31tt01 daemon.info ofonod[622]: Aux: < \r\n+CRSM:
144,0,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF\r\n\r\nOK\r\n
Aug 8 11:40:00 mx31tt01 daemon.debug ofonod[622]:
drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 17
Aug 8 11:40:00 mx31tt01 daemon.debug ofonod[622]:
src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 17
Aug 8 11:40:00 mx31tt01 daemon.err ofonod[622]: EFspn read
successfully, but couldn't parse
ofonod[13066]: src/stk.c:stk_select_item()
ofonod[13066]: src/stk.c:stk_select_item()
ofonod[13066]: src/stk.c:stk_send_envelope()
ofonod[13066]: drivers/qmimodem/stk.c:qmi_envelope()
ofonod[13066]: src/stk.c:envelope_cb() length 0
ofonod[13066]: src/stk.c:menu_selection_envelope_cb()
ofonod[13066]: Sending Menu Selection to UICC failed
process 13066: arguments to dbus_message_new_error() were incorrect,
assertion "reply_to != NULL" failed in file dbus-message.c line 1333.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
ofonod[13066]: Aborting (signal 6) [./src/ofonod]
ofonod[13066]: ++++++++ backtrace ++++++++
Indicators should not be updated if:
- multiple separate calls are active at same time
- a conf call and a call are active at same time
- multiple separate calls are held at same time
- a conf call and a call are held at same time
- a conf call has call in active and held state
Due to how the quiescent behavior of conditional call forwarding rules
when CFU is active, do not allow the user to try and set conditional
rules. This will fail at the network level anyway.
==29809== Conditional jump or move depends on uninitialised value(s)
==29809== at 0x4E826C: stk_file_iter_next (stkutil.c:212)
==29809== by 0x4E8CF8: parse_dataobj_file_list (stkutil.c:635)
==29809== by 0x4EBA29: parse_dataobj (stkutil.c:2410)
==29809== by 0x4ECFB5: parse_refresh (stkutil.c:2971)
==29809== by 0x4EECA3: parse_command_body (stkutil.c:3826)
==29809== by 0x4EF0DF: stk_command_new_from_pdu (stkutil.c:3948)
==29809== by 0x4D50DA: ofono_stk_proactive_command_handled_notify
(stk.c:2885)
In a somewhat bizarre case, both PNN and OPL might change, which will
trigger sim_pnn_opl_changed twice. This can have some funny
side-effects, so don't allow this to happen in the first place.
If both EFspn and EFspdi are changed, then we trigger reading of EFspn
twice which leads to a memory leak. Instead, always read EFspdi if the
relevant service is available.
If EFspdi is changed, use a simple heuristic to update the 'Name'
property if appropriate. This heuristic is not always correct, but in
the worst case we will emit the same name.
HFP does not implement HangupAll natively and most AGs do not support
releasing held calls by id. Work around this by using hangup active and
then dropping all held calls if no waiting calls exist. Otherwise
fall back to releasing calls by id.
If we have a single held call, then it should be possible to hang it up
with 'Hangup' even if active calls exist. Only if multiple held calls
or a waiting call exists should we disallow the request due to possible
side-effects.
Some hardware returns an empty mcc/mnc operator during an operator scan
when no operators are found (e.g. on an LTE dongle in a non-LTE area).
This results in oFono mistaking trying to update a non-existent operator
object.
For reference:
ofonod[27532]: Device: < \r\n+NWSTATEIND: 4\r\n\r\n+COPS:
(0,"","","",255),,(0-4),(0-2)\r\n\r
\nOK\r\n
process 27532: arguments to dbus_message_new_signal() were incorrect,
assertion "_dbus_check_
is_valid_path (path)" failed in file dbus-message.c line 1289.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
For handled commands, in case the terminal response is not reported by
the modem, we must set the cancel_cmd variable so the command is
canceled properly.
This patch also modifies the behavior so that pending_cmd is freed,
since stk_proactive_command_cancel expects cancel_cmd to be set if
pending_cmd is not NULL.
Fix PTS test TP/TWC/BV-03-I [Call Waiting- Hold Active/Retrieve
Waiting Call or Held].
PTS test fails after receiving intermediate update of callheld indicator
with value 0 (no held call) before it receives update to value 1
(active and held calls). This is due to the non-atomic update of calls
status after call swap (moving first call to active state before moving
second one to hold state).
HFP 1.5 spec specifies that an update of callheld indicator to 1 should
be sent after AT+CHLD=2 command.
As oFono emulator sends +CIEV only if the indicator value changes, we
need to use an intermediate state for callheld indicator (2, all calls on
hold).
So, in case of multiple active calls, or an active call with an active
mutiparty call, force update of callheld indicator to 2.
It is not safe to call dial_request_user_cancel directly. This is
because there might be a situation where the SIM requested the calls to
be dropped first. If we're still executing the release_all_active
request and someone calls hangup -> crash.
Instead it is safer to throttle the hangup requests until the call is
actually dialing.
In similar fashion, we should not allow hanging up a specific call if a
dial request is active, unless that call is part of the SIM dial
request. Note that by default this is not known until the driver's dial
implementation returns and the call is in the dialing (or alerting /
connected) state.
Make sure that only a single request from (possibly multiple) emulators
is ever sent to the voicecall driver. In the beginning it wasn't clear
whether this will be necessary, however several command implementations
already implemented basic throttling (+CHUP, ATD, CHLD=3, CHLD=2x) and
it made sense to make this more formal.
The other constraint is the abrupt removal of the emulator atom while an
operation is pending. This case must be handled gracefully. See next
commit.
During test TP/TCA/BV-05-I [Terminate Ongoing Call – While Call Waiting]
PTS fails if multiple +CCWA are sent (waiting for 1st phone number when
waiting one becomes incoming, intead of 2nd phone number).
So, send only 1 +CCWA.
Update RING timer management to be started as soon as an incoming call
exists, and retrieve +CLIP info for incoming or waiting call (in case
of waiting call becoming incoming call, call indicator changes before
internal call status is updated)
Force to send +CCWA (if needed) on reception of AT+CCWA=1
The Send DTMF command is special in its use of DisplayAction method of
STK agent. This allows the user to send a 'User Terminated Session'
response to the SIM. If the user performs this action, then any pending
DTMFs should also be canceled as soon as possible.
respond_on_exit flag is set by commands which are dispatched to the
agent, so that if the agent exits prematurely, a 'User Terminated
Session' response is sent to the SIM.
There were a couple of corner cases not quite handled correctly:
- During Set Up Call, if the user confirmation phase succeeded and the
call was dispatched to voicecall atom successfully, and the agent
exited at this point, then no terminal response would be sent until
the call succeeded / failed. Now the agent termination results in an
'User Terminated Session' response being sent immediately, but the
call setup proceeding.
==20365== Invalid read of size 8
==20365== at 0x4B3501: sim_fs_free (simfs.c:114)
==20365== by 0x493CEC: sim_remove (sim.c:2485)
==20365== by 0x4703D7: modem_change_state (modem.c:410)
==20365== by 0x470664: set_powered (modem.c:848)
==20365== by 0x4706BA: __ofono_modem_shutdown (modem.c:2137)
==20365== by 0x46F2C5: signal_cb (main.c:76)
==20365== by 0x52F555E: g_io_unix_dispatch (giounix.c:166)
==20365== by 0x52A0AAB: g_main_dispatch (gmain.c:2440)
==20365== by 0x52A203B: g_main_context_dispatch (gmain.c:3013)
==20365== by 0x52A2501: g_main_context_iterate (gmain.c:3091)
==20365== by 0x52A2C98: g_main_loop_run (gmain.c:3299)
==20365== by 0x46F0D3: main (main.c:243)
==20365== Address 0x63ff998 is 8 bytes inside a block of size 16 free'd
==20365== at 0x4C2612D: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20365== by 0x52AA4A1: g_free (gmem.c:263)
==20365== by 0x52C433D: g_slice_free1 (gslice.c:907)
==20365== by 0x52C58D0: g_slist_free_1 (gslist.c:192)
==20365== by 0x52C5C5F: g_slist_remove (gslist.c:465)
==20365== by 0x4B342A: sim_fs_context_free (simfs.c:192)
==20365== by 0x4B3500: sim_fs_free (simfs.c:117)
==20365== by 0x493CEC: sim_remove (sim.c:2485)
==20365== by 0x4703D7: modem_change_state (modem.c:410)
==20365== by 0x470664: set_powered (modem.c:848)
==20365== by 0x4706BA: __ofono_modem_shutdown (modem.c:2137)
==20365== by 0x46F2C5: signal_cb (main.c:76)
==20287== Invalid read of size 4
==20287== at 0x52B5C6B: g_queue_peek_nth_link (gqueue.c:704)
==20287== by 0x52B5F57: g_queue_peek_nth (gqueue.c:848)
==20287== by 0x4B33ED: sim_fs_context_free (simfs.c:170)
==20287== by 0x4B34F8: sim_fs_free (simfs.c:116)
==20287== by 0x493CEC: sim_remove (sim.c:2485)
==20287== by 0x4703D7: modem_change_state (modem.c:410)
==20287== by 0x470664: set_powered (modem.c:848)
==20287== by 0x4706BA: __ofono_modem_shutdown (modem.c:2137)
==20287== by 0x46F2C5: signal_cb (main.c:76)
==20287== by 0x52F555E: g_io_unix_dispatch (giounix.c:166)
==20287== by 0x52A0AAB: g_main_dispatch (gmain.c:2440)
==20287== by 0x52A203B: g_main_context_dispatch (gmain.c:3013)
==20287== Address 0x63fae70 is 16 bytes inside a block of size 24
free'd
==20287== at 0x4C2612D: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20287== by 0x52AA4A1: g_free (gmem.c:263)
==20287== by 0x52C433D: g_slice_free1 (gslice.c:907)
==20287== by 0x52B4E96: g_queue_free (gqueue.c:60)
==20287== by 0x4B34E0: sim_fs_free (simfs.c:107)
==20287== by 0x493CEC: sim_remove (sim.c:2485)
==20287== by 0x4703D7: modem_change_state (modem.c:410)
==20287== by 0x470664: set_powered (modem.c:848)
==20287== by 0x4706BA: __ofono_modem_shutdown (modem.c:2137)
==20287== by 0x46F2C5: signal_cb (main.c:76)
==20287== by 0x52F555E: g_io_unix_dispatch (giounix.c:166)
==20287== by 0x52A0AAB: g_main_dispatch (gmain.c:2440)
In certain circumstances, when the image has been cached but EFimg has
not been read yet, we might end up accessing an unitialized variable.
Fix this by always failing if EFimg has not been read yet.