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 (Daniel Wagner)
2. Re: Connman to control OpenVPN connection (Daniel Wagner)
3. Re: two wlan interfaces - tether on one and control the other
as a client? (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 1 Jan 2017 15:27:20 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH] service: Don't auto connect if error is set for
service
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Saurav,
On 12/24/2016 01:02 PM, Saurav Babu wrote:
>>> 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 <[email protected]>
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;
--
2.9.3
------------------------------
Message: 2
Date: Sun, 1 Jan 2017 15:39:31 +0100
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Florent,
On 12/27/2016 06:52 PM, Florent Le Saout wrote:
> Hello,
>
> I'm trying to get vpn connection managed by connman.
>
> I've been looking in the documentation in the sources or website, but
> didn't find my answer yet.
>
> So far, I can connect to my OpenVPN server manually via connmanctl, so I
> guess my vpn config file is quite ok.
>
> But the remaining question is about the autoconnection and link
> verification.
>
> From my understanding autoconnect, reconnect etc, that we can configure
> in main config file only applies to technologies, but VPNs are not
> technologies from connman perspectives, so they are listed as service
> (maybe my statement here is not correct ?).
If you set your Ethernet Service and VPN Service to autoconnect, the VPN
tunnel will be openened after the Ethernet Service got connected.
> My goal is to be able, as soon as I get proper network connection,
> either by ethernet, cellular or wifi technologies to get connected to my
> vpn server and in case of disconnection (so implicitly a connection
> check is done in background) to get reconnected.
That should work in theory :)
> * How to setup autoconnect and reconnect with OpenVPN (also in case we
> change technology from ethernet to cellular for instance) ?
ConnMan will reconnect the tunnel when the underlying connection dies
and there is a new connection established.
> * Regarding routes, I would like to know how to apply the routes
> pushed by the OpenVPN server as the default route?
ConnMan will add the routes automatically to your routing table. You
just need to push them from the server, e.g. do something like
push "redirect-gateway def1"
> * Regarding DNS server, I also would like to know how to get the DNS
> pushed by the OpenVPN applied in resolv.conf ?
Same here ConnMan will take of the DNS resolving, you might need to push
the right DNS entries from the OpenVPN server:
push "dhcp-option DNS 85.25.128.10"
push "dhcp-option DNS 85.25.255.10"
HTH,
Thanks,
Daniel
------------------------------
Message: 3
Date: Sun, 1 Jan 2017 15:42:11 +0100
From: Daniel Wagner <[email protected]>
To: Matthijs Vader <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: two wlan interfaces - tether on one and control the other
as a client?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Matthijs,
On 12/24/2016 01:08 PM, Matthijs Vader wrote:
> I have two wlan interfaces in linux, from a single rtl8723bu chipset
> running in concurrent mode. I want to use wlan0 as a normal client, and
> use wlan1 to host an access point. The idea is to use wlan1 to let users
> of our blackbox-type-product for setting up eth0 or wlan0 networking and
> some other config options.
>
> Is it possible make connman enable tethering on wlan1 only, while also
> still using connman to configure & manage the wlan0 as well to connect
> to other access points?
Unfortunately, no that wont work, because ConnMan does not export the
individual device. That means all devices are grouped under the
Technology API and therefore you can either have all them in tethering
mode or none.
> All documentation and connmanctl instructions I've seen and use refer to
> the more generic wifi..
>
> Or won't that work, and would I be therefore better of keeping connman
> for the client (wlan0) only. So make it ignore wlan1 by blacklisting it,
> and then setting up hostapd or something similar on wlan1. ?
Yes, that should work.
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 15, Issue 1
**************************************
