Send connman mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] service: Don't auto connect if error is set for
service (Saurav Babu)
2. How to make device running connman have a hostname?
(Daniel Bedrenko)
3. Re: two wlan interfaces - tether on one and control the other
as a client? (Jose Blanquicet)
4. Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Wed, 04 Jan 2017 15:34:12 +0530
From: Saurav Babu <[email protected]>
To: [email protected]
Cc: [email protected], Saurav Babu <[email protected]>
Subject: Re: [PATCH] service: Don't auto connect if error is set for
service
Message-ID: <[email protected]>
Hi Daniel,
>>>> In the following scenario:
>>>> 1. Device gets connected to an AP.
>>>> 2. Goto AP's settings page and add device's MAC address in block list
>>>> 3. Device gets disconnected with AP.
>>>> 4. Auto Connection is again triggered with AP.
>>>> In above scenario steps 3 and 4 are repeated infintely even though
>>>> device would never connect to AP because it's MAC address is added in
>>>> block list of AP.
>>>> On the first disconnection connect-failed error is set. This patch only
>>>> blocks auto connection whenever an error is set for the service.
>>
>>
>>> service_indicate_state() {
>>> [...]
>>
>>> switch (new_state) {
>>> [...]
>>
>>> case CONNMAN_SERVICE_STATE_DISCONNECT:
>>> set_error(service,
>>> CONNMAN_SERVICE_ERROR_UNKNOWN);
>>
>>> [...]
>>> }
>>
>>> [...]
>>> }
>>
>>> Is that the source of setting the error variable to
>>> CONNMAN_SERVICE_ERROR_UNKNOWN?
>> Yes.
> Thanks for confirming it. So I decoded it correctly.
>>> From a quick look at the pluging tells me that we don't propagate
>>> or use the disconnect reason code at all. I suspect we would get
>>> some hint why the disconnect happened. For example if we see reason
>>> code 4 "Disassociated due to inactivity" would be a non-error reason and
>>> we would be allowed to reconnect. See table 8-36 in the IEEE 802.11-2012
>>> spec.
>>
>>> Do you see a reason code in the above scenario?
>> On most occasions I got reason code as 6 "Class 2 frame received from
>> nonauthenticated STA" and some occasions reason code 1.
> So at leas reason code 6 seems to be correct. 1 is not really telling
> anything. Ideally we start logging things like reason code 6 or and
> let the user know why stuff doesn't work.
>>>> ---
>>>> src/service.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/src/service.c b/src/service.c
>>>> index 737a39f..e6fdef8 100644
>>>> --- a/src/service.c
>>>> +++ b/src/service.c
>>>> @@ -3733,6 +3733,9 @@ static bool is_ignore(struct connman_service
>>>> *service)
>>>> if (service->state == CONNMAN_SERVICE_STATE_FAILURE)
>>>> return true;
>>>>
>>>> + if (service->error != CONNMAN_SERVICE_ERROR_UNKNOWN)
>>>> + return true;
>>>> +
>>>> if (!is_ipconfig_usable(service))
>>>> return true;
>>
>>> Looking at the auto_connect_service() code we have following:
>>
>>> if (is_ignore(service) || service->state !=
>>>
>>> CONNMAN_SERVICE_STATE_IDLE)
>>> continue;
>>
>>> The service is in CONNMAN_SERVICE_STATE_IDLE state and not in
>>> CONNMAN_SERVICE_STATE_FAILURE. If so is_ignored() doesn't need to be updated
>>> (which I would prefer because we are looking only on the service state
>>> there and not the newtork state)
>>
>>> So from this, should we set the service state to FAILURE if we have
>>> a network error code?
>> Are you trying to say that we should decide to remain to FAILURE state or
>> change to
>> IDLE state depending on the reason code?
>> If yes, then what would be the reason codes on which we should change to
>> IDLE state
>> from FAILURE?
> It's been a while since I last hacked on the service state machine. IIRC the
> rule is the service state is ending in FAILURE ConnMan will stop trying to
> autoconnect. So my reasoning is if we get an disconnect from a plugin we check
> why it was disconnected. If the disconnect just happened because the signal
> got so weak (soft fail), the service should end in IDLE state. Though if we
> get a disconnect because of reason code 6 we should set the state to FAILURE.
> That should stop ConnMan from auto connect.
> Does the attached patch work for you? I tested it on my network and as
> soon I blocked my client, the service entered into FAILURE state and
> stayed there.
> Thanks,
> Daniel
>>From 9b49a97a0730e03232e128202c1ca3744adfec1d Mon Sep 17 00:00:00 2001
> From: Daniel Wagner <wagi at monom.org>
> Date: Sun, 1 Jan 2017 15:17:24 +0100
> Subject: [PATCH] wifi: Propagete disconnect reason code to service
> Currently, if the WiFi plugin gets disconnected we ignore the reason
> why that happened. Instead we just cleanup and let the corresponding
> Service go to the IDLE state. If autoconnect than decides to reconnect
> to that service it might just fail again, because the AP decided to
> block us.
> To prevent this busy loop we introduce a new error code blocked on the
> network and service layer. So whenever the AP decided to kick this
> client from the network we set the error code.
> BTW, wpa_supplicant sents first the reason code before it tells
> ConnMan the interface got disconnected.
---
> include/network.h | 1 +
> include/service.h | 1 +
> plugins/wifi.c | 13 +++++++++++++
> src/network.c | 13 +++++++++++++
> src/service.c | 2 ++
> 5 files changed, 30 insertions(+)
> diff --git a/include/network.h b/include/network.h
> index bb9647f23aaa..5d44669599c8 100644
> --- a/include/network.h
> +++ b/include/network.h
> @@ -55,6 +55,7 @@ enum connman_network_error {
> CONNMAN_NETWORK_ERROR_CONFIGURE_FAIL = 2,
> CONNMAN_NETWORK_ERROR_INVALID_KEY = 3,
> CONNMAN_NETWORK_ERROR_CONNECT_FAIL = 4,
> + CONNMAN_NETWORK_ERROR_BLOCKED = 5,
> };
> #define CONNMAN_NETWORK_PRIORITY_LOW -100
> diff --git a/include/service.h b/include/service.h
> index 31dfce7e217c..185f008f585b 100644
> --- a/include/service.h
> +++ b/include/service.h
> @@ -79,6 +79,7 @@ enum connman_service_error {
> CONNMAN_SERVICE_ERROR_LOGIN_FAILED = 5,
> CONNMAN_SERVICE_ERROR_AUTH_FAILED = 6,
> CONNMAN_SERVICE_ERROR_INVALID_KEY = 7,
> + CONNMAN_SERVICE_ERROR_BLOCKED = 8,
> };
> enum connman_service_proxy_method {
> diff --git a/plugins/wifi.c b/plugins/wifi.c
> index 70cec7772e74..f8d88fa3ada0 100644
> --- a/plugins/wifi.c
> +++ b/plugins/wifi.c
> @@ -2461,6 +2461,19 @@ static void interface_state(GSupplicantInterface
> *interface)
> network, wifi))
> break;
> + /* See table 8-36 Reason codes in IEEE Std 802.11 */
> + switch (wifi->disconnect_code) {
> + case 1: /* Unspecified reason */
> + /* Let's assume it's because we got blocked */
> +
> + case 6: /* Class 2 frame received from nonauthenticated STA */
> + connman_network_set_error(network,
> + CONNMAN_NETWORK_ERROR_BLOCKED);
> + break;
> +
> + default:
> + break;
> + }
> connman_network_set_connected(network, false);
> connman_network_set_associating(network, false);
> wifi->disconnecting = false;
> diff --git a/src/network.c b/src/network.c
> index aa82b741f62e..5b7ef5569f7a 100644
> --- a/src/network.c
> +++ b/src/network.c
> @@ -1256,6 +1256,16 @@ static void set_connect_error(struct connman_network
> *network)
> CONNMAN_SERVICE_ERROR_CONNECT_FAILED);
> }
>
> +static void set_blocked_error(struct connman_network *network)
> +{
> + struct connman_service *service;
> +
> + service = connman_service_lookup_from_network(network);
> +
> + __connman_service_indicate_error(service,
> + CONNMAN_SERVICE_ERROR_BLOCKED);
> +}
> +
> void connman_network_set_ipv4_method(struct connman_network *network,
> enum connman_ipconfig_method method)
> {
> @@ -1310,6 +1320,9 @@ void connman_network_set_error(struct connman_network
> *network,
> case CONNMAN_NETWORK_ERROR_CONNECT_FAIL:
> set_connect_error(network);
> break;
> + case CONNMAN_NETWORK_ERROR_BLOCKED:
> + set_blocked_error(network);
> + break;
> }
>
> __connman_network_disconnect(network);
> diff --git a/src/service.c b/src/service.c
> index 737a39f4c3b0..2a7147639c99 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -320,6 +320,8 @@ static const char *error2string(enum
> connman_service_error error)
> return "auth-failed";
> case CONNMAN_SERVICE_ERROR_INVALID_KEY:
> return "invalid-key";
> + case CONNMAN_SERVICE_ERROR_BLOCKED:
> + return "blocked";
> }
>
> return NULL;
> --
Above patch works on my setup
Thanks,
Saurav
------------------------------
Message: 2
Date: Wed, 4 Jan 2017 11:34:17 +0100
From: Daniel Bedrenko <[email protected]>
To: "[email protected]" <[email protected]>
Subject: How to make device running connman have a hostname?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello all,
I have connman running on my device in tether mode. When I'm connected to it
with my laptop I want the hostname "my.hostname" to resolve to the device
running connman. How could I achieve this?
I tried creating a /var/lib/connman/example.config file, but it doesn't seem to
have an effect; I can't ping "my.hostname" from the laptop:
root@mydevice: ~# cat /var/lib/connman/example.config
[global]
Name = Example
Description = Example network configuration
[service_home_wifi]
Type = wifi
Nameservers = 8.8.8.8,127.0.0.1,192.168.0.1
SearchDomains = local
Domain = my.hostname
Any pointers would be much appreciated.
Daniel B
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170104/bb532b06/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 4 Jan 2017 12:55:59 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>, "MANIEZZO Marco
(MM)" <[email protected]>
Subject: Re: two wlan interfaces - tether on one and control the other
as a client?
Message-ID:
<cafc8ij+phqg5gjlt9ooiztqlp1yn7oizcwx0abzo+v+wbvn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Tue, Jan 3, 2017 at 6:02 PM, Daniel Wagner <[email protected]> wrote:
>> ConnMan's idea is to hide lower level things like actual interfaces. I
>> partially agree, this approach aims to keep things simple but
>> unfortunately it harms complex systems with more than one device per
>> Technology where we would like to have control over which role they
>> will play. This does not only affect Tethering, we found the same
>> problem on the RFC we have been working on for WPS connections.
>>
>> We have a similar scenario here, we have one single Marvell WiFi
>> chipset which exposes three devices and we are currently using ConnMan
>> to manage STA, AP and P2P connections in parallel. However, even
>> though Marvell produces WiFi chipset used by WFA for testing, the
>> driver does not perfectly report devices' capabilities. Therefore, I
>> think we should start thinking on some solution for these kind of
>> complex systems. I hope that maintainers also start considering this
>> because, for example, sometimes we have had to hard-code interface
>> names and that's really sad :(.
>
>
> Agreed, that is really sad. I am not against supporting more complex stuff.
> We just need to be very careful not to clutter the D-Bus APIs.
OK, actually our initial idea would be to insert some kind of
"intelligence" inside ConnMan in order to make it select the most
suitable device for enabling Tethering based on current devices state.
Doing so, D-Bus APIs would not be affected at all.
> So if I understood you correctly, one major problem is that the device
> picked for AP is depending on the order of scanning results. Well, that is
> indeed a bit funky.
Not exactly the order of the scanning but the order on which devices
were created in WiFi plugin and then stored into devices list
(iface_list). The reason is that when Tethering is trying to be
enabled, WiFi plugin moves across iface_list looking for the first
device which supports AP mode based on the algorithm I mentioned in
the previous email. Therefore, if both devices support AP then the
first on iface_list will be picked.
I would like to clarify something, most of WiFi chipset providers
guarantee a certain performance and simultaneous role support if
devices are used in specific roles. Then, in cases like Matthijs's, it
would not be actually incorrect if driver reports that both devices
support AP mode. But let's consider Matthijs's provider guarantees
best performance when wlan1 is used as AP, that would be indeed one of
the main reasons one would want to specify the device to be used for
Tethering.
> I wonder if it would be possible to 'annotate' via the config files
> which device is used for tethering. This is just a quick and dirty
> proposal:
>
>
> $ cat /var/lib/connman/example.config
> [device_wifi_ap]
> Type = wifi
> MAC = 01:02:03:04:05:06
> Tethering = enabled
>
> [device_wifi_sta]
> Type = wifi
> MAC = 01:02:03:04:05:07
> Tethering = disabled
>
>
> Instead handling the config information via the ConnMan core, the wifi
> plugin could itself look for a config file. We have this also done for the
> session plugin. It looks for a config itself.
Well, for a static configuration where WiFi devices have the same
capabilities, your proposal would indeed solve the issue. But what
about different capabilities? Let's consider a system with two WiFi
devices (wlan0, wlan1) where any simultaneous role is guarantee by
WiFi chipset provider (Of course, according to each device
capabilities), e.g. STA||AP, STA||P2P, AP||P2P, and so on. Therefore,
you are requested to provide any of those combinations at any time.
Consider the following devices capabilities:
- wlan0 supports STA and AP mode.
- wlan1 supports STA, AP and P2P mode.
In such a scenario, what would one put in the Tether config file?
Maybe disabled Tethering for wlan0 in order to use it only as STA
could be an option but then if user first enables Tethering, ConnMan
will use wlan1 and then you cannot provide P2P connections anymore
because wlan1 is busy. If instead, you let both devices as enabled in
Tether config file, then ConnMan could have wlan1 before wlan0 in
iface_list thus it will always use wlan1 when user enables Tethering
and again we have the same problem as before; we are not able to
provide P2P and AP simultaneously if user enables Tethering before
establishing a P2P connection.
In order to avoid the restriction described above, I would suggest to
add a certain kind of priority to STA/AP devices over STA/AP/P2P
devices. Doing so, in previous example, one should let both devices as
enabled in Tether config file and then ConnMan will consider STA/AP
devices always before trying to use STA/AP/P2P ones and such a
restriction is gone; after user enabled Tethering we can still provide
P2P connections.
What do others think? Suggestions/Comments?
Regards,
Jose Blanquicet
------------------------------
Message: 4
Date: Wed, 4 Jan 2017 13:27:04 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Auto-connect from wpa_supplicant and ConnMan does not
become aware
Message-ID:
<CAFC8iJL54fZmo3iMLNd_6QeM=-vdu6pp6fu5fjvtmeykhrn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Daniel,
On Tue, Jan 3, 2017 at 5:44 PM, Daniel Wagner wrote:
>> I asked if such a reconnection is a desired behaviour in wpa_supplican
>> mailing list and Jouni confirmed this is how it should works and
>> suggested a solution
>> (http://lists.infradead.org/pipermail/hostap/2016-December/036844.html).
>> He told that we need to keep track of the created network profiles
>> during WPS provisioning (Yes, they may be more than one) and then mark
>> them as disabled or delete them. What do you think?
>
>
> If wpa_supplicant behavior is supposed to be correct, then there aren't many
> options. Hopefully this isn't too complex to add to wifi.c. That file is
> already a bit big but well, not much choice.
>
> Are you going to work on this?
Well, I think maybe it would need to be implemented at lower lever
than wifi.c, it means into gsupplicant.c level because it concerns
D-Bus signals, network profiles and stuff strictly related to
wpa_supplicant. However, I have not looked at this into details yet
thus I am not completely sure.
And yes, maybe it would not be so complex but only once you know
how/when does wpa_supplicant send those networks profile information
for WPS in order to avoid to clutter non-WPS stuff and auto-connect
implementation. So, I will start studying wpa_supplicant a little bit
more and ask for more details to Jouni. Then, I will see if it is
quick enough to be done now, otherwise I will need to postpone also
this.
Any wpa_supplicant expert around? Maybe Tomasz? Any suggestion/comment
is welcome :)
Regards,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 4
**************************************
