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 2/2] Force full wifi scan if it is a request over
dbus. (Daniel Wagner)
2. Re: [PATCH] Fix gsupplicant not to include empty entry
"SSIDs" in dbus message to wpa_supplicant (Daniel Wagner)
3. [PATCHv2] iptables: Set protocol family in xtables setup.
(Jussi Laakkonen)
4. Re: [PATCH 0/5] Add iptables IPv6 support (Jussi Laakkonen)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Dec 2018 11:05:23 +0100
From: Daniel Wagner <[email protected]>
To: Volodymyr Ostap <[email protected]>
Cc: [email protected], Vasyl Vavrychuk
<[email protected]>
Subject: Re: [PATCH 2/2] Force full wifi scan if it is a request over
dbus.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Volodymyr,
On 11.12.18 19:18, Volodymyr Ostap wrote:
> If there are stored connections and wifi is not connected
> the scan used to fall into scan on stored channels even it is
> a manually requested scan over dbus from an application.
> The application used to receive only APs on these channels.
>
> Now, if it is a scan request over dbus it scans on all channels and
> an application gets a full list of APs.
I have splited up your patch slightly and renamed a few bits. The result
is already in the tree. Please verify I didn't screw it up.
Thanks,
Daniel
------------------------------
Message: 2
Date: Wed, 12 Dec 2018 11:12:35 +0100
From: Daniel Wagner <[email protected]>
To: Volodymyr Ostap <[email protected]>
Cc: [email protected], Vasyl Vavrychuk
<[email protected]>
Subject: Re: [PATCH] Fix gsupplicant not to include empty entry
"SSIDs" in dbus message to wpa_supplicant
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Volodymyr,
On 11.12.18 19:20, Volodymyr Ostap wrote:
> To to an active wifi scan on all channels connman calls gsupplicant's
> g_supplicant_interface_scan() with empty list of frequencies and empty
> list of SSIDs. gsupplicant used to send an empty entry of "SSIDs" in this
> case.
> Sending the empty entry "SSIDs" to wpa_supplicant 2.6 triggers an error in
> wpas_dbus_get_scan_ssids() called from wpas_dbus_handler_scan().
> The function does not expect the empty list and fails with the error:
> "wpas_dbus_get_scan_ssids[dbus]: ssids must be an array of arrays of bytes"
Patch applied after slightly changing the commit message.
Thanks,
Daniel
------------------------------
Message: 3
Date: Wed, 12 Dec 2018 18:47:55 +0200
From: Jussi Laakkonen <[email protected]>
To: [email protected]
Subject: [PATCHv2] iptables: Set protocol family in xtables setup.
Message-ID: <[email protected]>
When xtables loads a library for a match (-m) the protocol family is
used to get a correct version loaded. If a change has been made using a
match modifier in iptables rule with, e.g., IPv4 protocol family the
global xtables_matches array holding xtables_match structures is not
reset or changed (at least in iptables 1.6.1) to IPv6 when
xtables_init_all() (or any of the initialization functions) is called.
This commit fixes the issue of not being able to set some IPv6 rules
after IPv4 rules with matches have been set (or the other way around).
The family for the global variable xtables_matches has to be explicitely
updated when changing between IP protocol families.
Otherwise adding the following rules would result a failure, where
iptables calls exit() on ConnMan on the IPv6 rule:
__connman_firewall_add_rule(ctx, "filter", "INPUT", "-m conntrack
--ctstate ESTABLISHED,RELATED -j ACCEPT");
__connman_firewall_add_ipv6_rule(ctx, "filter", "INPUT", "-m conntrack
--ctstate ESTABLISHED,RELATED -j ACCEPT");
Depending on the match type, iptables may result in an error. The exit()
is called if the required library for the match cannot be loaded. This
change allows to avoid such situations.
---
src/iptables.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/iptables.c b/src/iptables.c
index 305a553f..a188f99a 100644
--- a/src/iptables.c
+++ b/src/iptables.c
@@ -3330,6 +3330,7 @@ static int current_type = -1;
static int setup_xtables(int type)
{
int err;
+ struct xtables_match *xt_m;
DBG("%d", type);
@@ -3351,6 +3352,13 @@ static int setup_xtables(int type)
}
if (!err) {
+ /*
+ * Set the match type, otherwise loading of matches in xtables
+ * will fail when IP protocol family has changed.
+ */
+ for (xt_m = xtables_matches; xt_m; xt_m = xt_m->next)
+ xt_m->family = type;
+
current_type = type;
} else {
connman_error("error initializing xtables");
--
2.19.1
------------------------------
Message: 4
Date: Wed, 12 Dec 2018 18:50:35 +0200
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 0/5] Add iptables IPv6 support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 11/23/18 7:27 AM, Daniel Wagner wrote:
> Hi Jussi,
>
> On Thu, Nov 08, 2018 at 03:23:41PM +0200, Jussi Laakkonen wrote:
>> This patch set adds support for IPv6 iptables management into iptables.c.
>> Managing IPv6 iptables content differs only from the structure definition
>> parts so most of the IPv6 support is included into existing code.
>>
>> For each iptables.c exposed function a type variable has been added, which
>> indicates the IP protocol type. Common AF_* definitions are used (AF_INET &
>> AF_INET6) as types.
>>
>> Necessary changes for firewall-iptables.c and iptables-unit.c are applied.
>> Also a tool for testing ip6tables functionality is implemented as a copy of
>> the existing iptables-test.
>>
>> NAT tests for IPv6 are not included into unit tests as IPv6 NAT functionality
>> is not implemented within this work.
>
> Wow, that is a hugh effort! And also a big thank you for taking the
> time write the commit messages.
>
> I've applied the whole series. If there are any problem we fix that in
> on top of it. Not that I expect any problems :)
>
> Thanks,
> Daniel
>
You are welcome. If I'd have more time I'd tailor more of the changes
I've made into upstreamable format. I hope I could at some point write a
draft about things I've had in mind to propose to upstream ConnMan.
Sincerely,
Jussi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 38, Issue 3
**************************************
