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: two wlan interfaces - tether on one and control the other
as a client? (Patrik Flykt)
2. Re: How to make device running connman have a hostname?
(Patrik Flykt)
3. RE: two wlan interfaces - tether on one and control the other
as a client? (Matthijs Vader)
4. Re: [PATCH] service: Don't auto connect if error is set for
service (Patrik Flykt)
5. Re: two wlan interfaces - tether on one and control the other
as a client? (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Wed, 04 Jan 2017 15:50:34 +0200
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, Daniel Wagner
<[email protected]>
Cc: "[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="UTF-8"
Hi,
On Wed, 2017-01-04 at 12:55 +0000, Jose Blanquicet wrote:
> 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?
Yes, the issue is complex on ConnMan side. I just wish wpa_supplicant
would take a bit better care of its WiFi interfaces, as these issues
look like tasks for a WiFi daemon. Why should another application,
ConnMan in this case, understand WiFi better than the WiFi daemon
itself?
I'm not sure pushing this kind of functionality to wpa_supplicant is
going to succeed, though.
Cheers,
Patrik
------------------------------
Message: 2
Date: Wed, 04 Jan 2017 15:51:58 +0200
From: Patrik Flykt <[email protected]>
To: Daniel Bedrenko <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: How to make device running connman have a hostname?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2017-01-04 at 11:34 +0100, Daniel Bedrenko wrote:
> 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?
There is no such functionality in ConnMan to achieve this. The closest
that comes to mind is mDNS done by Avahi.
Cheers,
Patrik
------------------------------
Message: 3
Date: Wed, 4 Jan 2017 13:53:55 +0000
From: Matthijs Vader <[email protected]>
To: Jose Blanquicet <[email protected]>, Daniel Wagner
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: two wlan interfaces - tether on one and control the other
as a client?
Message-ID:
<he1pr07mb1436b215510b53c04a08dc85c5...@he1pr07mb1436.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi Jose and Daniel,
My 2 cents below,
> 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.
> >>
The other day when sending the initial email of this thread, the reason for me
to started looking at Connman for the AP was that we already use it for the
rest of the networking. But now that I know that Connman doesn't do it, there
is no problem in getting the feature implemented with hostapd and dnsmasq.
So, a question someone perhaps needs to answer before going all too deep into
this, is if it is really for ConnMan to manage such complex systems? Looking at
our device, the AP setup is so static that I don't see the benefit in using
Connman. Over the hostapd + dnsmasq alternative I mean. While for the internet
going connections, the `normal` Ethernet and/or Wifi STA, ConnMan does offer a
benefit.
And, for us, I much prefer ConnMan development to focus on stability, providing
for a 101% reliable internet connection always. Over adding features like this
that is.
Perhaps it does become a bit more complex when there is only one wlan
interface. Then we'd want it to be an AP when unconfigured, and have a user be
able to configure its STA mode while connected to the AP. Just like for example
Sonos seems to do.
> >> 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's indeed what our chipset provider (RT) does: they recommend wlan1 for 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
Can it not work with interface names, ie. wlan0, wlan1? We are using embedded
devices, and requiring mac addresses into the config file would mean sedding
them in there are boot or something like that.
> >
> > 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?
Though I see the idea when wanting to use P2P as well, for our use case, the
setup is best to be static. There is no need for priorities, and for example
when debugging it's a lot easier to see what's going on when one knows by heart
what wlan0 is used for, same for wlan1.
Best regards, Matthijs
------------------------------
Message: 4
Date: Wed, 04 Jan 2017 15:56:02 +0200
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>, 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="UTF-8"
On Sun, 2017-01-01 at 15:27 +0100, Daniel Wagner wrote:
> 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;
Looks the right way to implement this. ACK but no testing done by me.
Cheers,
Patrik
------------------------------
Message: 5
Date: Wed, 4 Jan 2017 17:30:49 +0000
From: Jose Blanquicet <[email protected]>
To: Matthijs Vader <[email protected]>
Cc: Daniel Wagner <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: two wlan interfaces - tether on one and control the other
as a client?
Message-ID:
<cafc8ijlt00bcpp-uuu4_nkjv4udgd+obh2rny6zkse+rap1...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Matthijs,
On Wed, Jan 4, 2017 at 1:53 PM, Matthijs Vader wrote:
> The other day when sending the initial email of this thread, the reason for
> me to started looking at Connman for the AP was that we already use it for
> the rest of the networking. But now that I know that Connman doesn't do it,
> there is no problem in getting the feature implemented with hostapd and
> dnsmasq.
>
> So, a question someone perhaps needs to answer before going all too deep into
> this, is if it is really for ConnMan to manage such complex systems? Looking
> at our device, the AP setup is so static that I don't see the benefit in
> using Connman. Over the hostapd + dnsmasq alternative I mean. While for the
> internet going connections, the `normal` Ethernet and/or Wifi STA, ConnMan
> does offer a benefit.
Personally, I do not agree. I would like to keep upper layers, e.g.
User Interface, as simple as possible thus I will always try to avoid
that it has to communicate with more than one component. If the
functionalities one needs are all provided by ConnMan, why don't only
use it? In my opinion, what we are doing here is trying to enhance
ConnMan to become the only WiFi component at that level over
wpa_supplicant.
> And, for us, I much prefer ConnMan development to focus on stability,
> providing for a 101% reliable internet connection always. Over adding
> features like this that is.
>
> Perhaps it does become a bit more complex when there is only one wlan
> interface. Then we'd want it to be an AP when unconfigured, and have a user
> be able to configure its STA mode while connected to the AP. Just like for
> example Sonos seems to do.
Well, as you also said, your case is a very stable configuration, but
I think it would not mean to have to harm more complex ones by keeping
things simple, of course without exaggerating. In particular, we use
ConnMan as connection manager in our products (Infotainment systems)
and our configuration could be very dynamic instead. I think this is a
Linux embedded system field where there is a lot of interest to have a
suitable connection manager daemon and ConnMan could be that one :)
>> >> 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's indeed what our chipset provider (RT) does: they recommend wlan1 for
> 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
>
> Can it not work with interface names, ie. wlan0, wlan1? We are using embedded
> devices, and requiring mac addresses into the config file would mean sedding
> them in there are boot or something like that.
I agree. We could try.
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 5
**************************************
