Telit LE910V1 - LTE only modem

Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Piotr Haber]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

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.

[PATCH] support Telit LE910 modem

[Piotr Haber]

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

---
 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

Re: Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

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.
> 
> 
> 

Re: Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

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.
> 
> 
> 

Re: Telit LE910V1 - LTE only modem

[gluedig]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

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.
>>
>>
>>

Re: Telit LE910V1 - LTE only modem

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 3606 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 3118 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

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

Re: Telit LE910V1 - LTE only modem

[Lukasz Nowak]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

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