Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
A periodic CLCC polling is started when there is an ongoing multiparty
call and a new call appears in the system. A simple way to reproduce
the crashing scenario is:
1. Place a call.
2. Place a second call.
3. Create a multiparty call with both calls.
4. Place a third call (incoming or outgoing does not matter).
5. Disconnect HFP from the modem.
Within the function ciev_callheld_notify, the AT+CLCC command is also
invoked, thus a new cyclic CLCC polling is started, and it overwrites
the timer resource identifier stored in voicecall_data.clcc_source.
This means that there are several timers doing the CLCC polling, but
only one of those is under control, i.e. it can be removed through its
source identifier, hence a timer source leak.
This has a fatal consequence when the HFP modem is disconnected. The
function hfp_voicecall_remove stops the timer that is under control
before freeing the voicecall_data struct. However there are other timers
that are still active and will execute its handler poll_clcc afterwards.
Inside poll_clcc the driver_data is accessed, which is already NULL.
A solution for this is to avoid starting a CLCC polling if there is
already one active, i.e. clcc_source is not 0. By doing this the
uncontrolled timers will not cycle forever.
|
|
|
|
According to the standard "3GPP 27.007 v6.8.0" Appendix C.2.11,
when sending multiple DTMF characters, these must go in individual
+VTS commands for each tone. This adopts the AT modem approach.
Before: AT+VTS=1234\r
After: AT+VTS=1;+VTS=2;+VTS=3;+VTS=4\r
|
|
|
|
To be more consistent with others in the same file
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
INCOMING calls are not affected by UDUB, only by +CHUP.
|
|
The affected call types for +CHUP were set to only ACTIVE calls.
Instead the affected set should include INCOMING, DIALING, ALERTING and
ACTIVE calls.
Thanks to Ionut Dediu for the diagnosing and reporting this issue.
|
|
|
|
|
|
We must tell we want the signal strength reporting using
AT+AUTOCSQ command (ref. "SIM5215_SIM5216_ATC_V1.18.pdf - §10.7").
|
|
Use mode=1 otherwise it fails (ref. "SIM5215_SIM5216_ATC_V1.18.pdf - §6.9")
|
|
The SIM900 module from SIMCOM does have a AT+CGDATA command.
However, it is not possible to make a ppp connection when CGDATA
has been used to bring up the gprs context.
This patch adds a quirk that uses the alternative ATD*99***<cid>#
command instead.
|
|
|
|
|
|
This patch adds echo canceling and noise reduction implementation to
hfpmodem. It adds the implementation to send the command "AT+NREC=0"
to the AG.
|
|
hfp.h should store all HFP related definitions.
|
|
Before, the AT+BAC command was being sent with fixed information,
now we send the command (that inform the AG of the codecs supported by
the HF) with the codecs supported by the registered Handsfree Audio
Agent.
|
|
|
|
SIM is busy right after pin is entered. Use the quirk which
add a CPIN? pooling check until having "CPIN: READY" answer.
|
|
This patch fixes segmentation fault when the network registration
watch is called without being initialized. CIEV GAtChat callback can
be called before ofono_netreg_register().
==15101== Invalid read of size 8
==15101== at 0x492B56: ofono_netreg_register (network.c:2073)
==15101== by 0x47245E: hfp_netreg_probe (network-registration.c:311)
==15101== by 0x492A8D: ofono_netreg_create (network.c:1881)
==15101== by 0x4849D5: hfp_pre_sim (hfp_hf_bluez5.c:288)
==15101== by 0x48C486: ofono_modem_set_powered (modem.c:1194)
==15101== by 0x484E9D: slc_established (hfp_hf_bluez5.c:85)
==15101== by 0x4702AD: chld_cb (slc.c:147)
==15101== by 0x440457: at_chat_finish_command (gatchat.c:461)
==15101== by 0x44109F: new_bytes (gatchat.c:532)
==15101== by 0x4433B7: received_data (gatio.c:122)
==15101== by 0x3CBAA47824: g_main_context_dispatch (gmain.c:2539)
==15101== by 0x3CBAA47B57: g_main_context_iterate.isra.23
(gmain.c:3146)
==15101== Address 0x18 is not stack'd, malloc'd or (recently) free'd
|
|
|
|
|
|
Some phones do not send the corresponding call state update (+CIEV)
after a successful release-and-swap operation (AT+CHLD=1).
This has been observed with a Nokia 500, while testing ReleaseAndSwap()
while an active and a held call exist:
ofonod[20414]: > AT+CLCC\r
ofonod[20414]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20414]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20414]: < \r\nOK\r\n
ofonod[20414]: > AT+CHLD=1\r
ofonod[20414]: < \r\nOK\r\n
After this, no +CIEV is received, but the call has been hung up.
The proposed approach to solve this consists of using AT+CLCC, unless
a call release has been received within a specific time period.
The result fixes the problem as can be seen below:
ofonod[20847]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CHLD=1\r
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CLCC\r
ofonod[20847]: < \r\n+CLCC: 1,0,0,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: < \r\n+CIEV: 5,2\r\n
ofonod[20847]: < \r\n+CIEV: 5,0\r\n
|
|
While processing the result of AT+CLCC, process the differences in a way
that disconnections are reported first, then call state changes and
finally new calls.
The goal is to avoid unnecessary transitional states such as two active
calls existing at the same time.
|
|
Define a helper function in order to use foreach statements when
ofono_voicecall_notify() needs to be called.
|
|
Right now, only the mandatory CVSD codec is supported. The mSBC
mandatory codec is "temporarily" not supported.
The spec alows this, HFP 1.6 Spec Section 4.34.1 page 92: "If wide band
speech is supported then the mandatory codec (mSBC) shall be included
unless it is temporarily unavailable."
|
|
|
|
|
|
Especially for Telit HE910 it is not enough to wait for
entering a PIN code.
If we do not wait for #QSS: 3, subsequent commands,
like +CMER will report SIM BUSY and the network registration
atom will be removed as a consequence.
|
|
With commit 6ee21a3fc18460cc12dbddb3b7ec70e941fa4bbc
the usage DECLARE_FAILURE was removed.
|
|
|
|
If device probe and removal happen in short succession, it's possible
that the idle handler registered in the probe function doesn't run before
the device is removed. In this case, the idle handler needs to be
unregistered so that it does not run and try to access the data that's
destroyed during the removal.
|
|
We might have mis-interpreted how 27.007 intends for CBS to work. After
studying the implementation notes of the IMC 6260 modem, the spec intent
made a little bit more sense.
|
|
|
|
|
|
During STK Set Up Call, we have modem-originated calls that do not go
through the core 'Dial' method. Make sure the calls are still detected
in this case.
|
|
in the case of a PIN entry, XSIMSTATE of 7 (Ready to Attach) should
never occur
|
|
|