Send connman mailing list submissions to
        connman@lists.01.org

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
        connman-requ...@lists.01.org

You can reach the person managing the list at
        connman-ow...@lists.01.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Re: [PATCH] gsupplicant: Propagate only property changes of
      the connected BSS (Daniel Wagner)
   2. Re: How to get IPv6 address ? (Daniel Wagner)
   3. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Daniel Wagner)
   4. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Daniel Wagner)
   5. Re: [PATCH v2] dnsproxy: Fix crash on malformed DNS response
      (Daniel Wagner)
   6. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Jonah Petri)
   7. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Jonah Petri)
   8. Re: When BackgroundScanning = false, connman's Scan() dbus
      method is broken (Daniel Wagner)


----------------------------------------------------------------------

Message: 1
Date: Wed, 9 Aug 2017 09:36:29 +0200
From: Daniel Wagner <w...@monom.org>
To: blanqui...@gmail.com
Cc: connman@lists.01.org
Subject: Re: [PATCH] gsupplicant: Propagate only property changes of
        the connected BSS
Message-ID: <be3452f8-e75b-be10-95e4-5d95a7f03...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Jose,

On 07/14/2017 11:33 AM, blanqui...@gmail.com wrote:
> From: Jose Blanquicet <jose.blanquicet-melen...@magnetimarelli.com>
> 
> A ConnMan service is a WiFi network identified by the SSID, security (none, 
> wep,
> psk and ieee8021x) and mode (managed, adhoc, ap). This WiFi network could be
> composed by multiple BSSs but it is shown as a single service by ConnMan. The
> properties of that network correspond to the best BSS (Currently, only the
> signal strength). The best BSS is the one with the highest signal strength. 
> Now,
> the issue is that ConnMan is selecting the best BSS by itself and it could 
> cause
> a misalignment with wpa_s; in particular when roaming. For instance, if 
> ConnMan
> updates the best BSS because there is a BSS with higher signal strength than 
> the
> current one but wpa_s takes too much time to roaming or even worse it never 
> does
> the roaming because such feature is not enabled in wpa_s; on both cases, 
> ConnMan
> will incorrectly start propagating the signal strength of the its best BSS but
> actually we are associated to another one. Therefore, in these cases, the 
> signal
> strength the user will see for that network comes from the BSS with the 
> highest
> signal not from the one he are actually associated.
> 
> This patch makes ConnMan memorize the WiFi network it gets associated
> (current_network). Then, from this point forward, the best BSS of that network
> will only be updated if wpa_s signals a disassociation or we got associated 
> with
> another BSS (roaming).
> 
> With this patch, ConnMan is now able to distinguish at gsupplicant level which
> is the BSS it is actually associated to because it will be always the best BSS
> of the associated network. This is useful for future developments.

I tested this patch for a while and everything still works nicely. 
Excellent work, thanks!

Patch applied.

Thanks,
Daniel


------------------------------

Message: 2
Date: Wed, 9 Aug 2017 11:02:05 +0200
From: Daniel Wagner <w...@monom.org>
To: Masashi Honma <masashi.ho...@gmail.com>, connman@lists.01.org
Subject: Re: How to get IPv6 address ?
Message-ID: <bf8b917d-1ed2-b5af-8304-662fc01ca...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

On 08/03/2017 10:43 PM, Masashi Honma wrote:
> I am trying to get IPv6 address with ConnMan.
> But no IPv6 (include link local address) could not be obtained.
> I could obtain IPv6 link local address and global addres with NetworkManager.
> So this is not a issue of my network.

ConnMan and NetworkManager run on the same kernel? Just want to make 
clear that the kernel configuration is the same.

> By my debugging, __connman_inet_ipv6_send_rs() calls ndisc_send_unspec() and
> the the ndisc_send_unspec calls sendmsg(). Then sendmsg() returns 
> EADDRNOTAVAIL.

According the manual pages sendmsg() is not supposed to return 
EADDRNOTAVAIL. I looked a bit at the kernel code I think the source of 
that error number is in net/ipv6/raw.c.

static int rawv6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
{
        [...]

        /* Raw sockets are IPv6 only */
        if (addr_type == IPV6_ADDR_MAPPED)
                return -EADDRNOTAVAIL;


        [...]
                /* ipv4 addr of the socket is invalid.  Only the
                 * unspecified and mapped address have a v4 equivalent.
                 */
                v4addr = LOOPBACK4_IPV6;
                if (!(addr_type & IPV6_ADDR_MULTICAST) &&
                    !sock_net(sk)->ipv6.sysctl.ip_nonlocal_bind) {
                        err = -EADDRNOTAVAIL;
                        if (!ipv6_chk_addr(sock_net(sk), &addr->sin6_addr,
                                           dev, 0)) {
                                goto out_unlock;
                        }
                }

        [...]
}

I don't really understand what is happening in here. The comments on 
IPV6_ADDR_MAPPED indicated that a configuration of IPV6 over IPV4 is 
enabled. The second one I can't really decode, it reads also some sort 
of IPV4/IPV6 mixing.

Don't know if there is a problem hidden.

> Then dst=ff02::2 and src=::. 

Is this after the second call of sendmsg() (that is 
__connman_inet_ipv6_send_rs() is called again)?

This would 'explain' why the return value of sendmsg() is not checked. I 
think we should do error checking and filter out the EADDDRNOTAVAIL if 
needed.

> By RFC 4861 "4.1. Router Solicitation Message
> Format", source address == :: is allowed... 

Okay.

> For reference, I have captured
> Router Solicitation of NetworkManager. dst is identical to ConnMan. src is
> Link local IPv6 Address of the interface.

Okay.

> I have captured the packets of ConnMan
> also, but no router solicitaion packets was captured.

So that means every call to sendmsg() fails?

> I will write my configurations.
> 
> boot arguments:
> $ sudo src/connmand --wifi=nl80211 --nodaemon --debug --device=enp0s25 
> --config /home/honma/connman.conf
> 
> config file:
> [General]
> PreferredTechnologies=wifi,ethernet,cellular
> SingleConnectedTechnology=false
> AlwaysConnectedTechnologies=wifi,ethernet,cellular
> 
> Other configs by commands:
> $ ./set-proxy <ethernet service> manual servers=URL:portno
> $ ./set-ipv4-method <ethernet service> off
> $ ./set-ipv6-method <ethernet service> auto

IIRC I tested the above configuration a long time ago. Most people will 
propably use always dual stack but IPv6 only should obviously also work.

Can you verify your IPv6 network setup again. Is it pure IPv6?

Thanks,
Daniel


------------------------------

Message: 3
Date: Wed, 9 Aug 2017 11:15:42 +0200
From: Daniel Wagner <w...@monom.org>
To: Sam Nazarko <em...@samnazarko.co.uk>, Jonah Petri
        <jo...@sense.com>, "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <8e3ef557-7ba7-f187-9c75-55ba59651...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed



On 08/08/2017 05:22 PM, Sam Nazarko wrote:
> ________________________________________
> From: connman <connman-boun...@lists.01.org> on behalf of Jonah Petri 
> <jo...@sense.com>
> Sent: 08 August 2017 16:10
> To: connman@lists.01.org
> Subject: When BackgroundScanning = false, connman's Scan() dbus method is 
> broken
> 
> I want to report an issue with connman.  We set BackgroundScanning = false in 
> main.conf.  However, I have found that this also causes connman to give an 
> erroneous empty response to the Scan() dbus call, potentially permanently 
> disabling the device.
> _______________________________________________
> connman mailing list
> connman@lists.01.org
> https://lists.01.org/mailman/listinfo/connman
> 
> Hello,
> 
> I can reproduce this issue. We wanted to disable BackgroundScanning as we 
> support
> a few wireless drivers that experience disruption to the connection when 
> scanning
> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
> reports of users unable to find any WiFi networks.

This worked in an older version of ConnMan? 1.33? This information would 
help to identify the commit which broke the feature.

Thanks,
Daniel


------------------------------

Message: 4
Date: Wed, 9 Aug 2017 12:35:10 +0200
From: Daniel Wagner <w...@monom.org>
To: Jonah Petri <jo...@sense.com>, Jose Blanquicet
        <blanqui...@gmail.com>
Cc: connman@lists.01.org
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <379b9e86-be94-6151-edf6-00dd7382c...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi

I added Jose to the list. He did some larger work in the recent days and 
might have an idea where the problem is.

On 08/08/2017 05:10 PM, Jonah Petri wrote:
> Hello,
> 
> I want to report an issue with connman.  We set BackgroundScanning = false in 
> main.conf.  However, I have found that this also causes connman to give an 
> erroneous empty response to the Scan() dbus call, potentially permanently 
> disabling the device.
> 
> The key preconditions seem to be:
> 1) wpa_supplicant reports a max_ssids > 1
> 2) the computer must have been previously associated to a SSID which is no 
> longer visible

'previously asscioated' is from a previous run? ConnMan has been 
restarted but not wpa_supplicant? Or the whole box has been restarted?

> 3) as above, BackgroundScanning must be set to false
> 
> This causes the logic of wifi.c:wifi_scan() to fail.  In particular:
> 1) wifi_scan_simple is not used, due to the above preconditions.
> 2) connman requests an active scan via wpa_supplicant for the ssids returned 
> by get_latest_connections.
> 3) connman does not request a followup passive scan, as BackgroundScanning is 
> turned off, which causes start_autoscan() to exit early.

autoscan is supposed to emulate the background scanning in ConnMan. 
According the following comment it should even be removed eventually:

/**
  * Used for autoscan "emulation".
  * Should be removed when wpa_s autoscan support will be by default.
  */
struct autoscan_params {
        int base;
        int limit;
        int interval;
        unsigned int timeout;
};

But it looks like it also used for the active scanning these days. If 
this true maybe the following patch might help (shot into the dark):



 From 6cff224046d80c71ad65eee3d2aae8cb8c22e4b5 Mon Sep 17 00:00:00 2001
From: Daniel Wagner <w...@monom.org>
Date: Wed, 9 Aug 2017 12:30:08 +0200
Subject: [PATCH] wifi: Setup autoscan independent of BackgroundScanning

The autoscan infrastructre is used to do active scan these
days. Because we don't initialize the default values for the algorithm
when BackgroundScanning is set to false, the autoscan algorithm wont
run at all (start_autoscan() checks for valid parameters).

Reported by Jonah Petri <jo...@sense.com>.
---
  plugins/wifi.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16dfd4486..d351ac0f0c9a 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1442,8 +1442,6 @@ static void setup_autoscan(struct wifi_data *wifi)
  {
        if (!wifi->autoscan)
                wifi->autoscan = parse_autoscan_params(AUTOSCAN_DEFAULT);
-
-       start_autoscan(wifi->device);
  }

  static void finalize_interface_creation(struct wifi_data *wifi)
@@ -1457,13 +1455,15 @@ static void finalize_interface_creation(struct 
wifi_data *wifi)

        connman_device_set_powered(wifi->device, true);

+       setup_autoscan(wifi);
+
        if (!connman_setting_get_bool("BackgroundScanning"))
                return;

        if (wifi->p2p_device)
                return;

-       setup_autoscan(wifi);
+       start_autoscan(wifi->device);
  }

  static void interface_create_callback(int result,
-- 
2.9.4


------------------------------

Message: 5
Date: Wed, 9 Aug 2017 12:40:17 +0200
From: Daniel Wagner <w...@monom.org>
To: Jukka Rissanen <jukka.rissa...@linux.intel.com>
Cc: connman@lists.01.org
Subject: Re: [PATCH v2] dnsproxy: Fix crash on malformed DNS response
Message-ID: <73571b7f-f82b-0cda-b11b-998dac362...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi Jukka,

On 08/09/2017 09:16 AM, Jukka Rissanen wrote:
> If the response query string is malformed, we might access memory
> pass the end of "name" variable in parse_response().
> ---
> v2: changed the max_name type to size_t

Patch applied.

Thanks,
Daniel


------------------------------

Message: 6
Date: Wed, 9 Aug 2017 10:08:03 -0400
From: Jonah Petri <jo...@sense.com>
To: Daniel Wagner <w...@monom.org>
Cc: Sam Nazarko <em...@samnazarko.co.uk>, "connman@lists.01.org"
        <connman@lists.01.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <8f64491c-7a48-4d07-8a97-68458b9bd...@sense.com>
Content-Type: text/plain; charset=us-ascii



> On Aug 9, 2017, at 5:15 AM, Daniel Wagner <w...@monom.org> wrote:
> 
> This worked in an older version of ConnMan? 1.33? This information would help 
> to identify the commit which broke the feature.

I don't know of a version of connman where this worked, but I have only tested 
1.33 and 1.34, as I mentioned in my original message.

Jonah

------------------------------

Message: 7
Date: Wed, 9 Aug 2017 10:24:35 -0400
From: Jonah Petri <jo...@sense.com>
To: Daniel Wagner <w...@monom.org>
Cc: Jose Blanquicet <blanqui...@gmail.com>, connman@lists.01.org
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <bfa170ff-4ead-49f7-aa46-c4f971a11...@sense.com>
Content-Type: text/plain; charset=us-ascii

Hi Daniel,

Thanks for having a look.  Comments below.

> On Aug 9, 2017, at 6:35 AM, Daniel Wagner <w...@monom.org> wrote:
> 
> Hi
> 
> I added Jose to the list. He did some larger work in the recent days and 
> might have an idea where the problem is.
> 
> On 08/08/2017 05:10 PM, Jonah Petri wrote:
>> Hello,
>> I want to report an issue with connman.  We set BackgroundScanning = false 
>> in main.conf.  However, I have found that this also causes connman to give 
>> an erroneous empty response to the Scan() dbus call, potentially permanently 
>> disabling the device.
>> The key preconditions seem to be:
>> 1) wpa_supplicant reports a max_ssids > 1
>> 2) the computer must have been previously associated to a SSID which is no 
>> longer visible
> 
> 'previously asscioated' is from a previous run? ConnMan has been restarted 
> but not wpa_supplicant? Or the whole box has been restarted?

In my case, the whole box has been restarted.  But, from code examination, if 
get_latest_connections() doesn't return empty, then the #2 precondition is 
satisfied.   I'm not sure all the ways that could become the case, but at least 
the following works: associating with a network, unplugging the device, 
unplugging the AP, then booting the device.

> 
>> 3) as above, BackgroundScanning must be set to false
>> This causes the logic of wifi.c:wifi_scan() to fail.  In particular:
>> 1) wifi_scan_simple is not used, due to the above preconditions.
>> 2) connman requests an active scan via wpa_supplicant for the ssids returned 
>> by get_latest_connections.
>> 3) connman does not request a followup passive scan, as BackgroundScanning 
>> is turned off, which causes start_autoscan() to exit early.
> 
> autoscan is supposed to emulate the background scanning in ConnMan. According 
> the following comment it should even be removed eventually:
> 
> /**
> * Used for autoscan "emulation".
> * Should be removed when wpa_s autoscan support will be by default.
> */
> struct autoscan_params {
>       int base;
>       int limit;
>       int interval;
>       unsigned int timeout;
> };
> 
> But it looks like it also used for the active scanning these days. If this 
> true maybe the following patch might help (shot into the dark):
> 

Thanks!  I see what you're doing there.  Isn't that change equivalent to always 
setting BackgroundScanning to true?  If so, that doesn't seem like the right 
thing. Better to deprecate and ignore BackgroundScanning, I would think.  I'll 
await Jose's comments as well.

Best,

Jonah

------------------------------

Message: 8
Date: Wed, 9 Aug 2017 17:12:26 +0200
From: Daniel Wagner <w...@monom.org>
To: Jonah Petri <jo...@sense.com>
Cc: Sam Nazarko <em...@samnazarko.co.uk>, "connman@lists.01.org"
        <connman@lists.01.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
        method is broken
Message-ID: <2294117b-d785-7d69-e3cd-be0a5f99c...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed



On 08/09/2017 04:08 PM, Jonah Petri wrote:
>> On Aug 9, 2017, at 5:15 AM, Daniel Wagner <w...@monom.org> wrote:
>>
>> This worked in an older version of ConnMan? 1.33? This information would 
>> help to identify the commit which broke the feature.
> 
> I don't know of a version of connman where this worked, but I have only 
> tested 1.33 and 1.34, as I mentioned in my original message.

I hoped that Sam is has some input on this. Sorry for the confusion.


------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 22, Issue 7
**************************************

Reply via email to