Hi Tony,
The other theory is that maybe the modem stays powered when ofono is re-
started? I've asked Tiago for a way to disable telepathy-ofono across
reboots.
I only see this behaviour on boot. To see what is happening, I add
-d in /etc/init/ofono.override, and to avoid telepathy setting
** Changed in: ofono (Ubuntu)
Assignee: Tony Espy (awe) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
** Branch linked: lp:~alfonsosanchezbeato/ubuntu/saucy/ofono/lp1222106
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
This is a USSD string, which has not been implemented yet.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1195398
Title:
[dialer-app] Is not possible to execute costumer service numbers like
*144#
file is not present, as it is not mandatory for SIM cards.
** Affects: ofono (Ubuntu)
Importance: Undecided
Assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato)
Status: Confirmed
** Attachment added: ofono log from Omer Akram
https://bugs.launchpad.net/bugs/1231320
Fixed in branch
https://github.com/alfonsosanchezbeato/ofono/tree/sim-refactor
A delay in a callback was responsible for the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1208657
Title:
We recently discovered that the number of retries returned when entering
the PIN/PUK is unreliable in the current RIL implementation of Google
devices (Galaxy Nexus and Nexus 4 return always 0 and 1 respectively in
ENTER_SIM_PIN/PUK).
So, for these devices we will never be able to display the
Public bug reported:
After booting a Galaxy Nexus with a SIM with PUK required:
# dbus-send --system --type=method_call --print-reply --dest=org.ofono
/ril_0 org.ofono.SimManager.GetProperties
shows no CardIdentifier property (it should, as this property can be
read regardless of the SIM being
** Description changed:
After booting a Galaxy Nexus with a SIM with PUK required:
# dbus-send --system --type=method_call --print-reply --dest=org.ofono
/ril_0 org.ofono.SimManager.GetProperties
shows no CardIdentifier property (it should, as this property can be
read regardless
The root cause seems to be a problem with the initialization sequence.
Some requests to RIL were getting the error RADIO_NOT_AVAILABLE, being
the reason that RIL_REQUEST_RADIO_POWER(1) had not been called yet. But,
that request was sent when ril_set_online() was called, thing that only
happened
** Description changed:
After booting a Galaxy Nexus with a SIM with PUK required:
# dbus-send --system --type=method_call --print-reply --dest=org.ofono
/ril_0 org.ofono.SimManager.GetProperties
shows no CardIdentifier property (it should, as this property can be
read regardless
After more testing, it seems that this issue affects maguro Galaxy
Nexus, but not mako Nexus 4. In the attached log (comment #5), it can be
seen that all SIM_IO requests are replied with a RADIO_NOT_AVAILABLE
error, until telepathy-ofono sends a RIL_REQUEST_RADIO_POWER. This
behaviour is not
** Attachment added: ofono log on boot (maguro)
https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1245860/+attachment/3895642/+files/log_boot_no_pin.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
The data for the following provider was missing:
country code=pk
...
provider
nameTelenor/name
gsm
network-id mcc=410 mnc=06/
apn value=internet
plan
** Changed in: ofono (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1231320
Title:
GPRS provisioning is broken for old (non-USIM) SIM cards
To manage
This can be at least partially related to bug #1235138 (ubuntu-load-
manager makes DoS attack on ofono)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1226145
Title:
Modem can sometimes take more
I have tested the SIM/PUK behaviour in Galaxy Nexus with Android 4.3,
and it never displays the retry counter of either the PIN or the PUK,
not even when you have entered any of those wrongly at least once.
Interestingly, an old Huwaei phone I have with Android 2.2 prints always
the retry counter.
Fix in feature branch
https://github.com/alfonsosanchezbeato/ofono/tree/fix-
pinrequired/drivers/rilmodem
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1225022
Title:
[ofono][rild] PinRequired
I have seen the same problem with a SIM card that sometimes takes 3
minutes to register, and another that takes 30 seconds. The problem is
that the modem is trying to register first in a network to which the SIM
does not belong. This is triggered whenever ofonod takes a bit longer
than expected to
Feature branch created on github for the fix:
https://github.com/alfonsosanchezbeato/ofono/tree/mnc_length
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1231320
Title:
GPRS provisioning is broken
#6 Change NetworkManager to telepathy-ofono
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1226145
Title:
Modem can sometimes take more than 20s to start
To manage notifications about this bug go
This periodic call to Register is from telepathy-ofono. This has been
removed due to other causes (see bug 1226145), so it would be
interesting to test with the branch proposed there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Maguro is not able to swap between an active call and a held call. To
reproduce the error:
# cd /usr/share/ofono/scripts
# ./dial-number A
# ./dial-number B
In this moment, A must be held and B active
# ./swap-calls
A should be now active and B held. However, this does
** Changed in: ofono (Ubuntu Trusty)
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1195398
Title:
[dialer-app] Support
This actually works with stock images 4.2.2 and 4.3, and with CM 10.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1257206
Title:
Maguro does not swap between active and held call
To manage
Public bug reported:
Asda Mobile APN settings take precedence over Vodafone UK in MBPI. This
happens because both operators have the same (MCC, MNC) tuple and Asda
appears first in serviceproviders.xml.
This is a problem for ofono, as it always takes the first found operator
by default. This
Public bug reported:
Latest version of oFono cannot create a data connection in maguro
(Galaxy Nexus).
** Affects: ofono (Ubuntu)
Importance: Undecided
Status: Confirmed
** Changed in: ofono (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because
** Changed in: ofono (Ubuntu)
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254219
Title:
[rilmodem/gril] If RIL message
The id 6fb7 corresponds to file EF_ECC (emergency call codes). This file
is present in both SIM and USIM applications, but it is of type
Transparent for the SIM while being Linear fixed for the USIM (see
3gpp 51.011 and 31.102).
What is happening is that the core ofono code tries to read that
Public bug reported:
When ofono is stopped (stop ofono), some messages that are supposed to
be sent to rild to clean up resources are not really sent. This happens
due to the asynchronous nature of g_ril_send(): ofono never returns to
glib's main loop after having started the termination stage of
Public bug reported:
I go to Cellular settings, choose carrier as Manually, then press
Carrier and finally press Refresh. After waiting for the refresh to
finish (around one minute or two), no operator is shown.
However, if I use the oFono script
/usr/share/ofono/scripts/scan-for-operators
a
Steps to reproduce added in bug description.
** Description changed:
When ofono is stopped (stop ofono), some messages that are supposed to
be sent to rild to clean up resources are not really sent. This happens
due to the asynchronous nature of g_ril_send(): ofono never returns to
It looks like the logic for this SS is really messed up in some modems.
Network-wise, what I see is:
mako:
test-ss *31# - No line number shown in called phone. Shown status is
disabled.
test-ss #31# - Line number shown in called phone. Shown status is enabled.
maguro:
test-ss *31# - Line
I have been testing this with different SIM cards in mako. scan-for-
operators seems to work. Sometimes I get a timeout, but re-trying with a
bigger timeout works in the end (although you need to wait for the first
request to finish, otherwise the script will return an operation in
progress
I have tried moving from manual to auto using ofono scripts
(/usr/share/ofono/scripts).
Switching back and forth between auto/manual mode with
./test-network-registration default
./test-network-registration /ril_0/operator/op_id
works, and changes get reflected in Cellular page
@Ian
Thanks for debugging this :-)
I was able to reproduce the problem you saw and found the same thing:
the number of operators was 0. Which in fact is what is happening: the
query for available operators sent to RILd is returning an empty list.
That triggered the (misleading) error message
@Tony
The only way that you can be in the auto-only state that produces the
AccessDenied error is because you must have a SIM file called EF_CSP
that apparently has a flag for disabling manual registration. Maybe you
could add a trace at network.c::sim_csp_read_cb() to see if that is the
case. If
@Iain
Is that 4.4 patches + Ubuntu image? That would suggest that it is a rild
or modem FW bug in 4.2.2.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1276699
Title:
scan-for-operator script
** Changed in: ofono (Ubuntu)
Status: New = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1299227
Title:
SupplementaryServices.Initiate() does not return
To manage notifications
Public bug reported:
After installing packages from
https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/
when I reboot once, everything seems fine: NM opens an ofono context and
a connection is established. However, the second time I reboot, NM
crashes and upstart re-starts it
File with ofono contexts that seems to trigger the bug
** Attachment added: gprs
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1316496/+attachment/4106226/+files/gprs
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
syslog attached
** Attachment added: syslog
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1316496/+attachment/4106216/+files/syslog
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: ofono (Ubuntu)
Assignee: Tony Espy (awe) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
** Changed in: ofono (Ubuntu)
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
maguro image #182 has a working data connection
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254746
Title:
Cannot establish a data call in Galaxy Nexus
To manage notifications about this bug go
The problem is caused because urfkilld onlines the modem when ofono's
Powered property switches from 0 to 1. However, depending on race
conditions on boot, Powered can be already 1 when urfkilld register
for changes in ofono properties.
Issue fixed in:
Public bug reported:
The modem is not onlined on boot for MTK-based devices, like the one in
an OEM project. The attached traces contain urfkilld output from syslog.
** Affects: urfkill (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: urfkilld.txt
Public bug reported:
Sometimes the WWAN value in /var/lib/urfkill/saved-states is incoherent
with the flight mode status. Note that in this case we have dual SIM (I
have not tried yet with just one modem, could happen too).
Start with flight mode=0. soft=false in all sections in saved-states.
An interesting line in syslog is:
URfkill[3014]: warning Could not set Online property in oFono: Timeout
was reached
In the case of MTK modem, onlining the modem after powering it on takes
~8 seconds, so probable the timeout has to be increased (maybe to ~20
seconds to be on the safe side).
In fact I did not restart immediately urfkill, I waited for around a
minute and did some checks between each command in the bug description.
The problem is not that the file is written just on shutdown, although I
would argue that it makes sense to write it each time the user modifies
a setting,
Fix commited in our ofono github repo
https://github.com/rilmodem/ofono/commit/d80b7c1833804698bbce8c2e4b7dab32b158938e
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1211804
Title:
Cell data
Full trace:
http://paste.ubuntu.com/7405345/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1316496
Title:
NM crash when testing MMS silo
To manage notifications about this bug go to:
The problem happens due to lack of support for UCS-2 strings for USSD in
rilmodem.
** Changed in: ofono (Ubuntu)
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
Fixed in github PR
https://github.com/rilmodem/ofono/pull/83
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1314143
Title:
USSD reply is empty
To manage notifications about this bug go to:
** Changed in: ubuntu-system-settings
Assignee: Tony Espy (awe) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1211804
Title:
Cell data technology
** Changed in: ubuntu-system-settings
Assignee: Alfonso Sanchez-Beato (alfonsosanchezbeato) = (unassigned)
** Changed in: ofono (Ubuntu)
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs
The emojis are have code points wider than 16 bits, so they cannot be
code using UCS-2. UTF-16 is being used instead, and the emojis are coded
using surrogate pairs. Code to use UTF-16 in ofono instead of UCS-2 can
be found in this PR:
https://github.com/rilmodem/ofono/pull/76
--
You received
@Matthew I have an idea of what might be happening, but I need traces to
confirm. Please do as follows (I assume we are talking about Nexus 4
here):
$ phablet-shell
$ sudo su
# stop ofono
# export OFONO_RIL_HEX_TRACE=
# export OFONO_RIL_TRACE=
# ofonod -n -d -P
Finally I managed to get traces of a successful MMS send. I used Nexus 4
flashed with Android 4.4.4, cyanogenmod.
** Attachment added: dump.pcap
https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1349299/+attachment/4206051/+files/dump.pcap
--
You received this bug notification because
** Changed in: nuntium (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349299
Title:
Cannot send MMS, pepephone operator
To manage notifications about
** Changed in: ofono (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1368675
Title:
No Wi-Fi on Nexus 4
This PR contains a fix for ofono:
https://github.com/rilmodem/ofono/pull/87
With the fix Status is now denied, as can be seen in list-modems
output from Matthew:
https://pastebin.canonical.com/117079/
However, Matthew still sees issues with the WiFi indicator, but
indicator-network does not
tcpdump for MMS sent from hangouts, as requested by Sergio.
** Attachment added: hangouts.pcap
https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1349299/+attachment/4206243/+files/hangouts.pcap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@Tony, the crash was because Status property was an empty string (it
was not unknown or anything else), which is wrong as specified by
ofono/doc/network-api.txt. And it was an actual ofono bug, as we were
getting a value for state from rild that was not valid for ofono core.
--
You received this
** Attachment added: mms_new_nuntium.pcap
https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1349299/+attachment/4212133/+files/mms_new_nuntium.pcap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Unfortunately, all 3 combinations failed. I have attached below the
corresponding tcpdump traces for the 3 cases.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349299
Title:
Cannot send MMS,
** Attachment added: mms_new_nuntium_jfif.pcap
https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1349299/+attachment/4212134/+files/mms_new_nuntium_jfif.pcap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Attachment added: mms_jfif.pcap
https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1349299/+attachment/4212132/+files/mms_jfif.pcap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349299
A PR with a fix can be found at
https://github.com/rilmodem/ofono/pull/123
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1374029
Title:
RadioSettings interface is not created some times
To manage
Public bug reported:
In some occasions the RadioSettings interface is not exposed by ofono.
When this happens, the command
# /usr/share/ofono/scripts/list-modems | grep RadioSettings
produces no output.
Additionally, the following message appears in syslog:
ril_delayed_register: cannot set
Right, it is MTK specific.
phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 57
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2014-09-22 10:15:10
version version: 57
version ubuntu: 20140923.1
version device: 20140919-1b3e670
version custom:
Public bug reported:
Doing:
# offline-modem /ril_0
# online-modem /ril_0
crashes ofono. This happens only if the other modem is online all the
time, so this does not really affect flight mode, which onlines/offlines
both modems at the same time.
phablet@ubuntu-phablet:~$ system-image-cli -i
@Tony, sorry, I forgot to link the PR, this already has a proposed
solution:
https://github.com/rilmodem/ofono/pull/125
** Changed in: ofono (Ubuntu)
Assignee: Tony Espy (awe) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member
First, as Pat commented there has been some confusion in the bug between
actions:
Enter PIN - Enter PIN after modem reboot to be able to use the phone
Unlock PIN - Deactivate PIN so no PIN needs to be entered after modem reboot
For both actions you need to use the current PIN. Maybe some
@Víctor, @Tony:
Regarding roaming, there are already mechanisms that check the content
of SIM files and the registered network that should prevent the
registration state to be roaming, even in these cases when we bounce
between different networks.
Víctor, could you please check if you see a
@Tony:
I am not sure this is really an issue. When operators have roaming
agreements, they add the right content to SIM files so the modem/phone
can detect whether the phone is really roaming or not. ofono already
checks the content of these files to prevent the network status be
roaming when it
I have just noticed that the output of monitor-ofono is part of the
logs, and I see that network status actually gets into roaming state.
But, it is in very short time windows:
2014-09-26 20:11:18,643 {NetworkRegistration} [/ril_0] Status = roaming
2014-09-26 20:11:19,323 {NetworkRegistration}
Looks like ofono core allowed to do the unlock even if the PIN has not
been entered, so probably implementing the quirk in ofono is fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1375945
Title:
This branch homogenizes the behaviour for krillin/mako:
https://github.com/rilmodem/ofono/pull/127
** Changed in: ofono (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
For some operators, Status is wrongly reported as roaming for a few
milliseconds before changing to registered. Although this should be
handled fine by the system, it can lead to status shown as roaming for
a small amount of time in the GUI, due to the signals emitted by
LP bug #1377148 has been reported to follow the -different from this
one- bug of the flickering roaming status.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1371032
Title:
Cannot send MMS from
Public bug reported:
After disabling WiFi and rebooting, WiFi appears as enabled in
indicator-network and system settings.
This contradicts what is shown in the status bar (see attached
screenshot).
WiFi interface exists, but it is down:
# ip address
22: wlan0: BROADCAST,MULTICAST mtu 1500
~# dbus-send --system --print-reply --dest=org.freedesktop.URfkill
/org/freedesktop/URfkill/WLAN org.freedesktop.DBus.Properties.GetAll
string:org.freedesktop.URfkill.Killswitch
method return sender=:1.2 - dest=:1.67 reply_serial=2
array [
dict entry(
string state
# /usr/share/urfkill/scripts/enumerate
/org/freedesktop/URfkill/devices/100
Printing props for unspecialized device: /org/freedesktop/URfkill/devices/100
Printing props for Ofono device: /org/freedesktop/URfkill/devices/100
soft: 0
name: Fake Manufacturer Fake Modem Model
urftype:
** Summary changed:
- WiFi shown as enabled in indicator while enabled in status bar
+ WiFi shown as enabled in indicator while disabled in status bar
** Description changed:
After disabling WiFi and rebooting, WiFi appears as enabled in
indicator-network and system settings.
This
This happened for touch image #149, with network-manager version
0.9.8.8-0ubuntu23 .
syslog for a simulated case where the APN name is wrong (APN
err.airtelwap.es), then ofono is stopped, the APN corrected
(airtelwap.es) and the phone rebooted is attached. The result is that no
context is
Also, if we stop network-manager upstart job after setting flight mode,
and then switch off flight mode, org.ofono.ConnectionManager.Powered
value will be 0.
** Changed in: ofono (Ubuntu)
Status: New = Invalid
** Also affects: ubuntu-system-settings
Importance: Undecided
Status:
I can easily reproduce the problem following Omer's steps (mako).
Some debugging in ofono shows that org.ofono.ConnectionManager.Powered
property is being set from NetworkManager after flight modem is switched
off, so this is not an ofono bug (Powered property is 0 right after
onlining the modem
For me, this happens only when you have no SIM inserted. indicator-
network crashes in that case when it tries to access the non-existing
ofono SIM interface. Executing indicator-network from the command line I
see:
phablet@ubuntu-phablet:~$
list-modems script with no SIM inserted shows that org.ofono.SimManager
does not appear in the Interfaces property of the modem, so it should
not be used:
root@ubuntu-phablet:/usr/share/ofono/scripts# ./list-modems
[ /ril_0 ]
Revision = M9615A-CEFWMAZM-2.0.1700.98
Emergency = 0
** Also affects: indicator-network (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1352744
Title:
List of WiFi access point is empty
To manage
The attached traces show that RIL_REQUEST_DIAL returns error code 0x13
instead of 0 (non-error). However, the subsequent GET_CURRENT_CALLS
shows a call with the dialled number, but with a prefix (014 instead of
0) because of the apparent redirection.
0x13 is not actually defined in ril.h. Some
This traces show the same problem. Error code 0x13 is returned when
dialling, and the call is redirected. In this case 123 is redirected
+18056377243 (T-Mobile US voice mail number).
** Attachment added: ofono traces
An easy workaround is to simply consider code 0x13 equivalent to 0
(=SUCCESS). However, some explanation on where this number comes from is
needed.
Interestingly, calling the same number in a BQ Aquaris does not produce
the error: REQUEST_DIAL reply has return code 0, although the number is
** Changed in: ofono (Ubuntu)
Assignee: Tony Espy (awe) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1239869
Title:
VoiceCallManager.Dial() fails
** Changed in: powerd (Ubuntu)
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1295085
Title:
powerd just listens to one
** Changed in: powerd
Assignee: (unassigned) = Alfonso Sanchez-Beato (alfonsosanchezbeato)
** Changed in: powerd
Status: New = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs
It turned out that error code 0x13 is specific to Qualcomm modems. A fix
can be found in:
https://github.com/rilmodem/ofono/pull/74
** Changed in: ofono (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
AOSP simply does not handle this: its ril.h it does not define this
error code. The error codes come from the codeaurora [1], which is
sponsored by Qualcomm and implements Snapdragon optimizations for
Android. Cyanogenmod took the code from them, ril.h and parts in the
java telephony service that
The radio log (I already had a full ofono log from Sergio). This can be
obtained using
/system/bin/logcat -b radio
while the error is being produced.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Analysis of the radio log shows CME error 3350 is returned when trying
to activate the context:
D/use-Rlog/RLOG-AT( 1961): AT+CGACT=1,2
...
D/use-Rlog/RLOG-AT( 1961): +CME ERROR: 3350
This error is not defined in TS 27.007, it looks MTK-specific.
--
You received this bug notification because
I can easily reproduce the 3350 error code when sending to myself an MMS
when technology is EDGE (2G). However, it does not happen when
technology is 3G. It might be caused by trying to activate too fast a
context after having just received an SMS (the MMS push notification).
The SDCCH GSM channel
1 - 100 of 794 matches
Mail list logo
