Re: Ofono LTE modems and connman services
Hi Jonas,
On 02/26/2018 05:12 PM, Denis Kenzior wrote:
Hi Jonas,
On 02/26/2018 08:37 AM, Jonas Bonn wrote:
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the
ofono and connman mailing lists because it's not really clear to me
who's doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman
step, setting the ofono context to Active, is not required for LTE;
the context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE
modem that does not auto-connect (in connman terms).
There are multiple possible scenarios here, the two most common ones are:
1. Default attach APN is an internet context
2. Default attach APN is an IMS context
The network provider usually behaves in way 1 or 2 above. We can
control the default attach context to some degree by using
org.ofono.LongTermEvolution.DefaultAccessPointName
For this to work nicely you really need automatic context provisioning
to work so that the various APN types are known ahead of time.
Either way, when the context is auto activated by the modem it should
tell what APN ended up being used. Ideally that APN _should_ match
one of the provisioned contexts.
Now the APN that ofono sets on the LTE context is 'automatic'; that
was selected because connman _requires_ some APN or else it ignores
the context altogther.
That would seem to be a driver issue. drivers/qmimodem/gprs-context.c
even has a TODO entry in there...
If the modem roams away from LTE connectivity and wants to fallback
to UMTS/GSM, it needs another context with a valid APN. So now the
modem has two 'internet' contexts ('automatic' and APN) which connman
presents as two distinct services.
This is obviously wrong. If the modem roams onto 3G then the contexts
should be preserved. There should still be a single internet context...
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered
context is the 3G context, connman goes into an endless loop
attempting to set it Active and continuously failing when the tech
switches to LTE.
Yeah, no wonder...
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts
since it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM
networks when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online;
what implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
The answer is to just fix your oFono driver.
I had this issue with QMI modems. As a workaround, I have disabled
auto-activation. This is just a workaround but here is my local patch:
From aaee53f19adbf7a4dca00366f6f7ae2ddfd4b580 Mon Sep 17 00:00:00 2001
From: Christophe Ronco
Date: Tue, 9 May 2017 17:02:45 +0200
Subject: [PATCH] qmimodem: no automatic activation in LTE
If a SIM connects in LTE and if an APN is provisionned for
this SIM, we end with 2 contexts, one automatically activated
and the other ready to be activated.
That's confusing for connman. To avoid that, simply avoid
automatic connection if techno is LTE.
That's only a workaround because LTE should work without any APN
provisioned.
diff --git a/drivers/qmimodem/gprs.c b/drivers/qmimodem/gprs.c
index a80d55f..51909cd 100644
--- a/drivers/qmimodem/gprs.c
+++ b/drivers/qmimodem/gprs.c
@@ -74,17 +74,17 @@ static int handle_ss_info(struct qmi_result *result,
struct ofono_gprs *gprs)
if (!extract_ss_info(result, &status, &tech))
return -1;
- if (status == NETWORK_REGISTRATION_STATUS_REGISTERED)
- if (tech == ACCESS_TECHNOLOGY_EUTRAN) {
- /* On LTE we are effectively always attached; and
- * the default bearer is established as soon as the
- * network is joined.
- */
- /* FIXME: query default profile number and APN
- * instead of assuming profile 1 and ""
- */
- ofono_gprs_cid_activated(gprs, 1 , "automatic");
- }
+ //if (status == NETWORK_REGISTRATION_STATUS_REGISTERED)
+ //if (tech == ACCESS_TECHNOLOGY_EUTRAN) {
+ ///* On LTE we are effectively always attached; and
+ //* the default bearer is established as soon as the
+ //* network is joined.
+ //*/
+ ///* FIXME: query default p
Re: Ofono LTE modems and connman services
Hi Jonas,
On 02/26/2018 08:37 AM, Jonas Bonn wrote:
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
There are multiple possible scenarios here, the two most common ones are:
1. Default attach APN is an internet context
2. Default attach APN is an IMS context
The network provider usually behaves in way 1 or 2 above. We can
control the default attach context to some degree by using
org.ofono.LongTermEvolution.DefaultAccessPointName
For this to work nicely you really need automatic context provisioning
to work so that the various APN types are known ahead of time.
Either way, when the context is auto activated by the modem it should
tell what APN ended up being used. Ideally that APN _should_ match one
of the provisioned contexts.
Now the APN that ofono sets on the LTE context is 'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
That would seem to be a driver issue. drivers/qmimodem/gprs-context.c
even has a TODO entry in there...
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
This is obviously wrong. If the modem roams onto 3G then the contexts
should be preserved. There should still be a single internet context...
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
Yeah, no wonder...
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
The answer is to just fix your oFono driver.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
Ofono LTE modems and connman services
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
Now the APN that ofono sets on the LTE context is 'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
Thanks,
Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
Re: Issue with service reporting on a 4G modem
Hi Bassem, On 26.02.2018 13:16, Bassem BOUBAKER wrote: > Issue is fixed. Thank you for your help. Glad to hear you could fix it. > I used to have this: > # cat /sys/class/net/usb0/uevent > INTERFACE=usb0 > IFINDEX=7 > > I changed my driver in the kernel to probe it as a wwan info device based on > vid and pid . > > Now I have the DEVTYPE correct: > # cat /sys/class/net/wwan0/uevent > DEVTYPE=wwan > INTERFACE=wwan0 > IFINDEX=7 > > > Below my kernel patch in case of anyone having the same issue. > > PS: I'm using a Cinterion PLS8 modem. Please also create a patch for Linux upstream. You are almost there. Just add a commit message and send it to the right mailing list :) Thanks, Daniel ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
RE: Issue with service reporting on a 4G modem
Hi Daniel,
Issue is fixed. Thank you for your help.
I used to have this:
# cat /sys/class/net/usb0/uevent
INTERFACE=usb0
IFINDEX=7
I changed my driver in the kernel to probe it as a wwan info device based on
vid and pid .
Now I have the DEVTYPE correct:
# cat /sys/class/net/wwan0/uevent
DEVTYPE=wwan
INTERFACE=wwan0
IFINDEX=7
Below my kernel patch in case of anyone having the same issue.
PS: I'm using a Cinterion PLS8 modem.
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index b1897c7..b1c29c2 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -480,7 +480,7 @@ static const struct driver_info wwan_info = {
#define ZTE_VENDOR_ID 0x19D2
#define DELL_VENDOR_ID 0x413C
#define REALTEK_VENDOR_ID 0x0bda
-
+#define GEMALTO_VENDOR_ID 0x1e2d
static const struct usb_device_id products [] = {
/*
* BLACKLIST !!
@@ -709,6 +709,17 @@ static const struct usb_device_id products [] = {
.bInterfaceProtocol= USB_CDC_PROTO_NONE,
.driver_info = (unsigned long)&wwan_info,
}, {
+ /* Cinterion pls8 by GEMALTO */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR
+ | USB_DEVICE_ID_MATCH_PRODUCT
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = GEMALTO_VENDOR_ID,
+ .idProduct = 0x0061,
+ .bInterfaceClass= USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long)&wwan_info,
+},{
/* Telit modules */
USB_VENDOR_AND_INTERFACE_INFO(0x1bc7, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
Thanks,
Bassem.
>Hi Bassem,
>
>On 02/20/2018 10:44 AM, Bassem BOUBAKER wrote:
>> Hello Daniel,
>>
>> Exactly, my modem is creating an additional ethernet interface, and I don't
>> know why.
>>
>> Please find in the link below the full log of connman.
>>
>> https://ufile.io/dmgbw
>
>Feb 20 08:52:21 pcm kernel: cdc_acm 1-1:1.4: ttyACM2: USB ACM device
>Feb 20 08:52:21 pcm kernel: cdc_acm 1-1:1.6: ttyACM3: USB ACM device
>Feb 20 08:52:21 pcm kernel: cdc_acm 1-1:1.8: This device cannot do calls on
>its own. It is not a modem.
>Feb 20 08:52:21 pcm kernel: cdc_acm 1-1:1.8: ttyACM4: USB ACM device
>Feb 20 08:52:21 pcm kernel: usbcore: registered new interface driver cdc_acm
>Feb 20 08:52:21 pcm kernel: cdc_acm: USB Abstract Control Model driver for USB
>modems and ISDN adapters
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm 1-1:1.0: ttyACM0: USB ACM device
>Feb 20 08:52:21 pcm kerncdc_ether 1-1:1.10 usb0: CDC: unexpected notification
>01!
>el[657]: cdc_acm 1-1:1.2: ttyACM1: USB ACM device
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm 1-1:1.4: ttyACM2: USB ACM device
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm 1-1:1.6: ttyACM3: USB ACM device
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm 1-1:1.8: This device cannot do calls
>on its own. It is not a modem.
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm 1-1:1.8: ttyACM4: USB ACM device
>Feb 20 08:52:21 pcm kernel[657]: usbcore: registered new interface driver
>cdc_acm
>Feb 20 08:52:21 pcm kernel[657]: cdc_acm: USB Abstract Control Model driver
>for USB modems and ISDN adapters
>Feb 20 08:52:21 pcm connmand[700]: src/rtnl.c:rtnl_message() buf 0x7eeffbf8
>len 1076
>Feb 20 08:52:21 pcm connmand[cdc_ether 1-1:1.12 usb1: CDC: unexpected
>notification 01!
>700]: src/rtnl.c:rtnl_message() NEWLINK len 1076 type 16 flags 0x seq 0
>pid 0
>Feb 20 08:52:21 pcm connmand[700]: src/ipconfig.c:__connman_ipconfig_newlink()
>index 7
>Feb 20 08:52:21 pcm connmand[700]: usb0 {create} index 7 type 1
>Feb 20 08:52:21 pcm connmand[700]: usb0 {update} flags 4098
>Feb 20 08:52:21 pcm connmand[700]: usb0 {newlink} index 7 address
>XX:XX:XX:XX:00:00 mtu 1500
>Feb 20 08:52:21 pcm connmand[700]: usb0 {newlink} index 7 operstate 2
>
>
>Check if the DEVTYPE is set correctly on the modem. If it is not
>wwan ConnMan wont ignore it src/rntl.c:
>
>static void read_uevent(struct interface_data *interface)
>{
> [...]
>
> found_devtype = false;
> while (fgets(line, sizeof(line), f)) {
> char *pos;
>
> pos = strchr(line, '\n');
> if (!pos)
> continue;
> pos[0] = '\0';
>
> if (strncmp(line, "DEVTYPE=", 8) != 0)
> continue;
>
> found_devtype = true;
>
> if (strcmp(line + 8, "wlan") == 0) {
> interface->service_type = CONNMAN_SERVICE_TYPE_WIFI;
> interface->device_type = CONNMAN_DEVICE_TYPE_WIFI;
> } else if (strcmp(line + 8, "wwan") == 0) {
> interface->service_type =
>CONNMAN_SERVICE_TYPE_CELLULAR;
> interface->device_type = CONNMAN_DEVICE_TYPE_CELLULAR;
> } else if (strcmp(line + 8, "bluetooth") == 0) {
> interface->service_type =
>CONNMAN_SERV
