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: Iptables error with rule creation (Daniel Wagner)
2. [PATCH 1/2] wifi: Do not allow scan/autoscan on p2p connected
interface ([email protected])
3. [PATCH 2/2] wifi: Make sure to reply scan request when
connected with P2P ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Thu, 1 Jun 2017 12:48:39 +0200
From: Daniel Wagner <[email protected]>
To: Jeff Gray <[email protected]>
Cc: [email protected]
Subject: Re: Iptables error with rule creation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Jeff,
Your email got marked as spam. Too much HTML I guess.
On 05/30/2017 12:34 PM, Jeff Gray wrote:
> Yes, it is one from the vaults... I wish I was in a position to replace it.
>
> The iptables code in ConnMan is known to be not 100% correct on how
> it creates the iptables. It seems to okay for modern kernels but
> that is just luck. One way around this problem could be to replace
> the ConnMan code which creates the iptables with calling iptables
> shell command.
>
> Obviously there would be some forks involved but that would be the
> simplest solution in your situation I suppose. I wouldn't recommend
> to spend time figuring out what ConnMan is doing and what the kernel
> expects. I spend far too many hours myself on this topic. That's why
> I recommend to use the nftable implementation usally but that is
> probably not going to fly with 2.6.
>
>
> Thanks for the helpful suggestion. Has anyone else ever tried to do this?
>
> Would you be able to point me in the right direction in terms of what
> functional layer to insert iptables shell commands?
> I can see that at __connman_iptables_insert() for example, I have a
> fairly complete iptables parameter list already.
> Should I just ifdef out the existing iptables API calls? The code is
> fairly daunting to understand completely, so any help appreciated.
If you don't want to ifdef around I suggest to implement this API here:
struct firewall_context;
struct firewall_context *__connman_firewall_create(void);
void __connman_firewall_destroy(struct firewall_context *ctx);
int __connman_firewall_enable_nat(struct firewall_context *ctx,
char *address, unsigned char prefixlen,
char *interface);
int __connman_firewall_disable_nat(struct firewall_context *ctx);
int __connman_firewall_enable_snat(struct firewall_context *ctx,
int index, const char *ifname,
const char *addr);
int __connman_firewall_disable_snat(struct firewall_context *ctx);
int __connman_firewall_enable_marking(struct firewall_context *ctx,
enum connman_session_id_type id_type,
char *id, uint32_t mark);
int __connman_firewall_disable_marking(struct firewall_context *ctx);
int __connman_firewall_init(void);
void __connman_firewall_cleanup(void);
The iptables and nftable code do this. Just add a new file and hook it
up in the build process (Makefile.am). I think such a patch can be
easily maintained out of tree. Or if it is nicely done, I don't see a
real problem to accept it upstream.
The function names indicate what the implementation is supposed to do.
If you are just interested to get tethering working you need to
implement the NAT function, e.g. from firewall-iptables:
cmd = g_strdup_printf("-s %s/%d -o %s -j MASQUERADE",
address, prefixlen, interface);
firewall_add_rule(ctx, "nat", "POSTROUTING", cmd);
That roughly translates to
iptables -t nat -A POSTROUTING -s $addr/$mask \
-o $interface -j MASQUERADE
firewall-iptables.c does create additional custom chains called
'connman' but I don't think you really need it.
HTH!
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 1 Jun 2017 15:15:42 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH 1/2] wifi: Do not allow scan/autoscan on p2p connected
interface
Message-ID:
<1496330143-20732-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
In eed27a6e1d1 was introduced the concept of p2p_device to identify the
dedicated P2P-Group interface created by wpa_supplicant when a P2P
connection is established. This concept is used to deny Scan and Autoscan
(Introduced in b584447dde1) on P2P connected interfaces.
However, if wpa_supplicant is configured to not create such dedicated
P2P-Group interface and instead use directly the same one, then ConnMan
needs a way to continue denying Scan/Autoscan on that P2P connected
interface and that is the scope if this patch. With this modification,
the p2p_device flag is also used to temporally mark the current interface
connected with P2P.
---
plugins/wifi.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index a49031c..551cfea 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -402,8 +402,10 @@ static int peer_disconnect(struct connman_peer *peer)
&peer_params);
g_free(peer_params.path);
- if (ret == -EINPROGRESS)
+ if (ret == -EINPROGRESS) {
peer_cancel_timeout(wifi);
+ wifi->p2p_device = false;
+ }
return ret;
}
@@ -2981,6 +2983,14 @@ static void peer_changed(GSupplicantPeer *peer,
GSupplicantPeerState state)
connman_peer_set_as_master(connman_peer,
!g_supplicant_peer_is_client(peer));
connman_peer_set_sub_device(connman_peer, g_wifi->device);
+
+ /*
+ * If wpa_supplicant didn't create a dedicated p2p-group
+ * interface then mark this interface as p2p_device to avoid
+ * scan and auto-scan are launched on it while P2P is connected.
+ */
+ if (!g_list_find(p2p_iface_list, g_wifi))
+ wifi->p2p_device = true;
}
connman_peer_set_state(connman_peer, p_state);
--
1.9.1
------------------------------
Message: 3
Date: Thu, 1 Jun 2017 15:15:43 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH 2/2] wifi: Make sure to reply scan request when
connected with P2P
Message-ID:
<1496330143-20732-2-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
As analog situation of e04c74b1eba, in this case is also required that
plugin replies error to the scan request otherwise ConnMan will never
emit the D-Bus reply and counterpart application will go in D-Bus time-out.
For instance, this will always happen in a system with only one interface
with wpa_supplicant configured to not create dedicated P2P-Group interface
for P2P connections.
---
plugins/wifi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 551cfea..8059da7 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1802,7 +1802,7 @@ static int wifi_scan(enum connman_service_type type,
return -ENODEV;
if (wifi->p2p_device)
- return 0;
+ return -EBUSY;
if (wifi->tethering)
return -EBUSY;
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 20, Issue 1
**************************************
