[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
1 year, 9 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, 1 month
gemalto: AGPS functionality
by Vincent CESSON
Hi,
I am trying to add AGPS functionality to Gemalto modems. I took a look
at interface AssistedSatelliteNavigation and implementation in
drivers/atmodem/gnss.c. Unfortunately, Gemalto does not support AT+CPOS
command but it uses a custom command: AT^SBNW. Moreover, the positioning
file expected is not XML but binary format.
The process of loading the binary is:
- Download binary file from Gemalto server to local memory
- Initiate binary write command: AT^SBNW="agps",<binary_file_length>
- Copy binary file from local memory to modem over its application (or
modem) interface
AT^SBNW immediately returns "CONNECT". Then "AGPS READY: SEND FILE..."
After the modem receives the exact amount of bytes specified in the
command, it verifies the data and returns one of the following: "AGPS
END OK", "TIME INFO ERROR", "BAD CRC" or "OK".
So I am facing several issues:
- How to send binary data from local memory to oFono? DBus message
with array of bytes?
- How to send binary data from oFono to modem interface? Does gatchat
only support strings?
- How to handle custom result codes? I already tried some hacks, and I
had to blacklist the response "CONNECT" for instance.
Or maybe it isn't worth the effort implementing it in oFono?
Regards,
Vincent
2 years, 5 months
[PATCH] ussd: Switch the state from USER_ACTION to IDLE
by Slava Monich
... when a USSD notification is received. Some networks
send 0 (no further user action required) after the response
timeout expires. That should result in the user input form
getting removed from the ME screen.
---
src/ussd.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/src/ussd.c b/src/ussd.c
index 99fa753..84f64c6 100644
--- a/src/ussd.c
+++ b/src/ussd.c
@@ -512,6 +512,20 @@ void ofono_ussd_notify(struct ofono_ussd *ussd, int status, int dcs,
ussd_change_state(ussd, new_state);
goto free;
+ } else if (ussd->state == USSD_STATE_USER_ACTION &&
+ status != OFONO_USSD_STATUS_ACTION_REQUIRED) {
+ ussd_change_state(ussd, USSD_STATE_IDLE);
+
+ if (status == OFONO_USSD_STATUS_NOTIFY && str && str[0]) {
+ const char *path = __ofono_atom_get_path(ussd->atom);
+
+ g_dbus_emit_signal(conn, path,
+ OFONO_SUPPLEMENTARY_SERVICES_INTERFACE,
+ "NotificationReceived", DBUS_TYPE_STRING,
+ &str, DBUS_TYPE_INVALID);
+ }
+
+ goto free;
} else {
ofono_error("Received an unsolicited USSD but can't handle.");
DBG("USSD is: status: %d, %s", status, str);
--
1.9.1
2 years, 5 months
[PATCH] radio-settings: Fix memory leaks in radio_load_settings
by Slava Monich
Errors returned by g_key_file_get_integer have to be deallocated
by the caller to avoid leaks like these:
==13330== 104 (24 direct, 80 indirect) bytes in 2 blocks are definitely lost
==13330== at 0x483F3EC: malloc (vg_replace_malloc.c)
==13330== by 0x4B020DF: g_malloc (gmem.c)
==13330== by 0x4B17F51: g_slice_alloc (gslice.c)
==13330== by 0x4AE80B9: g_error_new_valist (gerror.c)
==13330== by 0x4AE830B: g_set_error (gerror.c)
==13330== by 0x4AF5681: g_key_file_get_value (gkeyfile.c)
==13330== by 0x4AF6817: g_key_file_get_integer (gkeyfile.c)
==13330== by 0x10CFE3: radio_load_settings (radio-settings.c)
==13330== by 0x10D2E3: ofono_radio_settings_register (radio-settings.c)
---
src/radio-settings.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/radio-settings.c b/src/radio-settings.c
index b988e3e..4f81a84 100644
--- a/src/radio-settings.c
+++ b/src/radio-settings.c
@@ -856,9 +856,13 @@ static void radio_load_settings(struct ofono_radio_settings *rs,
"GsmBand", rs->band_gsm);
}
+ if (error) {
+ g_error_free(error);
+ error = NULL;
+ }
+
rs->pending_band_gsm = rs->band_gsm;
- error = NULL;
rs->band_umts = g_key_file_get_integer(rs->settings, SETTINGS_GROUP,
"UmtsBand", &error);
@@ -868,9 +872,13 @@ static void radio_load_settings(struct ofono_radio_settings *rs,
"UmtsBand", rs->band_umts);
}
+ if (error) {
+ g_error_free(error);
+ error = NULL;
+ }
+
rs->pending_band_umts = rs->band_umts;
- error = NULL;
rs->mode = g_key_file_get_integer(rs->settings, SETTINGS_GROUP,
"TechnologyPreference", &error);
@@ -880,6 +888,11 @@ static void radio_load_settings(struct ofono_radio_settings *rs,
"TechnologyPreference", rs->mode);
}
+ if (error) {
+ g_error_free(error);
+ error = NULL;
+ }
+
DBG("TechnologyPreference: %d", rs->mode);
DBG("GsmBand: %d", rs->band_gsm);
DBG("UmtsBand: %d", rs->band_umts);
--
1.9.1
2 years, 7 months