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: question on missing features (mac address authentication)
in AP mode (Patrik Flykt)
2. Re: [PATCH] service: state transition to configuration
(Naveen Singh)
3. Re: [PATCH] service: state transition to configuration
(Patrik Flykt)
4. [PATCH v2] service: state transition to configuration
(Naveen Singh)
5. Re: question on missing features (mac address authentication)
in AP mode (??)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Dec 2015 09:50:30 +0200
From: Patrik Flykt <[email protected]>
To: ?? <[email protected]>
Cc: [email protected]
Subject: Re: question on missing features (mac address authentication)
in AP mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Sun, 2015-12-27 at 11:31 +0800, ?? wrote:
> Does connman has any plan to use hostapd for AP mode? any try or
> consideration?
ConnMan does not have any plans to use hostapd for AP mode. ConnMan is
implementing the host side of things so it will need to have
wpa_supplicant up and running in order to connect to WiFi networks. It
implements decent tethering capabilities that a laptop or phone user can
be assumed to be able to control. But ConnMan does not try to be a
router device; therefore it lacks some of the more advanced and exotic
configuration capabilities of a router.
For a client end device MAC address filtering looks like a nuisance.
It's very hard to have a decent API for it, not mention digging out the
MAC address for various WiFi devices or believing that any UI using user
should be able to figure out why some devices suddenly can connect while
others can't. Besides, it does not give any extra security in the first
place as the MAC address can be changed by an attacker.
In general the wpa_supplicant/hostapd split is somehting you need to
take up on the hostapd mailing list. After all it would be simpler for
everybody if there were just one well-maintained daemon with a properly
functioning D-Bus API.
Cheers,
Patrik
------------------------------
Message: 2
Date: Mon, 28 Dec 2015 00:06:55 -0800
From: Naveen Singh <[email protected]>
To: [email protected]
Subject: Re: [PATCH] service: state transition to configuration
Message-ID:
<CAGTDzK=gk8rxffecqfxsmfzxo9mr6n7cigfdcm1ezufwozz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Dec 16, 2015 at 9:02 PM, Naveen Singh <[email protected]>
wrote:
> From: nasingh <[email protected]>
>
> If DHCP renewal fails and eventually lease expiry happens the
> service state machine was still left to online. This change changes
> ipv4 service state to configuration when ipv4 address is released.
> ---
> src/service.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/service.c b/src/service.c
> index abf0899..52fd6e8 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -6377,6 +6377,12 @@ static void service_ip_release(struct
> connman_ipconfig *ipconfig,
> CONNMAN_SERVICE_STATE_DISCONNECT,
> CONNMAN_IPCONFIG_TYPE_IPV4);
>
> + if (type == CONNMAN_IPCONFIG_TYPE_IPV4 &&
> + method == CONNMAN_IPCONFIG_METHOD_DHCP)
> + __connman_service_ipconfig_indicate_state(service,
> + CONNMAN_SERVICE_STATE_CONFIGURATION,
> + CONNMAN_IPCONFIG_TYPE_IPV4);
> +
> settings_changed(service, ipconfig);
> }
>
Hi Patrik
I realized that there is a better way to do the service transition. DHCP
results get communicated to network code through the registered call back
(through dhcp_result in network.c). On success dhcp_success is called and
on failure dhcp_failure is called. The service state transition to Ready is
done in dhcp_success when the function *__connman_ipconfig_gateway_add *is
called. In case of failure dhcp_failure is called which in turn calls
*__connman_ipconfig_gateway_remove
*but we do not do a state transition back to configuration.
I have made this change and would send a patch to you for review. Code
works fine. Service goes to configuration from online and again goes to
ready once IPV4LL is assigned.
Regards
Naveen
>
> --
> 2.6.0.rc2.230.g3dd15c0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20151228/915fda03/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 28 Dec 2015 10:10:23 +0200
From: Patrik Flykt <[email protected]>
To: Naveen Singh <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] service: state transition to configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, 2015-12-28 at 00:06 -0800, Naveen Singh wrote:
>
>
> On Wed, Dec 16, 2015 at 9:02 PM, Naveen Singh
> <[email protected]> wrote:
> From: nasingh <[email protected]>
>
> If DHCP renewal fails and eventually lease expiry happens the
> service state machine was still left to online. This change
> changes
> ipv4 service state to configuration when ipv4 address is
> released.
> ---
> src/service.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/service.c b/src/service.c
> index abf0899..52fd6e8 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -6377,6 +6377,12 @@ static void service_ip_release(struct
> connman_ipconfig *ipconfig,
>
> CONNMAN_SERVICE_STATE_DISCONNECT,
>
> CONNMAN_IPCONFIG_TYPE_IPV4);
>
> + if (type == CONNMAN_IPCONFIG_TYPE_IPV4 &&
> + method ==
> CONNMAN_IPCONFIG_METHOD_DHCP)
> +
> __connman_service_ipconfig_indicate_state(service,
> +
> CONNMAN_SERVICE_STATE_CONFIGURATION,
> + CONNMAN_IPCONFIG_TYPE_IPV4);
> +
> settings_changed(service, ipconfig);
> }
> Hi Patrik
> I realized that there is a better way to do the service transition.
> DHCP results get communicated to network code through the registered
> call back (through dhcp_result in network.c). On success dhcp_success
> is called and on failure dhcp_failure is called. The service state
> transition to Ready is done in dhcp_success when the
> function __connman_ipconfig_gateway_add is called. In case of failure
> dhcp_failure is called which in turn
> calls __connman_ipconfig_gateway_remove but we do not do a state
> transition back to configuration.
>
> I have made this change and would send a patch to you for review. Code
> works fine. Service goes to configuration from online and again goes
> to ready once IPV4LL is assigned.
I was suspecting something like this were to work mostly out-of-the-box,
but never had time to look at it. Thanks for figuring this one out,
please send a patch!
Cheers,
Patrik
------------------------------
Message: 4
Date: Mon, 28 Dec 2015 00:49:24 -0800
From: Naveen Singh <[email protected]>
To: [email protected]
Subject: [PATCH v2] service: state transition to configuration
Message-ID:
<[email protected]>
From: nasingh <[email protected]>
When the DHCP renewal fails dhcp_failure is called which in turn calls
__connman_connection_gateway_remove. This function unlike its
counterpart (__connman_connection_gateway_add which does the
service transition to READY) does not the change the state to
CONFIGURATION. This causes the service state to be stuck at ONLINE.
---
src/connection.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/connection.c b/src/connection.c
index aa4e1c0..3cb428c 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1014,6 +1014,16 @@ void __connman_connection_gateway_remove(struct
connman_service *service,
if (data)
set_default_gateway(data, type);
}
+
+ if (type == CONNMAN_IPCONFIG_TYPE_IPV4)
+ __connman_service_ipconfig_indicate_state(service,
+ CONNMAN_SERVICE_STATE_CONFIGURATION,
+ CONNMAN_IPCONFIG_TYPE_IPV4);
+
+ if (type == CONNMAN_IPCONFIG_TYPE_IPV6)
+ __connman_service_ipconfig_indicate_state(service,
+ CONNMAN_SERVICE_STATE_CONFIGURATION,
+ CONNMAN_IPCONFIG_TYPE_IPV6);
}
bool __connman_connection_update_gateway(void)
--
2.6.0.rc2.230.g3dd15c0
------------------------------
Message: 5
Date: Mon, 28 Dec 2015 17:07:09 +0800
From: ?? <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: question on missing features (mac address authentication)
in AP mode
Message-ID:
<CAKFk=cf7pao-sjp7q+vpfnpe0jopfm-jcb3vtt-5k4ggkqe...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Patrik,
Thanks for your reply. I understand connman will not give advanced AP
configuration support. And I will go to hostapd mailist.
2015-12-28 15:50 GMT+08:00 Patrik Flykt <[email protected]>:
> On Sun, 2015-12-27 at 11:31 +0800, ?? wrote:
>
> > Does connman has any plan to use hostapd for AP mode? any try or
> > consideration?
>
> ConnMan does not have any plans to use hostapd for AP mode. ConnMan is
> implementing the host side of things so it will need to have
> wpa_supplicant up and running in order to connect to WiFi networks. It
> implements decent tethering capabilities that a laptop or phone user can
> be assumed to be able to control. But ConnMan does not try to be a
> router device; therefore it lacks some of the more advanced and exotic
> configuration capabilities of a router.
>
> For a client end device MAC address filtering looks like a nuisance.
> It's very hard to have a decent API for it, not mention digging out the
> MAC address for various WiFi devices or believing that any UI using user
> should be able to figure out why some devices suddenly can connect while
> others can't. Besides, it does not give any extra security in the first
> place as the MAC address can be changed by an attacker.
>
> In general the wpa_supplicant/hostapd split is somehting you need to
> take up on the hostapd mailing list. After all it would be simpler for
> everybody if there were just one well-maintained daemon with a properly
> functioning D-Bus API.
>
> Cheers,
>
> Patrik
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20151228/a52b7d90/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 2, Issue 25
**************************************
