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] plugins/wifi: Do not disable network on
Disconnect (Naveen Singh)
2. Re: [PATCH] gweb: Remove multiple return and close()
statements in resolver code (Patrik Flykt)
3. Re: [PATCH] dnsproxy: Fix memory leak in update_domain
(Patrik Flykt)
4. Re: [PATCH] config: space as last character in passphrase
(Patrik Flykt)
5. Re: [PATCHv2] iptables-unit: Fixed dereferencing null pointer
in assert_rule() (Patrik Flykt)
6. Re: RFC: multipath routing for services and sessions
(Patrik Flykt)
7. Re: RFC: multipath routing for services and sessions
(Dragos Tatulea)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Mar 2016 13:23:28 -0700
From: Naveen Singh <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH] plugins/wifi: Do not disable network on
Disconnect
Message-ID:
<cafk1zrdybmdzthbwnm-aj_2r8u+szsplgzxidc-tku+mxhr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Mar 21, 2016 at 4:44 AM, Patrik Flykt <[email protected]>
wrote:
> On Mon, 2016-03-14 at 15:07 -0700, Naveen Singh wrote:
> > Thanks Patrik for the history. So looks like code was disabling
> > network in case of disconnect was received while device was in 4 way
> > hand shake state. Now by moving the code out from the function we
> > pretty much let wpa_supplicant try to connect on its own.
> >
> > Should not we let wpa_supplicant try to connect on its own
> > irrespective of reason code. Once wpa_supplicant is armed with a
> > profile (which would have happened as a part of a previous
> > AddNetwork), wpa_supplicant would keep trying to connect to that SSID
> > for ever. The only time when connman chooses a different SSID is when
> > wpa_supplicant should stop scanning and try connecting with the new
> > SSID.
> >
> > Tying this with reason code may lead to issue. Consider following
> > scenario when there are multiple AP with same SSID and device is
> > connected to one.
> >
> > 1) Device is connected with BSSID1.
> > 2) BSSID1 disappears so disconnect does not happen with any specific
> > reason code. Reason code may be 0 in this case.
> > 3) So in this case we would end up disabling the network and
> > wpa_supplicant will not try to connect on its own.
> > 4) The next connect attempt from connman is happening for the same
> > SSID connman will not even do AddNetwork as disabling the network is
> > not removing the network and hence network path may not be NULL.
> >
> > I think until and unless there is a bug in wpa_supplicant where it
> > stops trying to connect even if it has an active profile connman
> > should never disable the network. And when connman decides to connect
> > to a different service, remove the previous one, add the new one and
> > let wpa_supplicant handle things from there.
>
> ConnMan in general cannot leave wpa_supplicant to connect on its own. As
> there are other networking technologies with priority higher than WiFi,
> that network may have been connected meanwhile. When that is the case,
> wpa_supplicant need to be told it does and not should not do anything
> meanwhile. Also, as ConnMan got a list of networks from wpa_supplicant,
> ConnMan also wants to try the second and third best networks to connect.
> In addition ConnMan breaks connections only when a better other network
> technology becomes available, not when another previously seen WiFi
> reappears.
When there is a better network or even a technology available to connect,
connman would go ahead and remove that network anyway. This would end
wpa_supplicant attempt of connecting to that network. So connman is still
the master over here. The only time when wpa_supplicant will try to connect
on its own is between device getting disconnected till connman has
something different. And say if connman or application has nothing
different then let wpa_supplicant try on its own. If connman has only one
wifi network to connect, then connman does not even have to do AddNetwork
as this network is already plumbed to wpa_s.
>
> So unless the proper set of reason codes cannot be obtained from
> wpa_supplicant indicating that the disconnection is due to a lower level
> issue that can be ignored, wpa_supplicant should not be left connecting
> by its own.
>
Tying this up with a specific reason code may not be correct as reason code
are always not available. Consider an example where device intermittently
faced beacon loss (because of interference) and we know AP exists. wpa_s
will get device connected back immediately. In the other case if we would
have disabled the network (as reason code coming with this disconnect
notification is not 6, 7 or 4), re-connection would have taken longer.
I guess connman is still the master as it can remove any network anytime
because of any reason (better technology or better network). Only time
wpa_s will try to connect on its own is when it has an active profile and
device is not connected and connman has nothing new to try for.
Let me know your thoughts.
Regards
Naveen
>
> Cheers,
>
> Patrik
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160321/f247900b/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 22 Mar 2016 11:27:38 +0200
From: Patrik Flykt <[email protected]>
To: Milind Ramesh Murhekar <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH] gweb: Remove multiple return and close()
statements in resolver code
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-03-11 at 14:07 +0530, Milind Ramesh Murhekar wrote:
> Description: This patch removes the multiple return and close()
> statements instead to use single line of code, as per connman coding style
Applied, thanks!
Patrik
------------------------------
Message: 3
Date: Tue, 22 Mar 2016 11:27:56 +0200
From: Patrik Flykt <[email protected]>
To: Slava Monich <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] dnsproxy: Fix memory leak in update_domain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-03-17 at 16:31 +0200, Slava Monich wrote:
> ---
Applied, thanks!
Patrik
------------------------------
Message: 4
Date: Tue, 22 Mar 2016 11:28:34 +0200
From: Patrik Flykt <[email protected]>
To: [email protected]
Cc: [email protected], Naveen Singh <[email protected]>
Subject: Re: [PATCH] config: space as last character in passphrase
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2016-03-15 at 18:54 -0700, [email protected] wrote:
> From: Naveen Singh <[email protected]>
>
> If in the example.config file, passphrase has space (\s)
> in the end, it gets stripped while creating the service
> directory. This causes 4 way hand shake to fail. This commit
> allows space as the last character in passphrase by not stripping
> it.
>
> Tested with various combinations of passphrase
Applied with a bit of permutation, thanks!
Patrik
------------------------------
Message: 5
Date: Tue, 22 Mar 2016 11:28:59 +0200
From: Patrik Flykt <[email protected]>
To: Nishant Chaprana <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCHv2] iptables-unit: Fixed dereferencing null pointer
in assert_rule()
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2016-03-15 at 18:26 +0530, Nishant Chaprana wrote:
> ---
Applied, thanks!
Patrik
------------------------------
Message: 6
Date: Tue, 22 Mar 2016 11:43:23 +0200
From: Patrik Flykt <[email protected]>
To: Dragos Tatulea <[email protected]>
Cc: [email protected]
Subject: Re: RFC: multipath routing for services and sessions
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Mon, 2016-03-14 at 18:20 +0100, Dragos Tatulea wrote:
> Hello,
>
> We've been working recently on adding a few features to ConnMan for
> Multipath TCP. However, most features are not related to Multipath TCP
> and they could be useful in upstream. Please let me know what is of
> interest from the list below:
>
> * Per service multipath routing: This is a per service flag that
> allows the installation of a multipath table for a service.
> Something in the lines of:
>
> $> ip rule
> 0: from all lookup local
> 32763: from 10.10.3.2 lookup 283
> 32764: from 10.10.2.2 lookup 281
> 32765: from 10.10.1.2 lookup 279
> 32766: from all lookup main
> 32767: from all lookup default
>
> $> ip route show table 283
> default via 10.10.3.1 dev vethc3
> 10.10.3.0/24 dev vethc3 scope link
>
> There are 3 services above with multipath routing on.
>
> There's also a generic switch to turn it on by default in all
> services.
>
> * Multipath routing support for sessions: Each session contains a list
> of services that are added automatically if they have the multipath
> option set and they are considered connected. For all those services,
> fwmark + src ip rules are created to the service multipath routing
> table. It would look like this:
>
> $ ip rule
> 0: from all lookup local
> 32760: from 10.10.1.2 fwmark 0x10000 lookup 261
> 32761: from 10.10.3.2 fwmark 0x10000 lookup 265
> 32762: from all fwmark 0x10000 lookup 65536
> 32763: from 10.10.3.2 lookup 265
> 32764: from 10.10.2.2 lookup 263
> 32765: from 10.10.1.2 lookup 261
> 32766: from all lookup main
> 32767: from all lookup default
>
> The default service is not added to this list. But it has the
> default rule (32762).
>
> It's also possible to modify the list via the DBus API.
>
> * Flow Selectors: this is a fancy name for per session 5 tuple
> iptables rules. A 5 tuple contains: source/destination ip,
> protocol (tcp|udp), source/destination port. Fields can also be
> omitted. 3 rules would look like this:
>
> $ iptables -t mangle -L
> ...
> Chain connman-OUTPUT (1 references)
> target prot opt source destination
> MARK tcp -- 11.11.11.11 22.22.22.22 tcp spt:1111 dpt:2222 MARK set 0x10000
> MARK all -- 33.33.33.33 44.44.44.44 MARK set 0x10000
> MARK udp -- anywhere anywhere udp spt:7777 dpt:8888 MARK set 0x10000
> ...
>
> Currently these tules are only added to the output chain. But that can
> be made more flexible.
>
> These work as/in tandem with policy descriptors. The idea is to bind
> a certain kind of traffic to a session. However, you don't necessarily
> need a policy file for them. They can be set via the session API too.
>
>
> Would these features be interesting for upstream ConnMan? If yes, I'd
> gladly split the current patches [1] into per feature patch sets and
> send them here. Please let me know.
>
> [1] - https://github.com/endocode/connman/tree/work
>
> Thanks
I'm a bit lost with the overall context here. Shouldn't RFC 6897 be able
to handle all application needs with a generic per interface
administrative option whether Multipath TCP is (dis)allowed on a
particular interface? I sort of can see a Session knob regarding
Multipath TCP, but then again it might not be possible to satisfy that
request anyway, as the user can choose otherwise and force a
non-Multipath TCP interface to be used anyway.
Could you describe the overall neighborhood around ConnMan and Multipath
TCP where specific capabilities are needed by ConnMan to get everything
working better than currently expected?
Cheers,
Patrik
------------------------------
Message: 7
Date: Tue, 22 Mar 2016 11:00:03 +0100
From: Dragos Tatulea <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: [email protected]
Subject: Re: RFC: multipath routing for services and sessions
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 03/22/2016 10:43 AM, Patrik Flykt wrote:
>
> Hi,
>
> On Mon, 2016-03-14 at 18:20 +0100, Dragos Tatulea wrote:
>> Hello,
>>
>> We've been working recently on adding a few features to ConnMan for
>> Multipath TCP. However, most features are not related to Multipath TCP
>> and they could be useful in upstream. Please let me know what is of
>> interest from the list below:
>>
>> * Per service multipath routing: This is a per service flag that
>> allows the installation of a multipath table for a service.
>> Something in the lines of:
>>
>> $> ip rule
>> 0: from all lookup local
>> 32763: from 10.10.3.2 lookup 283
>> 32764: from 10.10.2.2 lookup 281
>> 32765: from 10.10.1.2 lookup 279
>> 32766: from all lookup main
>> 32767: from all lookup default
>>
>> $> ip route show table 283
>> default via 10.10.3.1 dev vethc3
>> 10.10.3.0/24 dev vethc3 scope link
>>
>> There are 3 services above with multipath routing on.
>>
>> There's also a generic switch to turn it on by default in all
>> services.
>>
>> * Multipath routing support for sessions: Each session contains a list
>> of services that are added automatically if they have the multipath
>> option set and they are considered connected. For all those services,
>> fwmark + src ip rules are created to the service multipath routing
>> table. It would look like this:
>>
>> $ ip rule
>> 0: from all lookup local
>> 32760: from 10.10.1.2 fwmark 0x10000 lookup 261
>> 32761: from 10.10.3.2 fwmark 0x10000 lookup 265
>> 32762: from all fwmark 0x10000 lookup 65536
>> 32763: from 10.10.3.2 lookup 265
>> 32764: from 10.10.2.2 lookup 263
>> 32765: from 10.10.1.2 lookup 261
>> 32766: from all lookup main
>> 32767: from all lookup default
>>
>> The default service is not added to this list. But it has the
>> default rule (32762).
>>
>> It's also possible to modify the list via the DBus API.
>>
>> * Flow Selectors: this is a fancy name for per session 5 tuple
>> iptables rules. A 5 tuple contains: source/destination ip,
>> protocol (tcp|udp), source/destination port. Fields can also be
>> omitted. 3 rules would look like this:
>>
>> $ iptables -t mangle -L
>> ...
>> Chain connman-OUTPUT (1 references)
>> target prot opt source destination
>> MARK tcp -- 11.11.11.11 22.22.22.22 tcp spt:1111 dpt:2222 MARK set 0x10000
>> MARK all -- 33.33.33.33 44.44.44.44 MARK set 0x10000
>> MARK udp -- anywhere anywhere udp spt:7777 dpt:8888 MARK set 0x10000
>> ...
>>
>> Currently these tules are only added to the output chain. But that can
>> be made more flexible.
>>
>> These work as/in tandem with policy descriptors. The idea is to bind
>> a certain kind of traffic to a session. However, you don't necessarily
>> need a policy file for them. They can be set via the session API too.
>>
>>
>> Would these features be interesting for upstream ConnMan? If yes, I'd
>> gladly split the current patches [1] into per feature patch sets and
>> send them here. Please let me know.
>>
>> [1] - https://github.com/endocode/connman/tree/work
>>
>> Thanks
>
> I'm a bit lost with the overall context here. Shouldn't RFC 6897 be able
> to handle all application needs with a generic per interface
> administrative option whether Multipath TCP is (dis)allowed on a
> particular interface? I sort of can see a Session knob regarding
> Multipath TCP, but then again it might not be possible to satisfy that
> request anyway, as the user can choose otherwise and force a
> non-Multipath TCP interface to be used anyway.
>
Multipath TCP needs multipath routing tables to be installed for each
interface. [1]
> Could you describe the overall neighborhood around ConnMan and Multipath
> TCP where specific capabilities are needed by ConnMan to get everything
> working better than currently expected?
>
I'll do my best to answer this: The context of these patches was to get
Multipath TCP working with ConnMan automatically. The most basic part was
to install a source based routing table for every active service. This has
nothing to do with Multipath TCP. We thought it's a standalone feature that
could be useful in ConnMan. The more complicated but still useful parts
are described in the initial email.
[1]
http://web.archive.org/web/20160310105619/http://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting
(Website is currently down for some reason.)
Thanks
--
Dragos Tatulea
Software Developer @ Endocode AG
[email protected]
Endocode AG, Br?ckenstra?e 5A, 10179 Berlin
+49 30 1206 4472 | [email protected] | www.endocode.com
Vorstandsvorsitzender: Mirko Boehm
Vorst?nde: Dr. Thomas Fricke, Sebastian Sucker
Aufsichtsratsvorsitzende: Alexandra Boehm
Registergericht: Amtsgericht Charlottenburg - HRB 150748 B
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 5, Issue 26
**************************************
