[PATCH] qmimodem: fix roaming status report
by Christophe Ronco
Hi,
With a MC7304 modem and a roaming SIM card, Status in org.ofono.NetworkRegistration
properties ends up in "registered" instead of roaming.
Both AT command and qmicli indicates we are roaming.
What's happening is the following:
1) first QMI_NAS_SS_INFO_IND indicating we are registered contains a QMI_NAS_RESULT_ROAMING_STATUS parameter.
Parameter inside says we are roaming and qmimidem driver correctly reports status NETWORK_REGISTRATION_STATUS_ROAMING.
2) other QMI_NAS_SS_INFO_IND arrive, saying we are registered without QMI_NAS_RESULT_ROAMING_STATUS parameter.
Driver reports NETWORK_REGISTRATION_STATUS_REGISTERED.
Extract of traces with QMI binary debug interpreted (as far as I can...):
a) first "searching" indication
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 3b 00 80 03 01 04 00 00 24 00 2f 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
22 05 00 01 02 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED, QMI_NAS_NETWORK_SERVICE_DOMAIN_PS, ...
15 03 00 01 08 01 LTE, no roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 01 00 00
10 01 00 01 No roaming
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=47 [client=1,type=4,tid=0,len=59]
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=34,len=5} {type=21,len=3} {type=18,len=5}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=17,len=1} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 2 lac -1 cellid -1 tech 7
b) second "searching" indication
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 21 00 80 03 01 04 00 00 24 00 15 00
22 05 00 03 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED_REGIONAL, CS_PS, ...
11 01 00 00
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=21 [client=1,type=4,tid=0,len=33]
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=17,len=1} {type=1,len=6}
c) First indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 5e 00 80 03 01 04 00 00 24 00 52 00
2a 01 00 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
26 08 00 03 00 00 00 03 00 00 00 CS: all calls allowed, PS: all calls allowed
22 05 00 02 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_AVAILABLE, CS_PS, ...
1e 04 00 f7 00 95 04 CID 3GPP
1d 02 00 fb 50 LAC 3GPP
15 03 00 01 05 00 UMTS: roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
10 01 00 00 ROAMING ON
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=82 [client=1,type=4,tid=0,len=94]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=42,len=1} {type=41,len=5} {type=40,len=2} {type=38,len=8}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=30,len=4} {type=29,len=2} {type=21,len=3}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=18,len=5} {type=17,len=4} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_gprs_status_notify modem /sierra_0 status 1
==================> ROAMING status reported <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 5 lac 20731 cellid 76873975 tech 2
d) second indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 31 00 80 03 01 04 00 00 24 00 25 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=37 [client=1,type=4,tid=0,len=49]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=40,len=2} {type=18,len=5} {type=17,len=4}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=1,len=6}
==================> ROAMING information lost <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 1 lac -1 cellid -1 tech 2
I don't know if this is a problem specific to MC7304 or even to my firmware version or if this is a normal behavior to have ROAMING_STATUS parameter only when status change from anything to registered.
Best Regards,
Christophe
Christophe Ronco (1):
qmimodem: fix roaming status report
drivers/qmimodem/network-registration.c | 50 ++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 7 deletions(-)
--
2.7.4
1 year, 10 months
[PATCH] sim: fix crash in case of invalid sim password type
by Christophe Ronco
Hi,
I have an old Swedish SIM card here that I tried to put in my MC7304 modem.
My ofono version is 1.20 (with some additional patches).
It sometimes return an invalid SIM password type.
After that, ofono crashes. Here is an extract of debug traces when this happens.
Ofono is just starting, modem was here before ofono starts.
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:string_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:qmi_query_serial()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.err ofonod[1120]: Requested file structure differs from SIM: 6fb7
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g2_read_cb() 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:get_ids_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x2fe2 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x2fe2 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 10
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x6f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 6
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x2f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x2f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 6
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_query_passwd_state()
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_card_status() info1->app_state:0x6: OFONO_SIM_PASSWORD_INVALID
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:query_passwd_state_cb() passwd state 16
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/sim.c:sim_pin_query_cb() sim->pin_type: 0, pin_type: 16
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.err ofonod[1120]: Aborting (signal 11) [/usr/sbin/ofonod]
Problem is just that we don't have a string corresponding to this password type.
Christophe Ronco (1):
sim: fix crash in case of invalid sim password type
src/sim.c | 1 +
1 file changed, 1 insertion(+)
--
2.7.4
2 years, 2 months
ofono with sim5320 module
by David Ashley
Hello, I'm at my wits' end trying to get ofono working with the
sim5320 module. I'm using the plugins/sim900.c module as a starting
point. I think the issue has something to do with the difference
between the MUX functionality between the 900 and the 5320. The sim900
supports the elaborate parameters sent on the
AT+CMUX=0,x,x,x,x, etc.
but the SIM5320 only supports
AT+CMUX=0
There's that... but also the way the sim900 plugin creates a
SETUP_DLC, initiates muxing, then deletes the setup DLC and creates 4
new DLC's... it didn't work for the sim5320 until I remapped the DLC's
somewhat like this:
#define NUM_DLC 4
#define VOICE_DLC 2
#define NETREG_DLC 1
//#define SMS_DLC 2
#define GPRS_DLC 3
#define SETUP_DLC 0
static char *dlc_prefixes[NUM_DLC] = {
[VOICE_DLC]="Voice: ",
[NETREG_DLC]="Net: ",
// [SMS_DLC]= "SMS: ",
[GPRS_DLC]= "GPRS: " ,
[SETUP_DLC]= "Setup: ",
};
Note I have to eliminate the SMS_DLC usage later in sim5320_post_sim:
// ofono_sms_create(modem, OFONO_VENDOR_SIMCOM, "atmodem",
// data->dlcs[SMS_DLC]);
OK everything is *ALMOST* working. ofonod interacts fine with
connmand, connmand tells ofonod to activate the sim5320, which
actually establishes a ppp connection and sets up a ppp device:
ppp0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0
inet addr:30.97.132.47 P-t-P:30.97.132.47 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:124 (124.0 B)
Here's the rub: No matter what I do, I never get any RX packets from
that ppp device, and even when it appears to TX packets (I'm trying to
ping out) the machine on the internet isn't actually receiving them.
I'm running on a beaglebone with a custom board with a sim5320 module on it.
I have no idea what to try... Any advice would be appreciated...
Thanks very much!!!!
-Dave
2 years, 6 months
[PATCH 0/7] Improve last call dialed functionality and add memory dialing
by Philippe De Swert
Hi!
Based on comments from my earlier patch series I made a new
one to add memory/favourites dialing. This patch set re-uses
parts of the common functionality of the earlier accepted
"last call dialed" calling. It also has a fix for a small dbus
bug that crept in and I only noticed later on while testing. This
series also adds caller id support to the last call dialed
functionality so that this is in line with the dial and dial favourites
options.
Cheers and thank you for reviewing,
Philippe
Philippe De Swert (7):
voicecall: Support clir for last call dialing
voicecall: Rename callbacks/functions related to dialing the last
called number
include/voicecall.h : Add support for dialing number at a given memory
location
voicecall: Fix issue with invalid dbus path
voicecall.c : Add functionality to dial from a memory location.
hfpmodem: Add memory dialling support
doc: Document the new DialMemory method of the voicecallmanager-api
doc/voicecallmanager-api.txt | 13 ++++++-
drivers/hfpmodem/voicecall.c | 30 ++++++++++++++-
include/voicecall.h | 8 +++-
src/voicecall.c | 88 +++++++++++++++++++++++++++++++++++++++-----
4 files changed, 126 insertions(+), 13 deletions(-)
--
2.11.0
2 years, 6 months
Re: connmand[186]: Online check failed but running dhclient manually fixes this issue
by Jonas Bonn
On 12/11/2017 07:37 AM, Sean Nyekjær wrote:
> Hi
> Sorry if i'm reposting.
>
> I'm also having this issue with the Quectel EC20 (and maybe EC21).
The EC21 is "raw ip" only so shouldn't be affected by this. I've got
one and I've never seen this issue in any case.
/Jonas
>
> Any known fixes or workarounds i could try? Is the problem in connman or ofono?
>
> /Sean
>
> On 6 September 2017 at 17:40, Denis Kenzior <denkenz(a)gmail.com> wrote:
>> Hi Daniel,
>>>>
>>>> If this is true, then falling back to DHCP would seem to be required
>>>> for many Qualcomm based devices. This seems to be a recently
>>>> introduced 'bug' as older QMI devices did not need this workaround.
>>>
>>> Do you think we should try to figure out which Qualcomm device is
>>> misbehaving or should the feature just be reverted?
>>
>> It would seem that this only affects devices introduced in the last several
>> years. The QMI code is from 2012, and the devices Marcel tested this with
>> worked fine.
>>
>> Perhaps we should have plugins/udevng.c maintain a database of all the
>> 'dhcp-required' devices and set this property accordingly. Running DHCP
>> takes time, so if it can be avoided, you get online a bit faster...
>>
>>> The other option is to add some fallback mechanism in ConnMan and print
>>> a fat warning into the log. But I don't this idea.
>>>
>> Sounds like a least preferred option to me as well.
>>
>> Regards,
>> -Denis
>>
>> _______________________________________________
>> connman mailing list
>> connman(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/connman
> _______________________________________________
> connman mailing list
> connman(a)lists.01.org
> https://lists.01.org/mailman/listinfo/connman
2 years, 6 months
[PATCH] sim: Don't submit parallel EFpl reads
by Slava Monich
In addition to not doing unnecessary SIM I/O, this fixes memory leaks
like this one:
==10096== 74 (56 direct, 18 indirect) bytes in 2 blocks are definitely lost in loss record 1,252 of 1,342
==10096== at 0x4841BF0: calloc (vg_replace_malloc.c)
==10096== by 0x4B03117: g_malloc0 (gmem.c)
==10096== by 0xF83DF: concat_lang_prefs (sim.c)
==10096== by 0xF8697: sim_efpl_read_cb (sim.c)
==10096== by 0x12CBF7: sim_fs_op_read_block_cb (simfs.c)
---
src/sim.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sim.c b/src/sim.c
index 2538c77..31df636 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -2200,6 +2200,9 @@ static void sim_efli_efpl_changed(int id, void *userdata)
if (sim->efli != NULL) /* This shouldn't happen */
return;
+ if (sim->language_prefs_update)
+ return;
+
if (sim->language_prefs) {
g_strfreev(sim->language_prefs);
sim->language_prefs = NULL;
--
1.9.1
2 years, 6 months
[PATCH] sim: Handle multiple EFpl read completions
by Slava Monich
Since sim_efli_efpl_changed() can be invoked several times before
completion of SIM reads (which are not cancellable), followed by
multiple completions, it's not enough to free old sim->language_prefs
in sim_efli_efpl_changed(). The same thing has to be done by
sim_efpl_read_cb() to avoid leaking memory e.g. after this
sequence of calls:
1. sim_efli_efpl_changed()
2. sim_efli_efpl_changed()
3. sim_efpl_read_cb()
4. sim_efpl_read_cb()
One such scenario involves __ofono_sim_refresh() calling
sim_efli_efpl_changed() first with id=SIM_EFPL_FILEID,
like this:
#0 sim_efli_efpl_changed (id=12037)
#1 sim_fs_notify_file_watches (id=-1)
#2 __ofono_sim_refresh (file_list=0x0, full_file_change=1, naa_init=1)
#3 handle_command_refresh ()
#4 ofono_stk_proactive_command_handled_notify ()
...
and then with id=28421 (SIM_EFLI_FILEID), so both files are
re-read twice, the second result overwriting the first one
and the first one getting lost (leaked). Since SIM reads are
asynchronous and take considerable time, I'm quite sure that
there are other scenarios as well.
In fact it's even better to keep the old sim->language_prefs
around until EFpl read is finished, to avoid issuing unnecessary
PropertyChanged signal if the second read produces the same
result, which it normally does.
---
src/sim.c | 30 ++++++++++++++++++++++++------
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index 2538c77..2585f06 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -2081,6 +2081,26 @@ static char **concat_lang_prefs(GSList *a, GSList *b)
return ret;
}
+static gboolean strv_equal(char **sv1, char **sv2)
+{
+ const guint len1 = sv1 ? g_strv_length(sv1) : 0;
+ const guint len2 = sv2 ? g_strv_length(sv2) : 0;
+
+ if (len1 == len2) {
+ guint i;
+
+ for (i = 0; i < len1; i++) {
+ if (strcmp(sv1[i], sv2[i])) {
+ return FALSE;
+ }
+ }
+
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
static void sim_efpl_read_cb(int ok, int length, int record,
const unsigned char *data,
int record_length, void *userdata)
@@ -2091,6 +2111,7 @@ static void sim_efpl_read_cb(int ok, int length, int record,
gboolean efli_format = TRUE;
GSList *efli = NULL;
GSList *efpl = NULL;
+ char **old_prefs = sim->language_prefs;
if (!ok || length < 2)
goto skip_efpl;
@@ -2142,13 +2163,15 @@ skip_efpl:
g_slist_free_full(efpl, g_free);
}
- if (sim->language_prefs != NULL)
+ if (!strv_equal(sim->language_prefs, old_prefs))
ofono_dbus_signal_array_property_changed(conn, path,
OFONO_SIM_MANAGER_INTERFACE,
"PreferredLanguages",
DBUS_TYPE_STRING,
&sim->language_prefs);
+ g_strfreev(old_prefs);
+
/* Proceed with sim initialization if we're not merely updating */
if (!sim->language_prefs_update)
__ofono_sim_recheck_pin(sim);
@@ -2200,11 +2223,6 @@ static void sim_efli_efpl_changed(int id, void *userdata)
if (sim->efli != NULL) /* This shouldn't happen */
return;
- if (sim->language_prefs) {
- g_strfreev(sim->language_prefs);
- sim->language_prefs = NULL;
- }
-
sim->language_prefs_update = true;
ofono_sim_read(sim->early_context, SIM_EFLI_FILEID,
--
1.9.1
2 years, 6 months
Print Backtrace on crash in Ofono
by Rohit Agrawal
Hi All,
I am trying to run Ofono on a ARM based AP processor. The backtrace
function which is present in Ofono is not working on that Processor though
I have done following:
Enabled -- > enable-debug option
Enabled -funwind_tables option in CC_FLAGS within enable-debug option
itself (configure.ac)
Provided -rdynamic option in LD_FLAGS within enable-debug option itseld (
configure.ac)
src/log.c
static void print_backtrace(unsigned int offset)
{
written = write(outfd[1], addr, len); -->This line is failing all the time.
}
I modified the print_backtrace() to below:
static void print_backtrace(unsigned int offset)
{
void *frames[99];
size_t n_ptrs;
//unsigned int i;
//int outfd[2], infd[2];
int pathlen;
//pid_t pid;
if (program_exec == NULL)
return;
pathlen = strlen(program_path);
ofono_error("++++++++ backtrace +++++++++++++++++++++");
n_ptrs = backtrace(frames, G_N_ELEMENTS(frames));
fprintf(stderr, "Last %d frames:\n", n_ptrs);
fprintf(stderr, "Offset is %d:\n", offset);
backtrace_symbols_fd(frames, n_ptrs, STDERR_FILENO);
ofono_error("++++++++++++++++++++++++++++++++++++++++");
}
With above modification, I am able to get backtrace but it only prints
address not the function names. Result is as below:
ofonod[2835]: ++++++++ backtrace +++++++++++++++++++++
Last 8 frames:
Offset is 2:
ofonod(+0xd5f60)[0x558a1a3f60]
ofonod(+0xd5ff4)[0x558a1a3ff4]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7f9cfa36c0]
ofonod(+0x3b614)[0x558a109614]
ofonod(ofono_modem_set_powered+0xe8)[0x558a1a6b18]
ofonod(+0x38548)[0x558a106548]
ofonod(+0x39548)[0x558a107548]
/usr/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x114)[0x7f9ce8eed4]
ofonod[2835]: ++++++++++++++++++++++++++++++++++++++++
Can some one help me what is missing and how can I resolve the issue ?
-Best Regards,
Rohit Agrawal
2 years, 6 months
[PATCH 1/4] network: allow drivers to generate more specific error codes
by Alexander Couzens
For certain modems it's not clear if they support all actions or not.
In such cases use CME errors which allows generate NotSupported
messages.
---
src/network.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network.c b/src/network.c
index 6e69b078495f..ae3175d4a7e9 100644
--- a/src/network.c
+++ b/src/network.c
@@ -222,7 +222,7 @@ static void register_callback(const struct ofono_error *error, void *data)
if (error->type == OFONO_ERROR_TYPE_NO_ERROR)
reply = dbus_message_new_method_return(netreg->pending);
else
- reply = __ofono_error_failed(netreg->pending);
+ reply = __ofono_error_from_error(error, netreg->pending);
__ofono_dbus_pending_reply(&netreg->pending, reply);
--
2.15.1
2 years, 7 months
[PATCH][v2 1/4] qmi/discovery: remove useless code
by Alexander Couzens
---
drivers/qmimodem/qmi.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/qmimodem/qmi.c b/drivers/qmimodem/qmi.c
index a0632ca54025..5b29b761686a 100644
--- a/drivers/qmimodem/qmi.c
+++ b/drivers/qmimodem/qmi.c
@@ -1161,13 +1161,6 @@ static void discover_callback(uint16_t message, uint16_t length,
device->version_str = strndup(ptr + 1, *((uint8_t *) ptr));
- service_list = ptr + *((uint8_t *) ptr) + 1;
-
- for (i = 0; i < service_list->count; i++) {
- if (service_list->services[i].type == QMI_SERVICE_CONTROL)
- continue;
- }
-
done:
device->version_list = list;
device->version_count = count;
--
2.15.1
2 years, 7 months
