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: connmanctl scan wifi: Error /net/connman/technology/wifi:
Not implemented (Daniel Wagner)
2. Re: Failed to create storage directory: No such file or
directory (Daniel Wagner)
3. Re: [PATCH v2 1/1] service: Start online check on IP address
update (Daniel Wagner)
4. [PATCH] service: Group online functions (Daniel Wagner)
5. Re: dnsproxy: invalid answer where there are no DNS servers
available (Daniel Wagner)
6. Re: WISPr authentication (Daniel Wagner)
7. Re: [PATCH v2 1/1] service: Start online check on IP address
update (Robert Tiemann)
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 Apr 2019 08:12:24 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: connmanctl scan wifi: Error /net/connman/technology/wifi:
Not implemented
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> and /now/ cmst had a "Rescan" button and showed wireless networks
>
> * ran my-set wlan-off
> --> the rescan button grayed out in the still running cmst
> * ran my-set wlan-on
> --> the rescan button STAYED grayed out :(
> * exited cmst
> * restarted cmst
> --> the rescan button was STILL grayed out !! :((
> * systemctl restart connman.service
> * started cmst
> --> the rescan button was not grayed out anymore
>
> So it seems to me that connman.service might not handle well the fact
> that I remove and then add wlan kernel modules??
ConnMan relies on wpa_supplicant. wpa_supplicant relies on the kernel
modules to behave correctly. You need to check first if
wpa_supplicant/drivers do report the right thing.
> It turns out that connman needs an extra push (manually) by
> issuing connmanctl disable wifi, connmanctl enable wifi after reloading
> the kernel modules, before connmanctl scan wifi works.
This sounds more like a wpa_supplicant/driver problem. I saw the same
behavior on a USB WiFi dongle. When I am using iwd, all works fine.
------------------------------
Message: 2
Date: Mon, 1 Apr 2019 08:15:55 +0200
From: Daniel Wagner <[email protected]>
To: Jussi Laakkonen <[email protected]>, JH
<[email protected]>
Cc: connman <[email protected]>
Subject: Re: Failed to create storage directory: No such file or
directory
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Good Morning Jussi,
On 3/28/19 11:07 AM, Jussi Laakkonen wrote:
> On 3/27/19 9:24 PM, Daniel Wagner wrote:
>> 1.4.21 released on 22.11.2013
>> 1.6.1? released on 02.02.2018
>> 1.8.0? released on 07.07.2018
>> 1.8.1? released on 23.10.2018
>> 1.8.2? releases on 13.11.2018
>
> Well, upping the requirement is quite tricky as we also noticed.
> Iptables 1.8.2 (and I'm guessing rest of the 1.8.x) will require newer
> kernel headers that are available with 4.2.8. Unless the system is
> running fairly up-to-date kernel it requires another patch for the
> kernel headers.
Good point.
> My Debian, for example, seems to use 1.6.1 still, which we had also used
> with older 3.x kernels without any problems. Except when we started to
> use iptables for IPv6 as well via ConnMan (I should make these firewall
> changes into a separate plugin and try to upstream it someday) we needed
> to patch iptables.
>
> Upping the version requirement would anyways require some patching on
> systems running older versions of kernel or iptables. Depending on the
> use of course :).
Maybe we should just add a warning/recommendation instead. 'Saying you
are using a dated iptables which might not work correctly.' So people
can check if they are happy with what they get.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 1 Apr 2019 08:26:37 +0200
From: Daniel Wagner <[email protected]>
To: Robert Tiemann <[email protected]>, [email protected]
Subject: Re: [PATCH v2 1/1] service: Start online check on IP address
update
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Robert,
On 3/28/19 1:18 PM, Robert Tiemann wrote:
> This patch enables ConnMan to enter online state after getting IP
> configuration via DHCP when coming from an IPV4LL configuration.
Patch applied. I saw we could drop the start_online_check() forward
deceleration by reordering. I'll send a patch for this.
Thanks,
Daniel
------------------------------
Message: 4
Date: Mon, 1 Apr 2019 08:26:53 +0200
From: Daniel Wagner <[email protected]>
To: [email protected]
Cc: Daniel Wagner <[email protected]>
Subject: [PATCH] service: Group online functions
Message-ID: <[email protected]>
We can drop start_online_check() function declaration now by
reordering the helper functions and move them in the right order.
---
src/service.c | 102 +++++++++++++++++++++++++-------------------------
1 file changed, 50 insertions(+), 52 deletions(-)
diff --git a/src/service.c b/src/service.c
index 0d0817550853..912c60952d1b 100644
--- a/src/service.c
+++ b/src/service.c
@@ -144,8 +144,6 @@ static struct connman_ipconfig *create_ip4config(struct
connman_service *service
static struct connman_ipconfig *create_ip6config(struct connman_service
*service,
int index);
static void dns_changed(struct connman_service *service);
-static void start_online_check(struct connman_service *service,
- enum connman_ipconfig_type type);
struct find_data {
const char *path;
@@ -1390,6 +1388,56 @@ void __connman_service_nameserver_del_routes(struct
connman_service *service,
nameserver_del_routes(index, service->nameservers, type);
}
+static bool check_proxy_setup(struct connman_service *service)
+{
+ /*
+ * We start WPAD if we haven't got a PAC URL from DHCP and
+ * if our proxy manual configuration is either empty or set
+ * to AUTO with an empty URL.
+ */
+
+ if (service->proxy != CONNMAN_SERVICE_PROXY_METHOD_UNKNOWN)
+ return true;
+
+ if (service->proxy_config != CONNMAN_SERVICE_PROXY_METHOD_UNKNOWN &&
+ (service->proxy_config != CONNMAN_SERVICE_PROXY_METHOD_AUTO ||
+ service->pac))
+ return true;
+
+ if (__connman_wpad_start(service) < 0) {
+ service->proxy = CONNMAN_SERVICE_PROXY_METHOD_DIRECT;
+ __connman_notifier_proxy_changed(service);
+ return true;
+ }
+
+ return false;
+}
+
+static void cancel_online_check(struct connman_service *service)
+{
+ if (service->online_timeout == 0)
+ return;
+
+ g_source_remove(service->online_timeout);
+ service->online_timeout = 0;
+ connman_service_unref(service);
+}
+
+static void start_online_check(struct connman_service *service,
+ enum connman_ipconfig_type type)
+{
+ if (!connman_setting_get_bool("EnableOnlineCheck")) {
+ connman_info("Online check disabled. "
+ "Default service remains in READY state.");
+ return;
+ }
+
+ if (type != CONNMAN_IPCONFIG_TYPE_IPV4 || check_proxy_setup(service)) {
+ cancel_online_check(service);
+ __connman_service_wispr_start(service, type);
+ }
+}
+
static void address_updated(struct connman_service *service,
enum connman_ipconfig_type type)
{
@@ -5930,31 +5978,6 @@ enum connman_service_state
__connman_service_ipconfig_get_state(
return CONNMAN_SERVICE_STATE_UNKNOWN;
}
-static bool check_proxy_setup(struct connman_service *service)
-{
- /*
- * We start WPAD if we haven't got a PAC URL from DHCP and
- * if our proxy manual configuration is either empty or set
- * to AUTO with an empty URL.
- */
-
- if (service->proxy != CONNMAN_SERVICE_PROXY_METHOD_UNKNOWN)
- return true;
-
- if (service->proxy_config != CONNMAN_SERVICE_PROXY_METHOD_UNKNOWN &&
- (service->proxy_config != CONNMAN_SERVICE_PROXY_METHOD_AUTO ||
- service->pac))
- return true;
-
- if (__connman_wpad_start(service) < 0) {
- service->proxy = CONNMAN_SERVICE_PROXY_METHOD_DIRECT;
- __connman_notifier_proxy_changed(service);
- return true;
- }
-
- return false;
-}
-
/*
* How many networks are connected at the same time. If more than 1,
* then set the rp_filter setting properly (loose mode routing) so that network
@@ -6068,31 +6091,6 @@ int __connman_service_online_check_failed(struct
connman_service *service,
return EAGAIN;
}
-static void cancel_online_check(struct connman_service *service)
-{
- if (service->online_timeout == 0)
- return;
-
- g_source_remove(service->online_timeout);
- service->online_timeout = 0;
- connman_service_unref(service);
-}
-
-static void start_online_check(struct connman_service *service,
- enum connman_ipconfig_type type)
-{
- if (!connman_setting_get_bool("EnableOnlineCheck")) {
- connman_info("Online check disabled. "
- "Default service remains in READY state.");
- return;
- }
-
- if (type != CONNMAN_IPCONFIG_TYPE_IPV4 || check_proxy_setup(service)) {
- cancel_online_check(service);
- __connman_service_wispr_start(service, type);
- }
-}
-
int __connman_service_ipconfig_indicate_state(struct connman_service *service,
enum connman_service_state new_state,
enum connman_ipconfig_type type)
--
2.20.1
------------------------------
Message: 5
Date: Mon, 1 Apr 2019 08:29:32 +0200
From: Daniel Wagner <[email protected]>
To: Nuno Gon?alves <[email protected]>, [email protected]
Subject: Re: dnsproxy: invalid answer where there are no DNS servers
available
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Nuno,
On 3/28/19 2:40 PM, Nuno Gon?alves wrote:
> Hi,
>
> Typing "ping abcd", where abcd does not exist on /etc/hosts or in the
> search domains, will usually hang for a while with Connman.
>
> I've compared with other systems and my conclusion is that libnss_dns
> is retrying the DNS request to connman, since connman answer does not
> include the query field.
>
> This behaviour comes from [1], where both a invalid Query and no
> upstream servers are handled in the same way.
>
> I believe the query field must be part of the answer when the Query
> message was valid, but just happens to not be possible to resolve.
Thanks for you report. Do you happen to have a patch for this? I suppose
you have the setup already running for testing.
Thanks,
Daniel
------------------------------
Message: 6
Date: Mon, 1 Apr 2019 08:34:10 +0200
From: Daniel Wagner <[email protected]>
To: Thomas Green <[email protected]>
Cc: connman <[email protected]>
Subject: Re: WISPr authentication
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Thomas,
On 3/28/19 11:12 PM, Thomas Green wrote:
> In addition to the log file I sent, here is a 'pcap' file suitable for use by
> wireshark to see what was happening on the wireless interface. Also, as you
> can tell, I've upgraded this to connman1.36. Thanks
I don't have the WISPr specification, so I can't really say what happens
in 307. My guts feeling is that it is handled like a portal has been
detected.
Maybe someone with the spec can help out? :)
Thanks,
Daniel
------------------------------
Message: 7
Date: Mon, 1 Apr 2019 10:53:14 +0200
From: Robert Tiemann <[email protected]>
To: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: [PATCH v2 1/1] service: Start online check on IP address
update
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 4/1/19 8:26 AM, Daniel Wagner wrote:
> On 3/28/19 1:18 PM, Robert Tiemann wrote:
>> This patch enables ConnMan to enter online state after getting IP
>> configuration via DHCP when coming from an IPV4LL configuration.
>
> Patch applied. I saw we could drop the start_online_check() forward
> deceleration by reordering. I'll send a patch for this.
Thank you. I did the forward declaration to keep the patch small,
thanks for cleaning this up. :) Current master + your patch works
well here.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 42, Issue 1
**************************************
