Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] supplicant: fixed return value of ssid getter
(Vasyl Vavrychuk)
2. Re: Ofono LTE modems and connman services (Jonas Bonn)
3. Re: Ofono LTE modems and connman services (Denis Kenzior)
4. Re: Ofono LTE modems and connman services (Jonas Bonn)
5. Re: Ofono LTE modems and connman services (Jonas Bonn)
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Mar 2018 00:40:11 +0200
From: Vasyl Vavrychuk <vvavryc...@gmail.com>
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org
Subject: Re: [PATCH] supplicant: fixed return value of ssid getter
Message-ID:
<CAGj4m+6gF5f6dNTeT5q3WyC=n+zq700obijnfzpvxqo-mci...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi, Daniel,
I appears that my change is breaking one. I have two hidden networks
in range and one (WEP one) survives this change but other (PSK)
disappear after my change from `>services` in commanctl.
I will investigate why...
On Wed, Feb 28, 2018 at 9:37 AM, Daniel Wagner <w...@monom.org> wrote:
> What about introducing a helper function which says, the SSID we have is a
> valig, something like this
>
> bool ssid_is_valid(const unsigned char *ssid, unsigned int ssid_len)
> {
> /* empty ssid, that is "" */
> if (ssid_len == 0 && !ssid && ssid[0] == '\0')
> return true;
>
> if (ssid_len > 0)
> return true;
>
> return false;
> }
>
> and use it everyhwere we need. Open coding seems like a bad idea.
>From one side I like this function but from other side it bothers me
if we can do ssid[0] when ssid_len==0. And also I am not sure how this
function can help us. And also it needs many changes in existing code.
I suggest go one of two ways. I prefer first if you are okay.
1. Simply remove noisy warning
--- a/src/config.c
+++ b/src/config.c
@@ -1219,8 +1219,7 @@ static int try_provision_service(struct
connman_config_service *config,
ssid = connman_network_get_blob(network, "WiFi.SSID",
&ssid_len);
if (!ssid) {
- connman_error("Network SSID not set");
- return -EINVAL;
+ return -ENOENT;
}
if (!config->ssid || ssid_len != config->ssid_len)
2. Keep track of ssid_valid field over the code
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -225,6 +225,7 @@ struct _GSupplicantNetwork {
char *name;
unsigned char ssid[32];
unsigned int ssid_len;
+ bool ssid_valid;
dbus_int16_t signal;
dbus_uint16_t frequency;
struct g_supplicant_bss *best_bss;
@@ -1186,8 +1187,8 @@ const char
*g_supplicant_network_get_security(GSupplicantNetwork *network)
return security2string(network->security);
}
-const void *g_supplicant_network_get_ssid(GSupplicantNetwork *network,
- unsigned int *ssid_len)
+bool g_supplicant_network_get_ssid(GSupplicantNetwork *network,
+ const void **ssid, unsigned int *ssid_len)
{
if (!network || !network->ssid_len) {
*ssid_len = 0;
diff --git a/src/network.c b/src/network.c
index 4757d0d7..2fd3d1aa 100644
--- a/src/network.c
+++ b/src/network.c
@@ -1991,10 +1991,10 @@ int connman_network_set_blob(struct
connman_network *network,
* @key: unique identifier
* @size: pointer to blob size
*
- * Get binary blob value for specific key
+ * Get binary blob value for specific key. Returns true if such value exists.
*/
-const void *connman_network_get_blob(struct connman_network *network,
- const char *key, unsigned int *size)
+bool connman_network_get_blob(struct connman_network *network,
+ const char *key, const void
**value, unsigned int *size)
and so on...
------------------------------
Message: 2
Date: Thu, 1 Mar 2018 12:27:42 +0100
From: Jonas Bonn <jo...@southpole.se>
To: Denis Kenzior <denk...@gmail.com>, of...@ofono.org,
"connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <e10fa5c9-24ea-3af8-651f-2f43a4967...@southpole.se>
Content-Type: text/plain; charset=utf-8; format=flowed
On 02/26/2018 05:12 PM, Denis Kenzior wrote:
> Hi Jonas,
>
> On 02/26/2018 08:37 AM, Jonas Bonn wrote:
>> 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.
OK... I fixed my driver. :) I sent the patches a couple of minutes ago.
With that, things work much better. connman doesn't choke on network
tech transitions anymore.
There are still issues with connman related to this though:
Ofono does something like this on a tech transition to LTE:
Active: false
Attached: false
...
Attached: true
Active: true
When ofono does Attached: true, connman starts trying to set the context
active which seems to result in InProgress. connman doesn't seem to
like the InProgress response and tries again, which ends up pounding the
modem hard with "set active" messages until read_settings() returns (on
the modem side) and the modem becomes Active (automatically) for real.
Similarly, on a transition from LTE to 3G, connman also tries to
activate the context hundreds of times before it settles. This
behaviour is harder to understand: connman has explicitly requested the
activation here and should know that it's in progress...
What I think might be an issue here is the interplay between Attached
and Active. For LTE, Attached and Active are synonymous...(???)
connman should not be setting Active for these at all.
Could ofono have Active set to true before Attached gets set true for
the LTE context case so that connman never sees the context as
Active:false? Or is there a better way to handle this?
/Jonas
------------------------------
Message: 3
Date: Thu, 1 Mar 2018 09:11:24 -0600
From: Denis Kenzior <denk...@gmail.com>
To: Jonas Bonn <jo...@southpole.se>, of...@ofono.org,
"connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <dfeca1c1-e4ab-a42c-f9b2-92d69b100...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jonas,
> Ofono does something like this on a tech transition to LTE:
>
> Active: false
> Attached: false
> ...
> Attached: true
> Active: true
>
This is from 3G to LTE or the initial registration to LTE? Do you have
an ofono-monitor log handy?
> When ofono does Attached: true, connman starts trying to set the context
> active which seems to result in InProgress.? connman doesn't seem to
> like the InProgress response and tries again, which ends up pounding the
> modem hard with "set active" messages until read_settings() returns (on
> the modem side) and the modem becomes Active (automatically) for real.
That sounds like connman isn't taking InProgress into consideration
properly.
>
> Similarly, on a transition from LTE to 3G, connman also tries to
> activate the context hundreds of times before it settles.? This
> behaviour is harder to understand:? connman has explicitly requested the
> activation here and should know that it's in progress...
ofono-monitor log by any chance? I'm not sure why a switch from LTE to
3G would cause any changes to Active/Attached states. It should simply
twiddle the NetworkRegistration state and that's it, unless the modem is
reporting things it shouldn't.
>
> What I think might be an issue here is the interplay between Attached
> and Active.? For LTE, Attached and Active are synonymous...(???) connman
> should not be setting Active for these at all.
ConnMan doesn't keep track of the NetworkRegistration state, so it
doesn't really know about LTE...
>
> Could ofono have Active set to true before Attached gets set true for
> the LTE context case so that connman never sees the context as
> Active:false?? Or is there a better way to handle this?
I don't think that would make sense from an API consistency perspective.
Regards,
-Denis
------------------------------
Message: 4
Date: Thu, 1 Mar 2018 16:38:53 +0100
From: Jonas Bonn <jo...@southpole.se>
To: Alexander Couzens <lyn...@fe80.eu>
Cc: of...@ofono.org, Denis Kenzior <denk...@gmail.com>,
"connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <a86022ac-0955-41ca-a4b9-0ccd4bf55...@southpole.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/01/2018 04:27 PM, Alexander Couzens wrote:
> Hi Jonas,
>
> thanks for your patch.
> I'm actually having problem from time to time with ofono (quectel
> ec 20) when using LTE. Ofono has 2 contexts allocated, but it says
> it's detached to packet switched.
You should get just one context now...
>
> I hope your patch is fixing this.
>
> In the LTE atom, you're setting the profile 1.
> Does it really have to be profile 1. Is the profile 1 a special profile
> which should not be removed?! Or how is it ensured, this can not be
> removed?
Well, that's where I need some help from somebody with another modem.
This works for the one I've got.
I'm not able to remove profile 1... not sure why, but the command fails
consistently. There's no reason it has to be profile 1, as far as I can
tell... for the AT command set, context 0 seems to be special, but
profile 0 does not exist on my modem.
Maybe the 'default' profile is the just the first dual-stack profile
amongst all profiles???
Hopefully the patch is starting point for figuring this out...
>
> I'm also asking, because ofono/qmi doesn't really support ipv4, ipv6 and
> dual contexts. For this we need to manage exactly those profiles and
> use them when starting the contexts. Atm requesting an ipv4
> context can result in requesting a Dual context depending if the
> network (SGSN/GGSN) supports it.
As far as I understand it, the default bearer context has to be dual stack.
/Jonas
>
> Best,
> lynxis
>
------------------------------
Message: 5
Date: Thu, 1 Mar 2018 16:48:09 +0100
From: Jonas Bonn <jo...@southpole.se>
To: Denis Kenzior <denk...@gmail.com>, of...@ofono.org,
"connman@lists.01.org" <connman@lists.01.org>
Subject: Re: Ofono LTE modems and connman services
Message-ID: <a2d778ca-a4b1-8b49-3c61-e800f3fae...@southpole.se>
Content-Type: text/plain; charset=utf-8; format=flowed
On 03/01/2018 04:11 PM, Denis Kenzior wrote:
> Hi Jonas,
>
>> Ofono does something like this on a tech transition to LTE:
>>
>> Active: false
>> Attached: false
>> ...
>> Attached: true
>> Active: true
>>
>
> This is from 3G to LTE or the initial registration to LTE?? Do you have
> an ofono-monitor log handy?
This is an explicit UMTS to LTE transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = lte
{ConnectionManager} [/quectelqmi_0] Attached = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{NetworkRegistration} [/quectelqmi_0] Status = searching
{NetworkRegistration} [/quectelqmi_0] Technology = lte
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = available
{NetworkRegistration} [/quectelqmi_0] Name =
{ConnectionManager} [/quectelqmi_0] Attached = True
{NetworkRegistration} [/quectelqmi_0] Status = roaming
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 65534
{NetworkRegistration} [/quectelqmi_0] CellId = 26710796
{NetworkOperator} [/quectelqmi_0/operator/24001] Status = current
{NetworkRegistration} [/quectelqmi_0] Name = 24001
{NetworkRegistration} [/quectelqmi_0] MobileCountryCode = 240
{NetworkRegistration} [/quectelqmi_0] MobileNetworkCode = 01
{NetworkRegistration} [/quectelqmi_0] Status = registered
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = TELIA
{NetworkRegistration} [/quectelqmi_0] Strength = 20
{NetworkRegistration} [/quectelqmi_0] Name = Orange F
{NetworkOperator} [/quectelqmi_0/operator/24001] Name = 24001
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.172.219.235, Netmask =
255.255.255.248, Gateway = 10.172.219.236, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
Here's what connman does effects on the LTE to UMTS transition:
{RadioSettings} [/quectelqmi_0] TechnologyPreference = umts
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionManager} [/quectelqmi_0] Attached = False
{NetworkRegistration} [/quectelqmi_0] LocationAreaCode = 11
{NetworkRegistration} [/quectelqmi_0] CellId = 752047
{NetworkRegistration} [/quectelqmi_0] Technology = umts
{ConnectionManager} [/quectelqmi_0] Attached = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.160.218.173, Netmask =
255.255.255.252, Gateway = 10.160.218.174, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
^[[F{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface
= wwp0s20u1i4, Method = static, Address = 10.167.137.164, Netmask =
255.255.255.248, Gateway = 10.167.137.165, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.173.100.170, Netmask =
255.255.255.252, Gateway = 10.173.100.169, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.160.115.172, Netmask =
255.255.255.248, Gateway = 10.160.115.173, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.167.11.161, Netmask =
255.255.255.252, Gateway = 10.167.11.162, DomainNameServers =
194.51.3.56 194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
{ConnectionContext} [/quectelqmi_0/context1] Settings = { Interface =
wwp0s20u1i4, Method = static, Address = 10.173.65.6, Netmask =
255.255.255.252, Gateway = 10.173.65.5, DomainNameServers = 194.51.3.56
194.51.3.56 }
{ConnectionContext} [/quectelqmi_0/context1] Active = True
{ConnectionContext} [/quectelqmi_0/context1] Settings = {}
{ConnectionContext} [/quectelqmi_0/context1] Active = False
....eventually that settles down and the connection is established.
>
>> When ofono does Attached: true, connman starts trying to set the
>> context active which seems to result in InProgress.? connman doesn't
>> seem to like the InProgress response and tries again, which ends up
>> pounding the modem hard with "set active" messages until
>> read_settings() returns (on the modem side) and the modem becomes
>> Active (automatically) for real.
>
> That sounds like connman isn't taking InProgress into consideration
> properly.
>
>>
>> Similarly, on a transition from LTE to 3G, connman also tries to
>> activate the context hundreds of times before it settles.? This
>> behaviour is harder to understand:? connman has explicitly requested
>> the activation here and should know that it's in progress...
>
> ofono-monitor log by any chance?? I'm not sure why a switch from LTE to
> 3G would cause any changes to Active/Attached states.? It should simply
> twiddle the NetworkRegistration state and that's it, unless the modem is
> reporting things it shouldn't.
>
Maybe... take at look at the first ofono log above and see what the
network registration state is doing... that's what's causing the
unattached state, I think.
/Jonas
>>
>> What I think might be an issue here is the interplay between Attached
>> and Active.? For LTE, Attached and Active are synonymous...(???)
>> connman should not be setting Active for these at all.
>
> ConnMan doesn't keep track of the NetworkRegistration state, so it
> doesn't really know about LTE...
>
>>
>> Could ofono have Active set to true before Attached gets set true for
>> the LTE context case so that connman never sees the context as
>> Active:false?? Or is there a better way to handle this?
>
> I don't think that would make sense from an API consistency perspective.
>
> Regards,
> -Denis
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 29, Issue 1
**************************************
