Re: [PATCH uqmi 3/3] wds: allow profile reconfiguration
Hi
I have a similar patch for APN profile commands,
https://patchwork.ozlabs.org/project/openwrt/patch/20220905200751.998416-1-hen...@ginstmark.se/
I included commands for
--get-default-profile-number
--get-profile-settings
--create-profile
--modify-profile
/Henrik
Den tis 10 okt. 2023 kl 16:07 skrev David Bauer :
>
> Extend uqmi so it can modify connection profiles stored on the modem.
>
> This is required in case the operator disallows connections using the
> dual-stacked PDP type. In case of either the home or visited network
> disallowing dual-stacked connections, the PDP context establishment
> fails with the default settings.
>
> This can be worked around by configuring the APN and PDP type to profile
> slot 1 and subsequently enabling the data connection.
>
> Signed-off-by: David Bauer
> ---
> commands-wds.c | 96 ++
> commands-wds.h | 9 +
> 2 files changed, 105 insertions(+)
>
> diff --git a/commands-wds.c b/commands-wds.c
> index 3aecefd..b72dcc7 100644
> --- a/commands-wds.c
> +++ b/commands-wds.c
> @@ -30,11 +30,30 @@ static struct qmi_wds_start_network_request wds_sn_req = {
> };
> static struct qmi_wds_stop_network_request wds_stn_req;
>
> +struct uqmi_profile_modify_req {
> + int idx;
> +
> + char *apn_name;
> + char *username;
> + char *password;
> +
> + struct {
> + QmiWdsPdpType val;
> + bool set;
> + } pdp_type;
> +
> + struct {
> + QmiWdsAuthentication val;
> + bool set;
> + } auth;
> +} prf_mdf_req;
> +
> #define cmd_wds_set_apn_cb no_cb
> static enum qmi_cmd_result
> cmd_wds_set_apn_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
> qmi_msg *msg, char *arg)
> {
> qmi_set_ptr(&wds_sn_req, apn, arg);
> + prf_mdf_req.apn_name = arg;
> return QMI_CMD_DONE;
> }
>
> @@ -58,6 +77,9 @@ cmd_wds_set_auth_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct qm
> continue;
>
> qmi_set(&wds_sn_req, authentication_preference,
> modes[i].auth);
> +
> + prf_mdf_req.auth.set = true;
> + prf_mdf_req.auth.val = modes[i].auth;
> return QMI_CMD_DONE;
> }
>
> @@ -70,6 +92,7 @@ static enum qmi_cmd_result
> cmd_wds_set_username_prepare(struct qmi_dev *qmi, struct qmi_request *req,
> struct qmi_msg *msg, char *arg)
> {
> qmi_set_ptr(&wds_sn_req, username, arg);
> + prf_mdf_req.username = arg;
> return QMI_CMD_DONE;
> }
>
> @@ -78,9 +101,37 @@ static enum qmi_cmd_result
> cmd_wds_set_password_prepare(struct qmi_dev *qmi, struct qmi_request *req,
> struct qmi_msg *msg, char *arg)
> {
> qmi_set_ptr(&wds_sn_req, password, arg);
> + prf_mdf_req.password = arg;
> return QMI_CMD_DONE;
> }
>
> +#define cmd_wds_set_pdp_type_cb no_cb
> +static enum qmi_cmd_result
> +cmd_wds_set_pdp_type_prepare(struct qmi_dev *qmi, struct qmi_request *req,
> struct qmi_msg *msg, char *arg)
> +{
> + static const struct {
> + const char *name;
> + const QmiWdsPdpType mode;
> + } modes[] = {
> + { "ipv4", QMI_WDS_PDP_TYPE_IPV4 },
> + { "ipv6", QMI_WDS_PDP_TYPE_IPV6 },
> + { "ipv4v6", QMI_WDS_PDP_TYPE_IPV4_OR_IPV6 },
> + };
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(modes); i++) {
> + if (strcasecmp(modes[i].name, arg) != 0)
> + continue;
> +
> + prf_mdf_req.pdp_type.val = modes[i].mode;
> + prf_mdf_req.pdp_type.set = true;
> + return QMI_CMD_DONE;
> + }
> +
> + uqmi_add_error("Invalid value (valid: ipv4, ipv6, ipv4v6)");
> + return QMI_CMD_EXIT;
> +}
> +
> #define cmd_wds_set_autoconnect_cb no_cb
> static enum qmi_cmd_result
> cmd_wds_set_autoconnect_prepare(struct qmi_dev *qmi, struct qmi_request
> *req, struct qmi_msg *msg, char *arg)
> @@ -123,9 +174,54 @@ cmd_wds_set_profile_prepare(struct qmi_dev *qmi, struct
> qmi_request *req, struct
> uint32_t idx = strtoul(arg, NULL, 10);
>
> qmi_set(&wds_sn_req, profile_index_3gpp, idx);
> + prf_mdf_req.idx = idx;
> return QMI_CMD_DONE;
> }
>
> +static void
> +cmd_wds_modify_profile_cb(struct qmi_dev *qmi, struct qmi_request *req,
> struct qmi_msg *msg)
> +{
> + struct qmi_wds_modify_profile_response res;
> +
> + qmi_parse_wds_modify_profile_response(msg, &res);
> + if (res.set.extended_error_code)
> + blobmsg_add_u32(&status, NULL, res.data.extended_error_code);
> +}
> +
> +static enum qmi_cmd_result
> +cmd_wds_modify_profile_prepare(struct qmi_dev *qmi, struct qmi_request *req,
> struct qmi_msg *msg, char *arg)
> +{
> + struct qmi_wds_modify_profile_request wds_mdf_prf_req = {
> + QMI_INIT_SEQUENCE(profile_identifier,
> + .profile_t
[PATCH] uqmi: add APN profile commands
Add commands to create and modify default APN profile
--get-default-profile-number
--get-profile-settings
--create-profile
--modify-profile
Signed-off-by: Henrik Ginstmark
---
uqmi/src/commands-wds.c | 346 +---
uqmi/src/commands-wds.h | 22 +++
2 files changed, 312 insertions(+), 56 deletions(-)
diff --git a/uqmi/src/commands-wds.c b/uqmi/src/commands-wds.c
index 3aecefd..3d0f524 100644
--- a/uqmi/src/commands-wds.c
+++ b/uqmi/src/commands-wds.c
@@ -24,17 +24,70 @@
#include "qmi-message.h"
+static const struct {
+ const char *auth_name;
+ QmiWdsAuthentication auth;
+} auth_modes[] = {
+ { "none", QMI_WDS_AUTHENTICATION_NONE },
+ { "pap", QMI_WDS_AUTHENTICATION_PAP },
+ { "chap", QMI_WDS_AUTHENTICATION_CHAP },
+ { "both", QMI_WDS_AUTHENTICATION_PAP | QMI_WDS_AUTHENTICATION_CHAP },
+};
+
+static const struct {
+ const char *ipfam_name;
+ const QmiWdsIpFamily mode;
+} ipfam_modes[] = {
+ { "ipv4", QMI_WDS_IP_FAMILY_IPV4 },
+ { "ipv6", QMI_WDS_IP_FAMILY_IPV6 },
+ { "unspecified", QMI_WDS_IP_FAMILY_UNSPECIFIED },
+};
+
+static const struct {
+ const char *pdp_name;
+ const QmiWdsPdpType type;
+} pdp_types[] = {
+ { "ipv4", QMI_WDS_PDP_TYPE_IPV4 },
+ { "ppp", QMI_WDS_PDP_TYPE_PPP },
+ { "ipv6", QMI_WDS_PDP_TYPE_IPV6 },
+ { "ipv4v6", QMI_WDS_PDP_TYPE_IPV4_OR_IPV6 },
+};
+
+static const struct {
+ const char *profile_name;
+ const QmiWdsProfileType profile;
+} profile_types[] = {
+ { "3gpp", QMI_WDS_PROFILE_TYPE_3GPP },
+ { "3gpp2", QMI_WDS_PROFILE_TYPE_3GPP2 },
+};
+
static struct qmi_wds_start_network_request wds_sn_req = {
QMI_INIT(authentication_preference,
QMI_WDS_AUTHENTICATION_PAP | QMI_WDS_AUTHENTICATION_CHAP),
};
+
static struct qmi_wds_stop_network_request wds_stn_req;
+static struct qmi_wds_modify_profile_request wds_mp_req = {
+ QMI_INIT_SEQUENCE(profile_identifier,
+ .profile_type = QMI_WDS_PROFILE_TYPE_3GPP,
+ .profile_index = 1,
+ ),
+ QMI_INIT(apn_disabled_flag, false),
+};
+
+static struct qmi_wds_create_profile_request wds_cp_req = {
+ QMI_INIT(profile_type,QMI_WDS_PROFILE_TYPE_3GPP),
+ QMI_INIT(apn_disabled_flag, false),
+};
+
#define cmd_wds_set_apn_cb no_cb
static enum qmi_cmd_result
cmd_wds_set_apn_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
qmi_msg *msg, char *arg)
{
qmi_set_ptr(&wds_sn_req, apn, arg);
+ qmi_set_ptr(&wds_mp_req, apn_name, arg);
+ qmi_set_ptr(&wds_cp_req, apn_name, arg);
return QMI_CMD_DONE;
}
@@ -42,22 +95,14 @@ cmd_wds_set_apn_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi
static enum qmi_cmd_result
cmd_wds_set_auth_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
qmi_msg *msg, char *arg)
{
- static const struct {
- const char *name;
- QmiWdsAuthentication auth;
- } modes[] = {
- { "pap", QMI_WDS_AUTHENTICATION_PAP },
- { "chap", QMI_WDS_AUTHENTICATION_CHAP },
- { "both", QMI_WDS_AUTHENTICATION_PAP |
QMI_WDS_AUTHENTICATION_CHAP },
- { "none", QMI_WDS_AUTHENTICATION_NONE },
- };
int i;
-
- for (i = 0; i < ARRAY_SIZE(modes); i++) {
- if (strcasecmp(modes[i].name, arg) != 0)
+ for (i = 0; i < ARRAY_SIZE(auth_modes); i++) {
+ if (strcasecmp(auth_modes[i].auth_name, arg) != 0)
continue;
- qmi_set(&wds_sn_req, authentication_preference, modes[i].auth);
+ qmi_set(&wds_sn_req, authentication_preference,
auth_modes[i].auth);
+ qmi_set(&wds_mp_req, authentication, auth_modes[i].auth);
+ qmi_set(&wds_cp_req, authentication, auth_modes[i].auth);
return QMI_CMD_DONE;
}
@@ -70,6 +115,8 @@ static enum qmi_cmd_result
cmd_wds_set_username_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
qmi_set_ptr(&wds_sn_req, username, arg);
+ qmi_set_ptr(&wds_mp_req, username, arg);
+ qmi_set_ptr(&wds_cp_req, username, arg);
return QMI_CMD_DONE;
}
@@ -78,6 +125,8 @@ static enum qmi_cmd_result
cmd_wds_set_password_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
qmi_set_ptr(&wds_sn_req, password, arg);
+ qmi_set_ptr(&wds_mp_req, password, arg);
+ qmi_set_ptr(&wds_cp_req, password, arg);
return QMI_CMD_DONE;
}
@@ -94,21 +143,12 @@ cmd_wds_set_autoconnect_prepare(struct qmi_dev *qmi,
struct qmi_request *req, st
static enum
Re: [PATCH v2] uqmi: wms - added storage to read text messages
Den tis 15 mars 2022 kl 21:14 skrev Sergey Ryazanov : > > On Tue, Mar 15, 2022 at 10:36 PM Henrik Ginstmark wrote: > > Today it's hard coded to read text messages from SIM card. > > Not all devices store received text messages in SIM, they store > > in me, QMI_WMS_STORAGE_TYPE_NV. > > I have added --storage as an argumet available to > > --list-messages > > --get-message > > --delete-message > > --get-raw-message > > > > If --storage is omitted default storage is sim, as before. > > > > Signed-off-by: Henrik Ginstmark > > Looks good! > > Reviewed-by: Sergey Ryazanov Hi What will be the next step? Any testing needed? BR Henrik ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] command-nas: fix json output
Hi
You can break down LTE global-cell-id to enodeb_id and cell_id like this:
"intrafrequency_lte_info": {
"tracking_area_code": 14000,
"global_cell_id": 10498829,
=
"enodeb_id": 41011,
"cell_id": 13,
blobmsg_add_u32(&status,
"enodeb_id",res.data.intrafrequency_lte_info_v2.global_cell_id/256);
blobmsg_add_u32(&status,
"cell_id",res.data.intrafrequency_lte_info_v2.global_cell_id%256);
Same in nas_get_system_info and for UMTS global_cell_id you can break
down to rnc_id and
cell_id.
blobmsg_add_u32(&status, "rnc_id",res.data.wcdma_system_info_v2.cid/65536);
blobmsg_add_u32(&status, "cell_id",res.data.wcdma_system_info_v2.cid%65536);
Henrik
Den mån 14 mars 2022 kl 17:00 skrev Jan-Niklas Burfeind :
>
> Hey everyone,
> I attached the current output of my patched uqmi.
> Please let me know if you think the arrays should be named differently
> or if you spot an error.
>
> Thanks and have a nice day
> Aiyion
>
> On 3/8/22 16:01, Jan-Niklas Burfeind wrote:
> > Output the cells from --get-cell-location-info in an array "cells",
> > "geran" entries as an array called alike,
> > and wrap output for different "frequencies" as such.
> >
> > Reported-by: Cezary Jackiewicz
> > Suggested-by: Oskari Lemmelä
> > Signed-off-by: Jan-Niklas Burfeind
> > ---
> > Hey Oskari and Cezary,
> > Please have a thorough look at this, as I do not have the matching
> > equipment at hand to test all cases.
> > Let me know if you rather would see `frequencies` become `channels`
> > and if the `geran`-array does make sense.
> >
> > I just compiled this series without errors and will have a look at the
> > LTE-related json-outputs.
> >
> > Thanks for your time
> > Jan-Niklas
> >
> > commands-nas.c | 46 +-
> > 1 file changed, 37 insertions(+), 9 deletions(-)
> >
> > diff --git a/commands-nas.c b/commands-nas.c
> > index 275c53f..b99767f 100644
> > --- a/commands-nas.c
> > +++ b/commands-nas.c
> > @@ -708,7 +708,7 @@ static void
> > cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
> > *req, struct qmi_msg *msg)
> > {
> > struct qmi_nas_get_cell_location_info_response res;
> > - void *c, *t, *cell, *freq;
> > + void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
> > int i, j;
> >
> > qmi_parse_nas_get_cell_location_info_response(msg, &res);
> > @@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> > struct qmi_request *req,
> >
> > res.data.umts_info_v2.primary_scrambling_code);
> > blobmsg_add_u32(&status, "rscp", res.data.umts_info_v2.rscp);
> > blobmsg_add_u32(&status, "ecio", res.data.umts_info_v2.ecio);
> > + cells = blobmsg_open_array(&status, "cells");
> > for (j = 0; j < res.data.umts_info_v2.cell_n; j++) {
> > cell = blobmsg_open_table(&status, NULL);
> > blobmsg_add_u32(&status, "channel",
> > @@ -734,6 +735,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> > struct qmi_request *req,
> > blobmsg_add_u32(&status, "ecio",
> > res.data.umts_info_v2.cell[j].ecio);
> > blobmsg_close_table(&status, cell);
> > }
> > + blobmsg_close_array(&status, cells);
> > + geran = blobmsg_open_array(&status, "geran");
> > for (j = 0; j < res.data.umts_info_v2.neighboring_geran_n;
> > j++) {
> > cell = blobmsg_open_table(&status,
> > "neighboring_geran");
> > blobmsg_add_u32(&status, "channel",
> > @@ -746,6 +749,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> > struct qmi_request *req,
> >
> > res.data.umts_info_v2.neighboring_geran[j].rssi);
> > blobmsg_close_table(&status, cell);
> > }
> > + blobmsg_close_array(&status, geran);
> > blobmsg_close_table(&status, c);
> > }
> > if (res.set.intrafrequency_lte_info_v2) {
> > @@ -769,6 +773,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> > struct qmi_request *req,
> > blobmsg_add_u32(&status, "s_intra_search_threshold",
> >
> > res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
> > }
> > + cells = blobmsg_open_array(&status, "cells");
> > for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
> > i++) {
> > cell = blobmsg_open_table(&status, NULL);
> >
> > print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
> > @@ -780,11 +785,14 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev
> > *qmi, struct qmi_request *req,
> >
> > res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
> > bl
[PATCH v2] uqmi: wms - added storage to read text messages
Today it's hard coded to read text messages from SIM card.
Not all devices store received text messages in SIM, they store
in me, QMI_WMS_STORAGE_TYPE_NV.
I have added --storage as an argumet available to
--list-messages
--get-message
--delete-message
--get-raw-message
If --storage is omitted default storage is sim, as before.
Signed-off-by: Henrik Ginstmark
---
uqmi/src/commands-wms.c | 62 ++---
uqmi/src/commands-wms.h | 5
2 files changed, 45 insertions(+), 22 deletions(-)
diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
index a58fd6a..186c043 100644
--- a/uqmi/src/commands-wms.c
+++ b/uqmi/src/commands-wms.c
@@ -24,6 +24,40 @@
#define MIN(a,b) (((a)<(b))?(a):(b))
#define CEILDIV(x,y) (((x) + (y) - 1) / (y))
+static struct qmi_wms_list_messages_request lmreq = {
+ QMI_INIT(storage_type, QMI_WMS_STORAGE_TYPE_UIM),
+ QMI_INIT(message_tag, QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
+};
+
+static struct qmi_wms_delete_request dmreq = {
+ QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
+ QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
+};
+
+static struct qmi_wms_raw_read_request gmreq = {
+ QMI_INIT_SEQUENCE(message_memory_storage_id,
+ .storage_type = QMI_WMS_STORAGE_TYPE_UIM,
+ ),
+ QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
+};
+
+
+#define cmd_wms_storage_cb no_cb
+static enum qmi_cmd_result
+cmd_wms_storage_prepare(struct qmi_dev *qmi, struct qmi_request *req, struct
qmi_msg *msg, char *arg)
+{
+ if (strcmp(arg, "sim") == 0) {
+ } else if (strcmp(arg, "me") == 0) {
+ qmi_set_ptr(&lmreq, storage_type, QMI_WMS_STORAGE_TYPE_NV);
+ qmi_set_ptr(&dmreq, memory_storage, QMI_WMS_STORAGE_TYPE_NV);
+ qmi_set_ptr(&gmreq, message_memory_storage_id.storage_type,
QMI_WMS_STORAGE_TYPE_NV);
+ } else {
+ uqmi_add_error("Invalid value (sim or me)");
+ return QMI_CMD_EXIT;
+ }
+ return QMI_CMD_DONE;
+}
+
static void cmd_wms_list_messages_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_wms_list_messages_response res;
@@ -41,12 +75,7 @@ static void cmd_wms_list_messages_cb(struct qmi_dev *qmi,
struct qmi_request *re
static enum qmi_cmd_result
cmd_wms_list_messages_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
- static struct qmi_wms_list_messages_request mreq = {
- QMI_INIT(storage_type, QMI_WMS_STORAGE_TYPE_UIM),
- QMI_INIT(message_tag, QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
- };
-
- qmi_set_wms_list_messages_request(msg, &mreq);
+ qmi_set_wms_list_messages_request(msg, &lmreq);
return QMI_CMD_REQUEST;
}
@@ -292,15 +321,10 @@ cmd_wms_delete_message_prepare(struct qmi_dev *qmi,
struct qmi_request *req, str
return QMI_CMD_EXIT;
}
- static struct qmi_wms_delete_request mreq = {
- QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
- QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
- };
-
- mreq.set.memory_index = 1;
- mreq.data.memory_index = id;
+ dmreq.set.memory_index = 1;
+ dmreq.data.memory_index = id;
- qmi_set_wms_delete_request(msg, &mreq);
+ qmi_set_wms_delete_request(msg, &dmreq);
return QMI_CMD_REQUEST;
}
@@ -443,12 +467,6 @@ error:
static enum qmi_cmd_result
cmd_wms_get_message_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
- static struct qmi_wms_raw_read_request mreq = {
- QMI_INIT_SEQUENCE(message_memory_storage_id,
- .storage_type = QMI_WMS_STORAGE_TYPE_UIM,
- ),
- QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
- };
char *err;
int id;
@@ -458,8 +476,8 @@ cmd_wms_get_message_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct
return QMI_CMD_EXIT;
}
- mreq.data.message_memory_storage_id.memory_index = id;
- qmi_set_wms_raw_read_request(msg, &mreq);
+ gmreq.data.message_memory_storage_id.memory_index = id;
+ qmi_set_wms_raw_read_request(msg, &gmreq);
return QMI_CMD_REQUEST;
}
diff --git a/uqmi/src/commands-wms.h b/uqmi/src/commands-wms.h
index e28b97b..03110bc 100644
--- a/uqmi/src/commands-wms.h
+++ b/uqmi/src/commands-wms.h
@@ -20,6 +20,7 @@
*/
#define __uqmi_wms_commands \
+ __uqmi_command(wms_storage, storage, required, CMD_TYPE_OPTION), \
__uqmi_command(wms_list_messages, list-messages, no, QMI_SERVICE_WMS), \
__uqmi_command(wms_delete_message, delete-message, required,
QMI_SERVICE_WMS), \
__uqmi_command(wms_get_message, get-message, required,
QMI_SERVICE_WMS), \
@@ -3
Re: [PATCH] uqmi: wms - added storage to read text messages
Yes, that's a good proposal. I will send an updated patch for review tomorrow.
Henrik
Den mån 14 mars 2022 kl 21:39 skrev Sergey Ryazanov :
>
> On Mon, Mar 14, 2022 at 9:03 PM Henrik Ginstmark wrote:
> > Yes, I agree this will break backward compatibility. --get-message and
> > --delete-message should be quite easy to fix with still have SIM as
> > default storage, but for --list-messages I don´t have a clear view how
> > to add an optional argument, jet.
> > A quick fix could be just to add a new command: --list-messages-me.
>
> How about implementing the storage argument as an option for each of
> these commands? Like the SMSC option for the send message command.
> Something like this:
> --list-messages: List SMS messages
> --messages-storage : Messages storage (sim (default), me)
> --delete-message :Delete SMS message at index
> --messages-storage : Messages storage (sim (default), me)
> --get-message : Get SMS message at index
> --messages-storage : Messages storage (sim (default), me)
>
> > Den mån 14 mars 2022 kl 01:26 skrev Sergey Ryazanov
> > :
> >> Hello Henrik,
> >>
> >> On Sun, Mar 13, 2022 at 10:25 PM Henrik Ginstmark
> >> wrote:
> >>> Today it's hard coded to read text messages from SIM card.
> >>> Not all devices store received text messages in SIM, they store
> >>> in me, QMI_WMS_STORAGE_TYPE_NV.
> >>> I have added a switch to choose sim or me for --list-messages,
> >>> --get-message and --delete-message.
> >>>
> >>> Signed-off-by: Henrik Ginstmarh
> >>> ---
> >>> uqmi/src/commands-wms.c | 69 +
> >>> uqmi/src/commands-wms.h | 10 +++---
> >>> 2 files changed, 61 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
> >>> index a58fd6a..2bcc398 100644
> >>> --- a/uqmi/src/commands-wms.c
> >>> +++ b/uqmi/src/commands-wms.c
> >>> @@ -46,6 +46,14 @@ cmd_wms_list_messages_prepare(struct qmi_dev *qmi,
> >>> struct qmi_request *req, stru
> >>> QMI_INIT(message_tag,
> >>> QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
> >>> };
> >>>
> >>> + if (strcmp(arg, "sim") == 0) {
> >>> + } else if (strcmp(arg, "me") == 0) {
> >>> + qmi_set_ptr(&mreq, storage_type, QMI_WMS_STORAGE_TYPE_NV);
> >>> + } else {
> >>> + uqmi_add_error("Invalid value (sim or me)");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> +
> >>> qmi_set_wms_list_messages_request(msg, &mreq);
> >>>
> >>> return QMI_CMD_REQUEST;
> >>> @@ -283,20 +291,37 @@ static void blobmsg_add_hex(struct blob_buf *buf,
> >>> const char *name, unsigned con
> >>> static enum qmi_cmd_result
> >>> cmd_wms_delete_message_prepare(struct qmi_dev *qmi, struct qmi_request
> >>> *req, struct qmi_msg *msg, char *arg)
> >>> {
> >>> - char *err;
> >>> - int id;
> >>> -
> >>> - id = strtoul(arg, &err, 10);
> >>> - if (err && *err) {
> >>> - uqmi_add_error("Invalid message ID");
> >>> - return QMI_CMD_EXIT;
> >>> - }
> >>> -
> >>> static struct qmi_wms_delete_request mreq = {
> >>> QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
> >>> QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
> >>> };
> >>>
> >>> + char *s;
> >>> + int id;
> >>> +
> >>> + s = strchr(arg, ',');
> >>> + if (!s) {
> >>> + uqmi_add_error("Invalid argument");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> + s = strtok(s, ",");
> >>> + if (!s) {
> >>> + uqmi_add_error("No message id");
> >>> + return QMI_CMD_EXIT;
> >>> + }
> >>> + id = strtoul(s, &s, 0);
> >>> + if (s && *s) {
> >>> + uqmi_add_error("Invalid message id");
> >&g
[PATCH] uqmi: wms - added storage to read text messages
Today it's hard coded to read text messages from SIM card.
Not all devices store received text messages in SIM, they store
in me, QMI_WMS_STORAGE_TYPE_NV.
I have added a switch to choose sim or me for --list-messages,
--get-message and --delete-message.
Signed-off-by: Henrik Ginstmarh
---
uqmi/src/commands-wms.c | 69 +
uqmi/src/commands-wms.h | 10 +++---
2 files changed, 61 insertions(+), 18 deletions(-)
diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
index a58fd6a..2bcc398 100644
--- a/uqmi/src/commands-wms.c
+++ b/uqmi/src/commands-wms.c
@@ -46,6 +46,14 @@ cmd_wms_list_messages_prepare(struct qmi_dev *qmi, struct
qmi_request *req, stru
QMI_INIT(message_tag, QMI_WMS_MESSAGE_TAG_TYPE_MT_NOT_READ),
};
+ if (strcmp(arg, "sim") == 0) {
+ } else if (strcmp(arg, "me") == 0) {
+ qmi_set_ptr(&mreq, storage_type, QMI_WMS_STORAGE_TYPE_NV);
+ } else {
+ uqmi_add_error("Invalid value (sim or me)");
+ return QMI_CMD_EXIT;
+ }
+
qmi_set_wms_list_messages_request(msg, &mreq);
return QMI_CMD_REQUEST;
@@ -283,20 +291,37 @@ static void blobmsg_add_hex(struct blob_buf *buf, const
char *name, unsigned con
static enum qmi_cmd_result
cmd_wms_delete_message_prepare(struct qmi_dev *qmi, struct qmi_request *req,
struct qmi_msg *msg, char *arg)
{
- char *err;
- int id;
-
- id = strtoul(arg, &err, 10);
- if (err && *err) {
- uqmi_add_error("Invalid message ID");
- return QMI_CMD_EXIT;
- }
-
static struct qmi_wms_delete_request mreq = {
QMI_INIT(memory_storage, QMI_WMS_STORAGE_TYPE_UIM),
QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
};
+ char *s;
+ int id;
+
+ s = strchr(arg, ',');
+ if (!s) {
+ uqmi_add_error("Invalid argument");
+ return QMI_CMD_EXIT;
+ }
+ s = strtok(s, ",");
+ if (!s) {
+ uqmi_add_error("No message id");
+ return QMI_CMD_EXIT;
+ }
+ id = strtoul(s, &s, 0);
+ if (s && *s) {
+ uqmi_add_error("Invalid message id");
+ return QMI_CMD_EXIT;
+ }
+ if (strcmp(strtok(arg, ","), "sim") == 0) {
+ } else if (strcmp(strtok(arg, ","), "me") == 0) {
+ qmi_set_ptr(&mreq, memory_storage, QMI_WMS_STORAGE_TYPE_NV);
+ } else {
+ uqmi_add_error("Invalid value (sim or me)");
+ return QMI_CMD_EXIT;
+ }
+
mreq.set.memory_index = 1;
mreq.data.memory_index = id;
@@ -449,12 +474,30 @@ cmd_wms_get_message_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct
),
QMI_INIT(message_mode, QMI_WMS_MESSAGE_MODE_GSM_WCDMA),
};
- char *err;
+
+ char *s;
int id;
- id = strtoul(arg, &err, 10);
- if (err && *err) {
- uqmi_add_error("Invalid message ID");
+ s = strchr(arg, ',');
+ if (!s) {
+ uqmi_add_error("Invalid argument");
+ return QMI_CMD_EXIT;
+ }
+ s = strtok(s, ",");
+ if (!s) {
+ uqmi_add_error("No message id");
+ return QMI_CMD_EXIT;
+ }
+ id = strtoul(s, &s, 0);
+ if (s && *s) {
+ uqmi_add_error("Invalid message id");
+ return QMI_CMD_EXIT;
+ }
+ if (strcmp(strtok(arg, ","), "sim") == 0) {
+ } else if (strcmp(strtok(arg, ","), "me") == 0) {
+ qmi_set_ptr(&mreq, message_memory_storage_id.storage_type,
QMI_WMS_STORAGE_TYPE_NV);
+ } else {
+ uqmi_add_error("Invalid value (sim or me)");
return QMI_CMD_EXIT;
}
diff --git a/uqmi/src/commands-wms.h b/uqmi/src/commands-wms.h
index e28b97b..d79acd6 100644
--- a/uqmi/src/commands-wms.h
+++ b/uqmi/src/commands-wms.h
@@ -20,7 +20,7 @@
*/
#define __uqmi_wms_commands \
- __uqmi_command(wms_list_messages, list-messages, no, QMI_SERVICE_WMS), \
+ __uqmi_command(wms_list_messages, list-messages, required,
QMI_SERVICE_WMS), \
__uqmi_command(wms_delete_message, delete-message, required,
QMI_SERVICE_WMS), \
__uqmi_command(wms_get_message, get-message, required,
QMI_SERVICE_WMS), \
__uqmi_command(wms_get_raw_message, get-raw-message, required,
QMI_SERVICE_WMS), \
@@ -30,10 +30,10 @@
__uqmi_command(wms_send_message, send-message, required,
QMI_SERVICE_WMS)
#define wms_helptext \
- " --list-messages: List SMS messages\n" \
- " --delete-message :Delete SMS message at
index \n" \
- " --get-message : Get SMS message at index
\n" \
- " --get-raw-message : Get SMS raw message
contents at index \n" \
+ " --list-me
[no subject]
Reply-To: Subject: In-Reply-To: ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uqmi: corrected too short received SMS
Thanks for the quick response.
Sorry about the line-wrapping. I need to lock into my git environment.
Cheers
Henrik
Den lör 12 mars 2022 kl 11:49 skrev Daniel Golle :
>
> Hi Henrik,
>
> thank you for submitting this patch. I've also noticed that problem
> long ago but it wasn't important for me at the time, so I didn't go
> into fixing it.
>
> On Sat, Mar 12, 2022 at 12:33:54AM +0100, Henrik Ginstmark wrote:
> > When characters with ascii values bigger than 0x7f are used, the
> > length of the received text
> > message is too short.
> >
> > Test message sent: 123äÄ123
> > Before correction:
> > root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
> > Raw text: 31 32 33 7b 5b 31 32 33
> > {
> > "smsc": "+4672441",
> > "sender": "+46x",
> > "timestamp": "2022-03-11 18:48:10",
> > "text": "123äÄ1"
> > }
> >
> > after correction:
> > root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
> > Raw text: 31 32 33 7b 5b 31 32 33
> > {
> > "smsc": "+4672441",
> > "sender": "+46x",
> > "timestamp": "2022-03-11 18:48:10",
> > "text": "123äÄ123"
> > }
> >
> > Signed-off-by: Henrik Ginstmark
> > ---
> > uqmi/src/commands-wms.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
> > index 700d79f..a58fd6a 100644
> > --- a/uqmi/src/commands-wms.c
> > +++ b/uqmi/src/commands-wms.c
> > @@ -222,8 +222,8 @@ static int decode_udh(const unsigned char *data)
> > static void decode_7bit_field(char *name, const unsigned char *data,
> > int data_len, int bit_offset)
>
> I've fixed the line-wrappign problems here ...
>
> > {
> > char *dest = blobmsg_alloc_string_buffer(&status, name, 3 *
> > data_len + 2);
>
> ... and here ...
> > - pdu_decode_7bit_str(dest, data, CEILDIV(data_len * 7, 8),
> > bit_offset);
> > - dest[data_len] = 0;
> > + int out_len = pdu_decode_7bit_str(dest, data, CEILDIV(data_len
> > * 7, 8), bit_offset);
>
> ... and here, so the patch would apply.
>
> > + dest[out_len] = 0;
> > blobmsg_add_string_buffer(&status);
> > }
> >
> > --
> > 2.34.1
>
> Please use 'git format-send-email' or 'git format-patch' next time to
> avoid the MUA messing around with line-wrapping.
> For this submission it's ok, I've already fixed it manually.
>
>
> Cheers
>
>
> Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uqmi: corrected too short received SMS
When characters with ascii values bigger than 0x7f are used, the
length of the received text
message is too short.
Test message sent: 123äÄ123
Before correction:
root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
Raw text: 31 32 33 7b 5b 31 32 33
{
"smsc": "+4672441",
"sender": "+46x",
"timestamp": "2022-03-11 18:48:10",
"text": "123äÄ1"
}
after correction:
root@OpenWrt:/tmp# uqmi -d /dev/cdc-wdm0 --get-message 20
Raw text: 31 32 33 7b 5b 31 32 33
{
"smsc": "+4672441",
"sender": "+46xxxxx",
"timestamp": "2022-03-11 18:48:10",
"text": "123äÄ123"
}
Signed-off-by: Henrik Ginstmark
---
uqmi/src/commands-wms.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/uqmi/src/commands-wms.c b/uqmi/src/commands-wms.c
index 700d79f..a58fd6a 100644
--- a/uqmi/src/commands-wms.c
+++ b/uqmi/src/commands-wms.c
@@ -222,8 +222,8 @@ static int decode_udh(const unsigned char *data)
static void decode_7bit_field(char *name, const unsigned char *data,
int data_len, int bit_offset)
{
char *dest = blobmsg_alloc_string_buffer(&status, name, 3 *
data_len + 2);
- pdu_decode_7bit_str(dest, data, CEILDIV(data_len * 7, 8), bit_offset);
- dest[data_len] = 0;
+ int out_len = pdu_decode_7bit_str(dest, data, CEILDIV(data_len
* 7, 8), bit_offset);
+ dest[out_len] = 0;
blobmsg_add_string_buffer(&status);
}
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] usbmode: add config #0 and delay before actual config
Hi I have a Huawei ME909s-120. When I switch directly from configuration #2 to #3, MBIM, the modem will not respond to any MBIM messages. I need to go via configuration #0, and a short delay, and then to configuration #3 to make my modem to respond. It´s the same for Huawei ME909s as well. BR Henrik Den lör 19 feb. 2022 kl 11:15 skrev Petr Štetiar : > > Henrik Ginstmark [2022-02-07 22:30:40]: > > Hi, > > > Add config #0 and a 100milliseconds delay before switching to actual config. > > Like in USB_ModeSwitch, > > https://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2710&sid=505ed44b4064fef7009f0c26aac085e2&start=15 > > can you be more specific, we need to know, why do you need to add this, is it > fixing some issue etc. No need to resend, just reply with the answer to 'Why > are these changes needed?' question, thanks. > > Cheers, > > Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] usbmode: add config #0 and delay before actual config
Add config #0 and a 100milliseconds delay before switching to actual config.
Like in USB_ModeSwitch,
https://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2710&sid=505ed44b4064fef7009f0c26aac085e2&start=15
Signed-off-by: Henrik Ginstmark
---
usbmode/src/switch.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/usbmode/src/switch.c b/usbmode/src/switch.c
index cc04237..6285c7c 100644
--- a/usbmode/src/switch.c
+++ b/usbmode/src/switch.c
@@ -520,8 +520,11 @@ void handle_switch(struct usbdev_data *data)
config_new = blobmsg_get_u32(tb[DATA_CONFIG]);
if (libusb_get_configuration(data->devh, &config) ||
- config != config_new)
+ config != config_new) {
+ libusb_set_configuration(data->devh, 0);
+ usleep(10);
libusb_set_configuration(data->devh, config_new);
+ }
}
if (tb[DATA_ALT]) {
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Hi I have gathered my thoughts in my own version of uqmi. I think I have dual-stack working. It's available at https://github.com/mrhaav/openwrt-packages. Feel free to take a lock and try. :) /Henrik Den mån 6 dec. 2021 kl 08:29 skrev Bjørn Mork : > > Sergey Ryazanov writes: > > > Can you reveal what modem model has such nasty behaviour? I personally > > test IPv6 with Huawei E3372 (NCM, not QMI) and Sierra MC7304, both of > > them work stable. But I can not recall whether they established the > > IPv6 connection as soon as a PDP context was reconfigured or I needed > > to reattach (power circle) them. Need to recheck someday. > > I believe this is a common issue, not limited to a specific vendor. The > last modem where I noticed it was a Quectel RG502Q-EA. But I'm pretty > sure the problem was there in older modems too. You should be able to > see it in the MC7304. Don't you? Not sure about the non-Qualcomm > modems. > > > And do you remember whether the airplane mode was the only option to > > configure a new APN or some other operation also help to recover IPv6 > > connectivity? E.g. disconnect/connect QMI command or a modem power > > circle. > > I haven't tried ariplane mode to resolve this. But that should work > since it will cause the modem to reattach to the network.. > > Since this is mostly a one-time thing I've just changed the modem config > and rebooted the modem. Usually after debugging for a while before I > remember to check the default APN config. > >>> BTW, when you are talking about QMAP, did you mean utilizing the QMAP > >>> demux module from the kernel as it is or implementing the WWAN > >>> subsystem ops for the qmi_wwan module. In other words, did you mean > >>> protocol or implementation? > >> > >> I was talking about the (lack of) muxing setup support in uqmi. There > >> is no way to tell the modem firmware how the different channels are > >> supposed to be connected. > > > > Ouch, now I got this too. Whether the --profile option serves > > this purpose, or do we need to implement some other message? > > > > I know this goes beyond the APN change discussion, but since such a > > case presented itself, I want to ask you a question. What do you think > > about turning the current linux QMAP implementation into a library and > > use it within the qmi_wwan driver to implement the data channels > > demuxing that is controlled via the WWAN ops? > > > > I would like to try this, but I have been pointed out a couple of > > times about the complexity of the Qualcomm protocols, so I am just > > afraid to propose such a change :) > > I'm not sure I understand what you want to do. Muxing is sort-of > supported in qmi_wwan. But the proper solution is to use the rmnet > driver on top of it. The legacy implementation in qmi_wwan doesn't > support QMAPv5, and probably won't since I don't think we can add that > without more userspace knobs. And I promised the last change to the > userspace ABI was ... well,... the LAST one. > > As for the PCIe stuff and all that, I assume Qualcomm will support that > using the rmnet driver on top of the PCIe transport drivers. If they > continue to support QMAP/QMI/RMNET it at all? The last I heard, they > wanted to go all-in for MBIM. Which makes muxing so much easier. > > Wrt useerspace, there is QMAP support in libqmi. Having similar i uqmi > might be nice, but it's probably not the feature most people are > missing. > > > Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH uqmi] nas: add decoding of cell_id
Add decoding of lte_system_info_v2.cid, in --get-system-info, and
intrafrequency_lte_info_v2.global_cell_id, in --get-cell-location-info,
to enodeb_id and cell_id.
h´xyy -> enodeb_id = h´x, cell_id = h´yy
Add decoding of wcdma_system_info_v2.cid, in --get-system-info, to
rnc_id and cell_id.
h´ -> rnc_id = h´, cell_id = h´
Change order to
mcc-mnc-tac/lac-enodeb_id/rnc_id-cell_id.
Signed-off-by: Henrik Ginstmark
---
commands-nas.c | 54 +++---
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..476cd61 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -313,9 +313,8 @@ print_system_info(uint8_t svc_status, uint8_t tsvc_status,
bool preferred, bool
bool service_cap_valid, uint8_t service_cap,
bool roaming_status_valid, uint8_t roaming_status,
bool forbidden_valid, bool forbidden,
- bool lac_valid, uint16_t lac,
- bool cid_valid, uint32_t cid,
- bool network_id_valid, char *mcc, char *mnc)
+ bool network_id_valid, char *mcc, char *mnc,
+ bool lac_valid, uint16_t lac)
{
static const char *map_service[] = {
[QMI_NAS_SERVICE_STATUS_NONE] = "none",
@@ -362,16 +361,14 @@ print_system_info(uint8_t svc_status, uint8_t
tsvc_status, bool preferred, bool
blobmsg_add_string(&status, "roaming_status",
map_roaming[roaming_status]);
if (forbidden_valid)
blobmsg_add_u8(&status, "forbidden", forbidden);
- if (lac_valid)
- blobmsg_add_u32(&status, "location_area_code",
(int32_t) lac);
- if (cid_valid)
- blobmsg_add_u32(&status, "cell_id", (int32_t) cid);
if (network_id_valid) {
blobmsg_add_string(&status, "mcc", mcc);
if ((uint8_t)mnc[2] == 255)
mnc[2] = 0;
blobmsg_add_string(&status, "mnc", mnc);
}
+ if (lac_valid)
+ blobmsg_add_u32(&status, "location_area_code",
(int32_t) lac);
}
}
@@ -405,13 +402,14 @@ cmd_nas_get_system_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct
res.data.gsm_system_info_v2.roaming_status,
res.data.gsm_system_info_v2.forbidden_valid,
res.data.gsm_system_info_v2.forbidden,
- res.data.gsm_system_info_v2.lac_valid,
- res.data.gsm_system_info_v2.lac,
- res.data.gsm_system_info_v2.cid_valid,
- res.data.gsm_system_info_v2.cid,
res.data.gsm_system_info_v2.network_id_valid,
res.data.gsm_system_info_v2.mcc,
- res.data.gsm_system_info_v2.mnc);
+ res.data.gsm_system_info_v2.mnc,
+ res.data.gsm_system_info_v2.lac_valid,
+ res.data.gsm_system_info_v2.lac);
+ if (res.set.gsm_system_info_v2 &&
res.data.gsm_system_info_v2.cid_valid)
+ blobmsg_add_u32(&status, "cell_id",
+ res.data.gsm_system_info_v2.cid);
if (res.set.additional_gsm_system_info &&
res.data.additional_gsm_system_info.geo_system_index !=
0x)
blobmsg_add_u32(&status, "geo_system_index",
@@ -433,13 +431,15 @@ cmd_nas_get_system_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct
res.data.wcdma_system_info_v2.roaming_status,
res.data.wcdma_system_info_v2.forbidden_valid,
res.data.wcdma_system_info_v2.forbidden,
- res.data.wcdma_system_info_v2.lac_valid,
- res.data.wcdma_system_info_v2.lac,
- res.data.wcdma_system_info_v2.cid_valid,
- res.data.wcdma_system_info_v2.cid,
res.data.wcdma_system_info_v2.network_id_valid,
res.data.wcdma_system_info_v2.mcc,
- res.data.wcdma_system_info_v2.mnc);
+ res.data.wcdma_system_info_v2.mnc,
+ res.data.wcdma_system_info_v2.lac_valid,
+ res.data.wcdma_system_info_v2.l
Re: [uqmi] dms: add --get-operating-mode
Hi I'm working for a cellular operator and I have the possibilities to monitor the registration of the modem from the network side. The registration of an LTE terminal is clearly described in the 3GPP specifications and I don´t agree with the options you mention. An LTE terminal can not register with an invalid APN. I have created commands for profile modification. But they are not polished ;) --get-profile-settings : Get APN profile settings (3gpp, 3gpp2),#\n" \ --get-default-profile-number : Get default profile number (3gpp, 3gpp2)\n" \ --modify-profile ,# Modify profile number (3gpp, 3gpp2)\n" \ --apn :Use APN\n" \ --pdp-type ipv4|ipv6|ipv4v6>: Use pdp-type for the connection\n" \ --username : Use network username\n" \ --password : Use network password\n" \ --auth-type pap|chap|both|none: Use network authentication type\n" \ But, if you don't see any benefit with my proposal I´m fine. /Henrik Den sön 5 dec. 2021 kl 18:56 skrev Sergey Ryazanov : > > On Sun, Dec 5, 2021 at 7:43 PM Henrik Ginstmark wrote: > > My intention was to speed up the registration to the LTE network. > > If we talk about a modem that is part of a router, then I doubt > whether the airplane mode activation will be able to speed up the > registration procedure. After a router power on, the main router > firmware should complete its own boot process before it will be able > to switch the modem into airplane mode. But the modem will be powered > in the same time as the router CPU and most probably the modem will > boot faster. So when the main firmware becomes ready, the modem will > be already registered with a network. And triggering the airplane mode > will only delay data communication readiness. > > It would be nice to have the mode configuration command in the uqmi > utility. But toggling the airplane mode in an automatic fashion can be > even dangerous (see below). > > > When the LTE terminal is powered on it will attach with the modem > > default APN profile. If that is empty, then the network will assign the > > network default APN and you get an IP address. > > > > But if the modem default APN is incorrect, or if your operator does not > > assign a default APN, you will be rejected in LTE and the modem will, > > after a while, register to 3G, since you don´t need a valid APN to > > register to 3G. > > Please be more specific, what modem model and operator do we talk > about? As I showed earlier, a modem has a lot of options during > network registration, and earlier community experience suggests that > it is most probable that a modem will register with a network smoothly > even without an earlier preconfigured APN. So we should make our > discussion more specific. > > > But if we verify that the modem default APN is correct, before we do the > > registration, we will be sure that the registration goes smoothly. > > The modem will store the default APN setting. > > When you talking about the default APN did you mean the first > connection profile? There are only two commands that carry APN: > profile creation and network start. Network start should be called > after the network registration completion, while the profile > configuration command is not yet implemented. > > > My proposal to qmi.sh, roughly. > > > > Check PIN > > Check data format 802.3/raw-ip > > Check modem default APN settings > > If the default APN setting are incorrect, > > Airplane mode on > > Change default APN settings > > Airplane mode off > > This is my primary concern. How many modem models will reliably exit > the airplane mode without any issues? > > > Check operator and radio technology > > run --start-network with client_id wds > > > > I don´t think this will break anything and you can still have > > the possibility of adding a secondary APN. > > -- > Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [uqmi] dms: add --get-operating-mode
Hi My intention was to speed up the registration to the LTE network. When the LTE terminal is powered on it will attach with the modem default APN profile. If that is empty, then the network will assign the network default APN and you get an IP address. But if the modem default APN is incorrect, or if your operator does not assign a default APN, you will be rejected in LTE and the modem will, after a while, register to 3G, since you don´t need a valid APN to register to 3G. But if we verify that the modem default APN is correct, before we do the registration, we will be sure that the registration goes smoothly. The modem will store the default APN setting. My proposal to qmi.sh, roughly. Check PIN Check data format 802.3/raw-ip Check modem default APN settings If the default APN setting are incorrect, Airplane mode on Change default APN settings Airplane mode off Check operator and radio technology run --start-network with client_id wds I don´t think this will break anything and you can still have the possibility of adding a secondary APN. /Henrik Den sön 5 dec. 2021 kl 16:12 skrev Sergey Ryazanov : > > On Sun, Dec 5, 2021 at 5:12 PM Bjørn Mork wrote: > > Sergey Ryazanov writes: > >> On Sun, Dec 5, 2021 at 3:32 PM Bjørn Mork wrote: > >>> Sergey Ryazanov writes: > I am, as an occasional user of an LTE modem, never faced a case when > the modem is unable to register with a network due to an unconfigured > APN. The most prominent fact is that no one else ever faced such case > for a 7 years of the uqmi existence. It looks like you either ran into > a very special operator, or you have a buggy modem that is recovered > via the airplane mode. It is also possible that I do not fully > understand your case. > >>> > >>> I agree that this is rare. But I'm pretty sure it can happen. > >>> > >>> A more common case is that the modem picks some arbitrary previously > >>> used APN, e.g. profile #1. This will often be fine. But it can be really > >>> annoying when it isn't. For example becasue that profile was configured > >>> as IPv4 only and you want a dual-stack connection. > >> > >> Should not a modem reestablish a bearer as soon as a user provides a > >> new APN along with the connect QMI command? > > > > I don't know what a modem should do. I only know what I've observed: If > > a modem is attached to a network using an IPv4 only default bearer, then > > you cannot connect a dual stack bearer. You can connect it, but you'll > > only get the IPv4 part of the session up. And connecting an IPv6 only > > APN is impossible in this case. > > Can you reveal what modem model has such nasty behaviour? I personally > test IPv6 with Huawei E3372 (NCM, not QMI) and Sierra MC7304, both of > them work stable. But I can not recall whether they established the > IPv6 connection as soon as a PDP context was reconfigured or I needed > to reattach (power circle) them. Need to recheck someday. > > And do you remember whether the airplane mode was the only option to > configure a new APN or some other operation also help to recover IPv6 > connectivity? E.g. disconnect/connect QMI command or a modem power > circle. > > >>> So flight mode will sometimes be necessary when changing APN. > >> > >> Just to make it clear. Should switching to the airplane mode be a part > >> of connection establishing procedure (i.e. qmi.sh script)? Or would it > >> be enough to have the mode switching command in the uqmi utility? So a > >> user will be able to manually toggle the airplane mode during the APN > >> reconfiguration. > > > > I'm not able to agree with myself here :-) > > > > On one hand, I believe toggling airplane mode after we know the initial > > APN would make this more robust. On the other hand, I fear that kind of > > automatic stuff. > > > > Better leave if for the user as a manual toggle, I guess. > > You just spelled out all my thoughts :) I am also afraid that such > automation will break a lot of modems, since I am not sure how many > modem models will reliably exit the airplane mode. And how many models > would require workarounds like power circle, etc. > > >>> Just don't ever force it. We don't want to lose the ability to connect > >>> to more than one APN (although this probably isn't supported in uqmi yet > >>> since you can't setup QMAP). > >> > >> Do not understand this phrase. How can the airplane mode break a > >> multi-bearer setup? > > > > I don't know if this was the plan or not. But I feared that someone got > > the idea that you could force airplane mode whenever a new APN is > > configured. This would obviously break existing connections. > > Oh, now I got it. Thank you for your clarification. > > >> BTW, when you are talking about QMAP, did you mean utilizing the QMAP > >> demux module from the kernel as it is or implementing the WWAN > >> subsystem ops for the qmi_wwan module. In other words, did you mean > >> protocol or implementation? > > > > I was talkin
Re: [uqmi] dms: add --get-operating-mode
Hi Sergey
Den lör 4 dec. 2021 kl 23:19 skrev Sergey Ryazanov :
>
> Hello Henrik,
>
> On Sat, Dec 4, 2021 at 6:22 PM Henrik Ginstmark wrote:
> > This command make it possible to query if the modem is in flight mode or
> > not.
> >
> > If you need to change your APN setting it should be done during flight mode
> > on.
>
> Just curious, is this true for any Qualcomm based mode or only for a
> specific model?
When an LTE terminal is powered on it needs a valid APN to be able to
register to the
network. Some cellular operators allow an "empty" APN and then set a default APN
to the terminal.
The most optimal way to power on an LTE terminal would be with flight mode on,
check that the correct APN is configured and then set flight mode off.
This is for all LTE terminals.
I have a local uqmi version with commands for checking and modifying
the APN settings.
>
> > To make it possible to automate change of APN setting --get-operating-mode
> > is
> > needed.
> >
> > Signed-off-by: Henrik Ginstmark
>
> Your patch seems broken. Consider using git-format-patch and
> git-send-email to prepare and submit the patch, please.
Sorry, I´m new to this. Do you know where I can find information about
git-format-patch and git-send-email? What I understand is uqmi a sub-project
to openwrt, or?
I´m still learning C. I will try to optimize the code in a better way.
>
> BTW, it is a good idea to keep the 'PATCH' word in the subject line,
> so patchwork (https://patchwork.ozlabs.org/project/openwrt/list/) will
> be able to catch your patch. Something like this:
>
> [PATCH uqmi] dms: add --get-operating-mode
>
> See also a couple of nit picks below.
>
> > commands-dms.c
> >
> > @@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_m
> > return QMI_CMD_REQUEST;
> > }
> >
> > +static void
> > +cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
> > *req, struct qmi_msg *msg)
> > +{
> > +struct qmi_dms_get_operating_mode_response res;
> > +
>
> This empty line is odd.
>
> > +const char *modes[] = {
>
> You could reuse 'modes' from the cmd_dms_set_operating_mode_prepare()
> to avoid duplication. Just move the array out from the function and
> call it something like 'oper_modes'.
>
> > +[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
> > +[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
> > +[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
> > +[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
> > +[QMI_DMS_OPERATING_MODE_RESET] = "reset",
> > +[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
> > +[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] =
> > "persistent_low_power",
> > +[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] =
> > "mode_only_low_power",
> > +};
> > +int s = 0;
>
> This is a magic number usage. Also if a modem returns unknown value
> then the code below will report that the modem is 'online'. What can
> be misleading. See the 'get_pin_status()' function for an example of
> an unknown value handling.
>
> > +
> > +qmi_parse_dms_get_operating_mode_response(msg, &res);
> > +if (res.set.mode &&
>
> This part of the check looks odd. If res.set.mode is zero you skip the
> 's' variable updation, but s is initialized with zero during the
> definition.
>
> > +res.data.mode < ARRAY_SIZE(modes))
> > +s = res.data.mode;
> > +
> > +blobmsg_add_string(&status, NULL, modes[s]);
> > +}
> > +
> > +static enum qmi_cmd_result
> > +cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_msg *msg, char *arg)
> > +{
> > +qmi_set_dms_get_operating_mode_request(msg);
> > +return QMI_CMD_REQUEST;
> > +}
> > +
> > #define cmd_dms_set_operating_mode_cb no_cb
> > static enum qmi_cmd_result
> > cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
> > qmi_request *req, struct qmi_msg *msg, char *arg)
> >
> >
> > ---
> >
> > commands-dms.h
> >
> > @@ -37,6 +37,7 @@
> > __uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
> > __uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
> > __uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
> > + __uqmi_command(dms_get_operating_mode
[uqmi] dms: add --get-operating-mode
dms: add --get-operating-mode
This command make it possible to query if the modem is in flight mode or not.
If you need to change your APN setting it should be done during flight mode on.
To make it possible to automate change of APN setting --get-operating-mode is
needed.
Signed-off-by: Henrik Ginstmark
---
commands-dms.c
@@ -375,6 +375,38 @@ cmd_dms_reset_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_m
return QMI_CMD_REQUEST;
}
+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
+{
+struct qmi_dms_get_operating_mode_response res;
+
+const char *modes[] = {
+[QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+[QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+[QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+[QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+[QMI_DMS_OPERATING_MODE_RESET] = "reset",
+[QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+[QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+[QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+};
+int s = 0;
+
+qmi_parse_dms_get_operating_mode_response(msg, &res);
+if (res.set.mode &&
+res.data.mode < ARRAY_SIZE(modes))
+s = res.data.mode;
+
+blobmsg_add_string(&status, NULL, modes[s]);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
+{
+qmi_set_dms_get_operating_mode_request(msg);
+return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
---
commands-dms.h
@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+ __uqmi_command(dms_get_operating_mode, get-device-operating-mode,
no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode, set-device-operating-mode,
required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no, QMI_SERVICE_DMS) \
@@ -67,6 +68,7 @@
" --get-imei: Get International Mobile
Equipment ID\n" \
" --get-msisdn: Get the MSISDN (telephone
number)\n" \
" --reset-dms: Reset the DMS service\n" \
+ " --get-device-operating-mode Get the device operating mode\n" \
" --set-device-operating-modeSet the device operating mode\n" \
"(modes: online,
low_power, factory_test, offline\n" \
" reset, shutting_down,
persistent_low_power,\n" \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uqmi: add dms_get_operating_mode
Hi
Is it possible to add dms_get_operating_mode command?
Then it would be possible to verify if the modem is in flight mode or not.
Or how can I contribute to uqmi?
BR
Henrik Ginstmark
---
commands-dms.c
@@ -375,6 +375,38 @@ qmi_set_dms_reset_request(msg);
return QMI_CMD_REQUEST;
}
+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
+{
+ struct qmi_dms_get_operating_mode_response res;
+
+ const char *modes[] = {
+ [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+ [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+ [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+ [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+ [QMI_DMS_OPERATING_MODE_RESET] = "reset",
+ [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+ [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+ [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+ };
+ int s = 0;
+
+ qmi_parse_dms_get_operating_mode_response(msg, &res);
+ if (res.set.mode &&
+res.data.mode < ARRAY_SIZE(modes))
+ s = res.data.mode;
+
+ blobmsg_add_string(&status, NULL, modes[s]);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_operating_mode_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
---
commands-dms.h
@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+ __uqmi_command(dms_get_operating_mode,
get-device-operating-mode, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode,
set-device-operating-mode, required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no,
QMI_SERVICE_DMS) \
@@ -67,6 +58,7 @@
" --get-imei: Get International
Mobile Equipment ID\n" \
" --get-msisdn: Get the MSISDN
(telephone number)\n" \
" --reset-dms: Reset the DMS service\n" \
+ " --get-device-operating-mode Get the device
operating mode\n" \
" --set-device-operating-modeSet the device
operating mode\n" \
"(modes: online,
low_power, factory_test, offline\n" \
"
reset,shutting_down, persistent_low_power,\n" \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
Hi
Is it possible to add dms_get_operating_mode command?
Then it would be possible to verify if the modem is in flight mode or not.
BR
Henrik Ginstmark
---
commands-dms.c
@@ -375,6 +375,38 @@ qmi_set_dms_reset_request(msg);
return QMI_CMD_REQUEST;
}
+static void
+cmd_dms_get_operating_mode_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
+{
+ struct qmi_dms_get_operating_mode_response res;
+
+ const char *modes[] = {
+ [QMI_DMS_OPERATING_MODE_ONLINE] = "online",
+ [QMI_DMS_OPERATING_MODE_LOW_POWER] = "low_power",
+ [QMI_DMS_OPERATING_MODE_FACTORY_TEST] = "factory_test",
+ [QMI_DMS_OPERATING_MODE_OFFLINE] = "offline",
+ [QMI_DMS_OPERATING_MODE_RESET] = "reset",
+ [QMI_DMS_OPERATING_MODE_SHUTTING_DOWN] = "shutting_down",
+ [QMI_DMS_OPERATING_MODE_PERSISTENT_LOW_POWER] = "persistent_low_power",
+ [QMI_DMS_OPERATING_MODE_MODE_ONLY_LOW_POWER] = "mode_only_low_power",
+ };
+ int s = 0;
+
+ qmi_parse_dms_get_operating_mode_response(msg, &res);
+ if (res.set.mode &&
+res.data.mode < ARRAY_SIZE(modes))
+ s = res.data.mode;
+
+ blobmsg_add_string(&status, NULL, modes[s]);
+}
+
+static enum qmi_cmd_result
+cmd_dms_get_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
+{
+ qmi_set_dms_get_operating_mode_request(msg);
+ return QMI_CMD_REQUEST;
+}
+
#define cmd_dms_set_operating_mode_cb no_cb
static enum qmi_cmd_result
cmd_dms_set_operating_mode_prepare(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg, char *arg)
---
commands-dms.h
@@ -37,6 +37,7 @@
__uqmi_command(dms_get_imsi, get-imsi, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_imei, get-imei, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_get_msisdn, get-msisdn, no, QMI_SERVICE_DMS), \
+ __uqmi_command(dms_get_operating_mode,
get-device-operating-mode, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_operating_mode,
set-device-operating-mode, required, QMI_SERVICE_DMS), \
__uqmi_command(dms_reset, reset-dms, no, QMI_SERVICE_DMS), \
__uqmi_command(dms_set_fcc_authentication, fcc-auth, no,
QMI_SERVICE_DMS) \
@@ -67,6 +58,7 @@
" --get-imei: Get International
Mobile Equipment ID\n" \
" --get-msisdn: Get the MSISDN
(telephone number)\n" \
" --reset-dms: Reset the DMS service\n" \
+ " --get-device-operating-mode Get the device
operating mode\n" \
" --set-device-operating-modeSet the device
operating mode\n" \
"(modes: online,
low_power, factory_test, offline\n" \
" reset,
shutting_down, persistent_low_power,\n" \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
