5:35 a.m.
Hi,
I am working on enabling a Telit LE910-SVG modem with ofono. It is LE910 V1 which is
completely different to LE910 V2. This is a modem which only has LTE data, no GSM/UMTS, no
CDMA.
I have hit a problem as it appears to register only to a GPRS network - not to a
"normal" one:
AT+CREG?
+CREG: 2,0
AT+CGREG?
+CGREG: 2,1,"3B01","E6A903",7,3D
I am using atmodem and it does not even check +CGREG when it gets +CREG: 2,0:
ofonod[2909]: Aux: > AT+CREG?\r
ofonod[2909]: Aux: < \r\n+CREG: 2,0\r\n\r\nOK\r\n
ofonod[2909]: ../git/src/network.c:ofono_netreg_status_notify() /telit_0 status 0 tech -1
ofonod[2909]: ../git/src/network.c:current_operator_callback() 0x56851870, 0
ofonod[2909]: ../git/src/gprs.c:netreg_status_changed() 0
ofonod[2909]: ../git/src/gprs.c:gprs_netreg_update() attach: 0, driver_attached: 0
Has such a modem been used with ofono before?
I would appreciate any pointers how to tackle this issue.
Thanks.
Lukasz
8:32 p.m.
Hi Lukasz,
I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem.
It uses QMI interface and is End-of-life product according to Telit.
Below is a patch I used to add support for it, maybe it will help you.
Modem is not recognized automatically, you need to point ofono to use correct driver
by setting ENV{OFONO_DRIVER}="le910" in udev.
8:32 p.m.
New subject: [PATCH] support Telit LE910 modem
---
drivers/qmimodem/devinfo.c | 2 +-
plugins/gobi.c | 26 ++++++++++++++------------
plugins/udevng.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/drivers/qmimodem/devinfo.c b/drivers/qmimodem/devinfo.c
index 34aec94a..9f0f1259 100644
--- a/drivers/qmimodem/devinfo.c
+++ b/drivers/qmimodem/devinfo.c
@@ -125,7 +125,7 @@ static void get_ids_cb(struct qmi_result *result, void *user_data)
}
str = qmi_result_get_string(result, QMI_DMS_RESULT_ESN);
- if (!str) {
+ if (!str || strcmp(str, "0") == 0) {
str = qmi_result_get_string(result, QMI_DMS_RESULT_IMEI);
if (!str) {
CALLBACK_WITH_FAILURE(cb, NULL, cbd->data);
diff --git a/plugins/gobi.c b/plugins/gobi.c
index 6a789411..dc53f92a 100644
--- a/plugins/gobi.c
+++ b/plugins/gobi.c
@@ -167,22 +167,24 @@ static void get_oper_mode_cb(struct qmi_result *result, void
*user_data)
}
data->oper_mode = mode;
-
switch (data->oper_mode) {
case QMI_DMS_OPER_MODE_ONLINE:
- param = qmi_param_new_uint8(QMI_DMS_PARAM_OPER_MODE,
- QMI_DMS_OPER_MODE_PERSIST_LOW_POWER);
- if (!param) {
+ if (ofono_modem_get_boolean(modem, "AlwaysOnline") != TRUE) {
+ DBG("set QMI_DMS_OPER_MODE_PERSIST_LOW_POWER");
+ param = qmi_param_new_uint8(QMI_DMS_PARAM_OPER_MODE,
+ QMI_DMS_OPER_MODE_PERSIST_LOW_POWER);
+ if (!param) {
+ shutdown_device(modem);
+ return;
+ }
+
+ if (qmi_service_send(data->dms, QMI_DMS_SET_OPER_MODE, param,
+ power_reset_cb, modem, NULL) > 0)
+ return;
+
shutdown_device(modem);
- return;
+ break;
}
-
- if (qmi_service_send(data->dms, QMI_DMS_SET_OPER_MODE, param,
- power_reset_cb, modem, NULL) > 0)
- return;
-
- shutdown_device(modem);
- break;
default:
ofono_modem_set_powered(modem, TRUE);
break;
diff --git a/plugins/udevng.c b/plugins/udevng.c
index 2279bbe9..b3c4bc74 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -218,6 +218,51 @@ static gboolean setup_gobi(struct modem_info *modem)
return TRUE;
}
+static gboolean setup_le910(struct modem_info *modem)
+{
+ const char *qmi = NULL, *mdm = NULL, *net = NULL, *aux = NULL;
+ GSList *list;
+
+ DBG("%p %s", modem, modem->syspath);
+
+ for (list = modem->devices; list; list = list->next) {
+ struct device_info *info = list->data;
+
+ DBG("%s %s %s %s %s", info->devnode, info->interface,
+ info->number, info->label, info->subsystem);
+
+ if (g_strcmp0(info->interface, "255/255/255") == 0) {
+ if (g_strcmp0(info->number, "02") == 0) {
+ if (g_strcmp0(info->subsystem, "net") == 0)
+ net = info->devnode;
+ else if (g_strcmp0(info->subsystem, "usbmisc") == 0)
+ qmi = info->devnode;
+ }
+ } else if (g_strcmp0(info->interface, "255/0/0") == 0) {
+ if (g_strcmp0(info->number, "04") == 0)
+ mdm = info->devnode;
+ else if (g_strcmp0(info->number, "05") == 0)
+ aux = info->devnode;
+ }
+ }
+
+ if (qmi == NULL || mdm == NULL || net == NULL)
+ return FALSE;
+
+ DBG("qmi=%s net=%s", qmi, net);
+ DBG("mdm=%s aux=%s", mdm, aux);
+
+ ofono_modem_set_string(modem->modem, "Device", qmi);
+ ofono_modem_set_string(modem->modem, "Modem", mdm);
+ ofono_modem_set_string(modem->modem, "NetworkInterface", net);
+ ofono_modem_set_string(modem->modem, "Aux", aux);
+ ofono_modem_set_boolean(modem->modem, "ForceSimLegacy", TRUE);
+ ofono_modem_set_boolean(modem->modem, "AlwaysOnline", TRUE);
+ ofono_modem_set_driver(modem->modem, "gobi");
+
+ return TRUE;
+}
+
static gboolean setup_sierra(struct modem_info *modem)
{
const char *mdm = NULL, *app = NULL, *net = NULL, *diag = NULL, *qmi = NULL;
@@ -942,6 +987,7 @@ static struct {
{ "mbm", setup_mbm, "device/interface" },
{ "hso", setup_hso, "hsotype" },
{ "gobi", setup_gobi },
+ { "le910", setup_le910 },
{ "sierra", setup_sierra },
{ "option", setup_option },
{ "huawei", setup_huawei },
--
2.11.0
11:57 p.m.
Hi Piotr,
Thanks for the QMI patch. I will try it out, and if I manage to get it to work with the
SVG modem, maybe it can be submitted to the main ofono code base.
I think vid/pid can be added to the list of devices in udevng.c to force the qmimodem
driver to load.
btw I am being told that at least the SVG variant (Verizon) hardware is not EOLed by Telit
currently.
Lukasz
On 16/03/17 09:32, Piotr Haber wrote:
Hi Lukasz,
I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem.
It uses QMI interface and is End-of-life product according to Telit.
Below is a patch I used to add support for it, maybe it will help you.
Modem is not recognized automatically, you need to point ofono to use correct driver
by setting ENV{OFONO_DRIVER}="le910" in udev.
12:19 a.m.
Hi Piotr, Denis,
With the qmimodem patch I was able to bring the LE910-SVG modem on-line.
But I had to do two things:
1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()
if (ofono_netreg_get_technology(gprs->netreg) ==
ACCESS_TECHNOLOGY_EUTRAN)
/*
* For LTE we set attached status only on successful
* context activation.
*/
return;
means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and
that
gets everything attached and working.
b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND,
ss_info_notify)
But then, ss_info_notify() is never called. I think that the modem is quick enough to
register
to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.
c) Denis, you mentioned that I need to call ofono_gprs_cid_activated()
Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?
2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted
operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong (later
on, dbus
aborts the entire ofono process, saying this is not a valid utf-8 string).
plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)
Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not
the right way to handle this.
Thanks for all your help with this.
Lukasz
On 16/03/17 09:32, Piotr Haber wrote:
Hi Lukasz,
I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem.
It uses QMI interface and is End-of-life product according to Telit.
Below is a patch I used to add support for it, maybe it will help you.
Modem is not recognized automatically, you need to point ofono to use correct driver
by setting ENV{OFONO_DRIVER}="le910" in udev.
12:32 a.m.
On 03/20/2017 02:19 PM, Lukasz Nowak wrote:
Hi Piotr, Denis,
With the qmimodem patch I was able to bring the LE910-SVG modem on-line.
But I had to do two things:
1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()
if (ofono_netreg_get_technology(gprs->netreg) ==
ACCESS_TECHNOLOGY_EUTRAN)
/*
* For LTE we set attached status only on successful
* context activation.
*/
return;
means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and
that
gets everything attached and working.
b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND,
ss_info_notify)
But then, ss_info_notify() is never called. I think that the modem is quick enough to
register
to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.
c) Denis, you mentioned that I need to call ofono_gprs_cid_activated()
Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?
2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted
operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong
(later on, dbus
aborts the entire ofono process, saying this is not a valid utf-8 string).
plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)
Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not
the right way to handle this.
Hi,
I have observed that as well for some networks/sims.
I assume this is due some idiosyncrasy of Telit's QMI implementation.
And since I was not able to obtain any help form Telit regarding QMI
(not even documentation) I accepted that and patched extract_ss_info to
rewrite plmm->desc as "mcc:mnc".
Thanks for all your help with this.
Lukasz
On 16/03/17 09:32, Piotr Haber wrote:
> Hi Lukasz,
>
> I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem.
> It uses QMI interface and is End-of-life product according to Telit.
> Below is a patch I used to add support for it, maybe it will help you.
>
> Modem is not recognized automatically, you need to point ofono to use correct
driver
> by setting ENV{OFONO_DRIVER}="le910" in udev.
>
>
>
1:39 a.m.
Hi Lukasz,
On 03/20/2017 08:19 AM, Lukasz Nowak wrote:
Hi Piotr, Denis,
With the qmimodem patch I was able to bring the LE910-SVG modem on-line.
But I had to do two things:
So it looks like the LE910 is a Qualcomm chip / firmware, funny.
1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()
if (ofono_netreg_get_technology(gprs->netreg) ==
ACCESS_TECHNOLOGY_EUTRAN)
/*
* For LTE we set attached status only on successful
* context activation.
*/
return;
means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and
that
gets everything attached and working.
Strictly speaking this statement is correct. In LTE there's really no
concept of 'attached'. We're attached by the virtue of getting onto the
LTE network (the default bearer is always available). So there should
be no need to explicitly issue a set_attached method.
b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND,
ss_info_notify)
But then, ss_info_notify() is never called. I think that the modem is quick enough to
register
to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.
c) Denis, you mentioned that I need to call ofono_gprs_cid_activated()
Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?
your gprs.c atom driver.
2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted
operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong
(later on, dbus
aborts the entire ofono process, saying this is not a valid utf-8 string).
plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)
Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not
the right way to handle this.
I have not played with QMI enough to give any guidance. You might want
to look at libqmi to see if they handle this differently.
Regards,
-Denis
3:46 a.m.
Hi Denis,
On 20/03/17 14:39, Denis Kenzior wrote:
Hi Lukasz,
On 03/20/2017 08:19 AM, Lukasz Nowak wrote:
> Hi Piotr, Denis,
>
> With the qmimodem patch I was able to bring the LE910-SVG modem on-line.
> But I had to do two things:
So it looks like the LE910 is a Qualcomm chip / firmware, funny.
Yes, it appears to
be a Qualcomm chip, but the firmware is a mixture - it has a Telit AT command set, very
similar to other Telit modems (only that CREG never goes registered). But it additionally
exposes a qmi_wwan usb device.
>
> 1. The gprs driver was never getting attached.
> a) This statement in src/gprs.c, gprs_netreg_update()
> if (ofono_netreg_get_technology(gprs->netreg) ==
> ACCESS_TECHNOLOGY_EUTRAN)
> /*
> * For LTE we set attached status only on successful
> * context activation.
> */
> return;
> means that the gprs->driver_attached is never set to true.
> If I remove this piece of code, the gprs->driver->set_attached() gets called,
and that
> gets everything attached and working.
Strictly speaking this statement is correct. In LTE there's really no concept of
'attached'. We're attached by the virtue of getting onto the LTE network (the
default bearer is always available). So there should be no need to explicitly issue a
set_attached method.
The current qmimodem code, calls
ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a
notification from the modem that it is fully connected. Is that the correct path to make
the gprs context marked as "attached"?
If that does not happen, all the dbus context APIs just return an error, and as a result,
e.g. connman does not enable the cellular service.
I can add a change to qmimodem, which will explicitly ask the modem firmware if it is
connected, from qmi_gprs_probe() rather than waiting on a state change notification, which
never arrives.
Does that make sense?
How do you usually test such changes for regressions? I do not have any other QMI modems,
to verify if I have broken anything in them or not. I think the change should be safe, but
I cannot be 100% certain.
>
> b) I can see, that another path to it would be:
> qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND,
ss_info_notify)
> But then, ss_info_notify() is never called. I think that the modem is quick enough to
register
> to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.
>
> c) Denis, you mentioned that I need to call ofono_gprs_cid_activated()
> Which piece of code should do that? qmimodem/network-registration.c or
plugins/gobi.c?
>
your gprs.c atom driver.
>
> 2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted
> operator name:
> plmn->desc_len = 3
> plmn->desc[] = { 0x56, 0xfd, 0x15 }
> The first byte seems correct ('V' for Verizon), but the other two are wrong
(later on, dbus
> aborts the entire ofono process, saying this is not a valid utf-8 string).
> plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)
>
> Have you ever seen anything like that?
> If I replace the invalid characters, everything works ok. But I imagine this is not
> the right way to handle this.
>
I have not played with QMI enough to give any guidance. You might want to look at libqmi
to see if they handle this differently.
I will check libqmi and then propose a
patch, sanitizing the operator name string.
Regards,
-Denis
10:39 a.m.
Hi Lukasz,
> Strictly speaking this statement is correct. In LTE there's
really no concept of 'attached'. We're attached by the virtue of getting onto
the LTE network (the default bearer is always available). So there should be no need to
explicitly issue a set_attached method.
The current qmimodem code, calls
ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a
notification from the modem that it is fully connected. Is that the correct path to make
the gprs context marked as "attached"?
If that does not happen, all the dbus context APIs just return an error, and as a result,
e.g. connman does not enable the cellular service.
So as it is today, oFono for LTE expects the following:
ofono_gprs_status_notify(with registered / roaming)
and ofono_gprs_cid_activated() for the default bearer.
The gprs-context driver must then implement read_settings method. LTE
is weird since the contexts can be network activated. The default
bearer is 'activated' by the modem firmware itself by virtue of
obtaining the LTE network registration. The logic is quite different
compared to 2G/3G.
If you know your AT commands, see how the ubloxmodem driver does this.
Pay attention to drivers/atmodem/gprs.c cgev_notify() and
drivers/ubloxmodem/gprs-context.c.
We also now have an lte atom. See doc/lte-api.txt for details.
If the above isn't possible for QMI, then we might need to tweak the
core logic (e.g. src/gprs.c) accordingly.
Please note that qmimodem driver was developed when we didn't have lte
support, so the logic in there is probably incorrect / inadequate.
I can add a change to qmimodem, which will explicitly ask the modem
firmware if it is connected, from qmi_gprs_probe() rather than waiting on a state change
notification, which never arrives.
Does that make sense?
How do you usually test such changes for regressions? I do not have any other QMI modems,
to verify if I have broken anything in them or not. I think the change should be safe, but
I cannot be 100% certain.
We try to catch most regressions during the patch review process. In
the past we had some QA resources performing manual tests, but these
resources are no longer available. Easiest might be to order a few qmi
modems and check if your patches break them :)
Regards,
-Denis
4:50 a.m.
Hi Denis, Piotr,
I have just submitted a patch. Piotr, you probably should add your sign-off on it, as
about half of it came directly from you.
I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can see
only atmodem calls it. No other driver does that.
The flow of user calling create-internet-context and activate-context seems to work fine
with my patch.
I am not sure if a context is automatically created. I can see that the sim card has a few
profiles, and the user can select which APN to use, start/stop ip network, etc.
Let me know if what I coded is ok. I am happy to make changes as required.
Thanks.
Lukasz
On 20/03/17 23:39, Denis Kenzior wrote:
Hi Lukasz,
>> Strictly speaking this statement is correct. In LTE there's really no
concept of 'attached'. We're attached by the virtue of getting onto the LTE
network (the default bearer is always available). So there should be no need to
explicitly issue a set_attached method.
>
> The current qmimodem code, calls
ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a
notification from the modem that it is fully connected. Is that the correct path to make
the gprs context marked as "attached"?
> If that does not happen, all the dbus context APIs just return an error, and as a
result, e.g. connman does not enable the cellular service.
>
So as it is today, oFono for LTE expects the following:
ofono_gprs_status_notify(with registered / roaming)
and ofono_gprs_cid_activated() for the default bearer.
The gprs-context driver must then implement read_settings method. LTE is weird since the
contexts can be network activated. The default bearer is 'activated' by the modem
firmware itself by virtue of obtaining the LTE network registration. The logic is quite
different compared to 2G/3G.
If you know your AT commands, see how the ubloxmodem driver does this. Pay attention to
drivers/atmodem/gprs.c cgev_notify() and drivers/ubloxmodem/gprs-context.c.
We also now have an lte atom. See doc/lte-api.txt for details.
If the above isn't possible for QMI, then we might need to tweak the core logic (e.g.
src/gprs.c) accordingly.
Please note that qmimodem driver was developed when we didn't have lte support, so
the logic in there is probably incorrect / inadequate.
> I can add a change to qmimodem, which will explicitly ask the modem firmware if it is
connected, from qmi_gprs_probe() rather than waiting on a state change notification, which
never arrives.
> Does that make sense?
>
> How do you usually test such changes for regressions? I do not have any other QMI
modems, to verify if I have broken anything in them or not. I think the change should be
safe, but I cannot be 100% certain.
>
We try to catch most regressions during the patch review process. In the past we had
some QA resources performing manual tests, but these resources are no longer available.
Easiest might be to order a few qmi modems and check if your patches break them :)
Regards,
-Denis
5:57 a.m.
Hi Lukasz,
I am still a little bit confused about ofono_gprs_cid_activated(). As
far as I can see only atmodem calls it. No other driver does that.
That's because only the ublox devices have been properly enabled for LTE :)
I am not sure if a context is automatically created. I can see that
the sim card has a few profiles, and the user can select which APN to use, start/stop ip
network, etc.
Yes, that's how LTE works. An initial context (default bearer) is
always activated on LTE. The device can provide an initial attach APN
(see doc/lte-api.txt) which is used to tell the modem which APN to
attach to by default. From what I recall, the device can provide an
empty APN (in which case the network assigns one).
The default bearer varies by the carrier. Some use it for IMS, some use
it for the internet context. So the modem/firmware behavior is often
tweaked for a particular carrier. Some modems might not report the
default context at all in which case the device acts more like a 3G
modem than an lte one.
Regards,
-Denis
5:23 a.m.
Hi Denis,
I investigated this further today. The Telit modem exposes two interfaces AT commands and
QMI.
What you are describing matches what the AT interface reports:
- modem powers on already registered to the network with 5 contexts, and one of them is
active
However, the QMI interface is quite different. None of the "profiles" as QMI
calls them is active.
The user needs to explicitly activate one of them with a "start network"
command. Without that,
the modem's data service (WDS) appears off-line.
For now, I left it the way the original qmimodem code works - the user provides an APN.
This works fine - the QMI "start network" command uses the user's entry from
a context, and
the modem is happy with that.
As an enhancement the wds-get-default-settings command could be used to pre-fill the
context
with APN, IP type and auth. But the ofono gprs context still needs to be activated in
order
to send the QMI "start network" command.
Lukasz
On 21/03/17 18:57, Denis Kenzior wrote:
Hi Lukasz,
> I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can
see only atmodem calls it. No other driver does that.
That's because only the ublox devices have been properly enabled for LTE :)
> I am not sure if a context is automatically created. I can see that the sim card has
a few profiles, and the user can select which APN to use, start/stop ip network, etc.
Yes, that's how LTE works. An initial context (default bearer) is always activated
on LTE. The device can provide an initial attach APN (see doc/lte-api.txt) which is used
to tell the modem which APN to attach to by default. From what I recall, the device can
provide an empty APN (in which case the network assigns one).
The default bearer varies by the carrier. Some use it for IMS, some use it for the
internet context. So the modem/firmware behavior is often tweaked for a particular
carrier. Some modems might not report the default context at all in which case the device
acts more like a 3G modem than an lte one.
Regards,
-Denis
2006
days inactive
2013
days old
11 comments
4 participants
participants (4)
-
Denis Kenzior -
gluedig＠gmail.com -
Lukasz Nowak -
Piotr Haber