SupplementaryServices.Initiate() does not return
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| ofono (Ubuntu) |
High
|
Alfonso Sanchez-Beato |
Bug Description
When I call Initiate() I noticed that I receive the RequestReceived() signal, but Initiate() doesn't actually return. The dbus call remains locked, when I try to Respond() the request, Initiate() is still locked and I get org.ofono.
Cancel() also returns the InProgress error.
Here is the log:
http://
Related branches
Changed in ofono (Ubuntu): | |
importance: | Undecided → High |
assignee: | nobody → Alfonso Sanchez-Beato (alfonsosanchezbeato) |
Changed in ofono (Ubuntu): | |
status: | New → In Progress |
Tony Espy (awe) wrote : | #1 |
Tony Espy (awe) wrote : | #2 |
Also, note as only some networks exhibit the behavior as originally described, this bug is difficult to reproduce.
Normal usage of the ofono USSD test scripts should trigger the bug if the operator's network behaves as described.
Launchpad Janitor (janitor) wrote : | #3 |
This bug was fixed in the package ofono - 1.12.bzr6858+
---------------
ofono (1.12.bzr6858+
[ Tony Espy ]
* [ Tony Espy ] build, gril, rilmodem, plugins/ril, test: call-
forwarding support. [ Alfonso Sanchez-Beato ] build, gril,
plugins/rildev: dynamic plugin loading for ril-type modems. The
new rildev plugin reads an environment variable to determine
which device plugin to load ( defaults to the standard ril
plugin ). build, gril, plugins/ril, rilmodem, unit: radio-settings
support. Allow radio technology ( ie. use 2G-only ) preference to
be configured. [ Tony Espy ] test: update remaining test scripts to
Python 3. build, src, plugins, src/gprs: add MMS support. Added
new android-provision plugin and associated -apndb code to
provision GPRS and MMS contexts using apns-conf.xml as the primary
provisioning database, while mobile-
still queried in order to pickup additional Apns. Also added
support for combined Internet/MMS contexts by allowing MMS
specific properties to be set for OFONO_GPRS_
contexts. [ Alfonso Sanchez-Beato ] rilmodem/ussd: Fix USSD Initiate
hang (LP: #1299227 ). gril, rilmodem, unit: add SIM write support.
This allows ofono's core call-forwarding and message-waiting logic
to update persistent state on the SIM, in order to preserve it
across reboots. build, gril, include, plugins, src,
drivers/
adds support for MTK-ril modems without breaking compatibility
with AOSP-ril modems. examples, include, plugins, src: support for
gid type MVNOs in Android APN database. gril, rilmodem: fix for call
redirections (LP: #1239869). This fix checks and ignores a
Qualcomm specific error code that indicates a call has been re-
directed by an operator while roaming. build, gril, rilmodem,
unit: add call-barring support. gril, mtkmodem, rilmodem, unit: MTK
followup changes. This change adds unit tests for MTK specific
messages. It also consolidates parsing logic for parsing data
call lists, which is a valid payload for multiple message types.
Finally, the deactivate data call logic on start- up has been re-
worked to query the active calls before attempting to deactivate
any. src/smsutil: use UTF-16 instead of UCS-2 (LP: #1269017). If
an incoming SMS is indicated to be UCS-2, use UTF-16 instead to
decode so that emoji's ( which use larger codepoints than can be
encoded in UCS-2 ) are properly decoded. [ Jussi Pakkanen ]
phonesim: add a DBus control interface. This control interface has
been added in order to make phonesime more flexible for auto-pilot
testing of Touch's network-indicator code. [ Alfonso Sanchez-Beato
] android-
all usage of g_str_equal() to g_strcmp0(). This fixes a crash that
may happen if the SIM doesn't contain a SPN file. gril: switch
process to radio user. Te...
Changed in ofono (Ubuntu): | |
status: | In Progress → Fix Released |
The root cause of this bug is as follows:
Initiate() does not return until a USSD notification (event) arrives. Firing the callback moves the state machine of the USSD core so it expects one ON_USSD event to arrive.
In some networks you will receive the ON_USSD event before the reply to SEND_USSD, so if you wait for the SEND_USSD reply to make the callback, the USSD core state machine will not be in the right state and it will not think that the incoming event is related to the previous USSD request, so it will generate a NotificationRec eived/RequestRe ceived signal and Initiate() will still be blocked.
The best way to thing about this is the the ON_UNSOL event is effectively the network reply to the SEND_USSD request.