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] Add AlwaysUseFallbackNameservers flag in the
configuration file. When it is enabled, the fallback name servers
will be used even though some name servers are provided by the
service. (Patrik Flykt)
2. Re: [PATCH] gdhcp: use opened listening socket to send DHCP
renew request (Patrik Flykt)
3. Re: nftables (Daniel Wagner)
4. Re: nftables (Patrik Flykt)
5. Re: nftables (Daniel Wagner)
6. Delete STORAGEDIR folders when services are removed
(Marco Maniezzo)
7. [PATCH 1/2] delete STORAGEDIR folders - documentation
(Marco Maniezzo)
8. [PATCH 2/2] delete STORAGEDIR folders - sources (Marco Maniezzo)
----------------------------------------------------------------------
Message: 1
Date: Fri, 26 Feb 2016 09:39:41 +0200
From: Patrik Flykt <[email protected]>
To: wangfe-nestlabs <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Add AlwaysUseFallbackNameservers flag in the
configuration file. When it is enabled, the fallback name servers will
be used even though some name servers are provided by the service.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-02-25 at 10:52 -0800, wangfe-nestlabs wrote:
> Background information.
>
> Connmand will not use fallback name servers when some name servers are
> provided by DHCP reply. But in some cases, the ISP provided its own
> name servers can?t be down, then DNS won?t work. So some requirement
> is to use some fallback name severs such as 8.8.8.8, 8.8.4.4 for
> backup.
>
> Add the option flag ?AlwaysUseFallbackNameservers?. Which it is
> enabled, the fallback name servers are appended to name server list,
> and will be used. The duplicate servers will be filtered out in the
> __connman_service_nameserver_append.
NACK. FallBackNameservers are just that, a list of servers to use when
there are zero nameservers provided otherwise. Every service has already
a Nameservers.Configuration attribute which takes precedence over the
ones provided by DHCP.
Cheers,
Patrik
------------------------------
Message: 2
Date: Fri, 26 Feb 2016 09:42:23 +0200
From: Patrik Flykt <[email protected]>
To: Feng Wang <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] gdhcp: use opened listening socket to send DHCP
renew request
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2016-02-24 at 11:32 -0800, Feng Wang wrote:
> But in some cases, the socket is closed after the DHCP ACK is
> received.
What are these cases on ConnMan side where the socket is closed after
the ACK is received? Or what code path does the code take in that case?
Isn't it easier to identify that code path or special case and figure
out if there is an easier solution fixing it?
Cheers,
Patrik
------------------------------
Message: 3
Date: Fri, 26 Feb 2016 09:19:23 +0100
From: Daniel Wagner <[email protected]>
To: "Zheng, Wu" <[email protected]>, "Tomasz Bursztyka
([email protected])" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi,
On 02/23/2016 10:37 AM, Zheng, Wu wrote:
>> Yes, it makes sense to abandon iptables.
>
> At current, if nftable need to be implemented in Connman, should
> connman support both iptables and nftables, right?
>
> If system only support iptables, connman need to support it too. Right?
Indeed I was thinking to replace iptables and not have nftables
and iptables to coexist. The iptables rules set are visible on
the highest layer, e.g
rule #1
src/nat.c- cmd = g_strdup_printf("-s %s/%d -o %s -j MASQUERADE",
src/nat.c- nat->address,
src/nat.c- nat->prefixlen,
src/nat.c- nat->interface);
rule #2
src/session.c: err = __connman_firewall_add_rule(fw, "mangle", "INPUT",
src/session.c- "-j CONNMARK --restore-mark");
src/session.c: err = __connman_firewall_add_rule(fw, "mangle", "POSTROUTING",
src/session.c- "-j CONNMARK --save-mark");
rule #3
src/session.c- case CONNMAN_SESSION_ID_TYPE_UID:
src/session.c: err = __connman_firewall_add_rule(fw, "mangle",
"OUTPUT",
src/session.c- "-m owner --uid-owner %s -j MARK
--set-mark %d",
src/session.c-
session->policy_config->id,
src/session.c- session->mark);
src/session.c- break;
src/session.c- case CONNMAN_SESSION_ID_TYPE_GID:
src/session.c: err = __connman_firewall_add_rule(fw, "mangle",
"OUTPUT",
src/session.c- "-m owner --gid-owner %s -j MARK
--set-mark %d",
src/session.c-
session->policy_config->id,
src/session.c- session->mark);
src/session.c- break;
rule #4
src/session.c: id = __connman_firewall_add_rule(session->fw, "nat",
"POSTROUTING",
src/session.c- "-o %s -j SNAT --to-source %s",
src/session.c- ifname, addr);
In order to have iptables and nftables available (the implementation will be
selected
at compile time) we need to do either
a) translate the iptables rules to nftables rules
b) come up with a generic rule API
c) introduce a bunch of specific rule functions which implemented
by iptables and nftables subsystem.
I think a) is pretty dirty and we should not do it. b) is way to
complex for what we do. c) would be a good compromise and it helps
the transitions phase. When we finally rip out iptables
this wrapper API could get removed as well.
So what about something like this:
rule #1
__connman_firewall_enable_masquerade(struct firewall_context *ctx);
__connman_firewall_disable_masquerade(struct firewall_context *ctx);
rule #2
__connman_firewall_enable_connection_tracking(struct firewall_context *ctx);
__connman_firewall_disable_connection_tracking(struct firewall_context *ctx);
rule #3
__connman_firewall_enable_marking(struct firewall_context *ctx,
enum connman_session_id_type,
chard *id, uint32_t mark);
__connman_firewall_disable_marking(struct firewall_context *ctx);
rule #4
__connman_firewall_enable_snat(struct firewall_context *ctx,
char *ifname, char *addr);
__connman_firewall_disable_snat(struct firewall_context *ctx);
Obviously, the naming sucks.
Comments, ideas, rants?
cheers,
daniel
------------------------------
Message: 4
Date: Fri, 26 Feb 2016 10:51:01 +0200
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 2016-02-26 at 09:19 +0100, Daniel Wagner wrote:
> Hi,
>
> Indeed I was thinking to replace iptables and not have nftables
> and iptables to coexist. The iptables rules set are visible on
> the highest layer, e.g
>
> rule #1
> src/nat.c- cmd = g_strdup_printf("-s %s/%d -o %s -j MASQUERADE",
> src/nat.c- nat->address,
> src/nat.c- nat->prefixlen,
> src/nat.c- nat->interface);
>
> rule #2
> src/session.c: err = __connman_firewall_add_rule(fw, "mangle", "INPUT",
> src/session.c- "-j CONNMARK --restore-mark");
> src/session.c: err = __connman_firewall_add_rule(fw, "mangle", "POSTROUTING",
> src/session.c- "-j CONNMARK --save-mark");
>
> rule #3
> src/session.c- case CONNMAN_SESSION_ID_TYPE_UID:
> src/session.c: err = __connman_firewall_add_rule(fw, "mangle",
> "OUTPUT",
> src/session.c- "-m owner --uid-owner %s -j MARK
> --set-mark %d",
> src/session.c-
> session->policy_config->id,
> src/session.c- session->mark);
> src/session.c- break;
> src/session.c- case CONNMAN_SESSION_ID_TYPE_GID:
> src/session.c: err = __connman_firewall_add_rule(fw, "mangle",
> "OUTPUT",
> src/session.c- "-m owner --gid-owner %s -j MARK
> --set-mark %d",
> src/session.c-
> session->policy_config->id,
> src/session.c- session->mark);
> src/session.c- break;
>
> rule #4
> src/session.c: id = __connman_firewall_add_rule(session->fw, "nat",
> "POSTROUTING",
> src/session.c- "-o %s -j SNAT --to-source %s",
> src/session.c- ifname, addr);
>
>
> In order to have iptables and nftables available (the implementation will be
> selected
> at compile time) we need to do either
>
> a) translate the iptables rules to nftables rules
> b) come up with a generic rule API
> c) introduce a bunch of specific rule functions which implemented
> by iptables and nftables subsystem.
>
> I think a) is pretty dirty and we should not do it. b) is way to
> complex for what we do. c) would be a good compromise and it helps
> the transitions phase. When we finally rip out iptables
> this wrapper API could get removed as well.
>
> So what about something like this:
>
> rule #1
> __connman_firewall_enable_masquerade(struct firewall_context *ctx);
> __connman_firewall_disable_masquerade(struct firewall_context *ctx);
Yes, looks simple enough.
> rule #2
> __connman_firewall_enable_connection_tracking(struct firewall_context *ctx);
> __connman_firewall_disable_connection_tracking(struct firewall_context *ctx);
Where is this needed? Isn't it something automatically used when
enabling marking with rule #3 below?
> rule #3
> __connman_firewall_enable_marking(struct firewall_context *ctx,
> enum connman_session_id_type,
> chard *id, uint32_t mark);
> __connman_firewall_disable_marking(struct firewall_context *ctx);
Should we say here which marking to remove or is the ctx per one marking
only? If it's one marking per ctx then subsequent (accidental) calls to
__connman_firewall_enable_marking() need to return -EALREADY or similar.
> rule #4
> __connman_firewall_enable_snat(struct firewall_context *ctx,
> char *ifname, char *addr);
> __connman_firewall_disable_snat(struct firewall_context *ctx);
Should this be called "add interface" with the code figuring out the
address (or am I getting confused which address this is)? What happens
if one combines this function with and only with rule #1 above?
> Obviously, the naming sucks.
Hmm, let's see. It could be worse, of course :-)
Thanks,
Patrik
------------------------------
Message: 5
Date: Fri, 26 Feb 2016 10:02:12 +0100
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
On 02/26/2016 09:51 AM, Patrik Flykt wrote:
> On Fri, 2016-02-26 at 09:19 +0100, Daniel Wagner wrote:
>> So what about something like this:
>> rule #2
>> __connman_firewall_enable_connection_tracking(struct firewall_context *ctx);
>> __connman_firewall_disable_connection_tracking(struct firewall_context *ctx);
>
> Where is this needed? Isn't it something automatically used when
> enabling marking with rule #3 below?
Yes, rules #2 is tied to rule #3.
>> rule #3
>> __connman_firewall_enable_marking(struct firewall_context *ctx,
>> enum connman_session_id_type,
>> chard *id, uint32_t mark);
>> __connman_firewall_disable_marking(struct firewall_context *ctx);
>
> Should we say here which marking to remove or is the ctx per one marking
> only? If it's one marking per ctx then subsequent (accidental) calls to
> __connman_firewall_enable_marking() need to return -EALREADY or similar.
There is only one mark per session and we use the enable()/disable()
in nice pairs. Obviously adding some sanity checks do not harm,
especially with iptables :)
>> rule #4
>> __connman_firewall_enable_snat(struct firewall_context *ctx,
>> char *ifname, char *addr);
>> __connman_firewall_disable_snat(struct firewall_context *ctx);
>
> Should this be called "add interface" with the code figuring out the
> address (or am I getting confused which address this is)?
True, we just could hand in the service:
ipconfig = __connman_service_get_ip4config(session->service);
index = __connman_ipconfig_get_index(ipconfig);
ifname = connman_inet_ifname(index);
addr = __connman_ipconfig_get_local(ipconfig);
id = __connman_firewall_add_rule(session->fw, "nat", "POSTROUTING",
"-o %s -j SNAT --to-source %s",
ifname, addr);
> What happens if one combines this function with and only with
> rule #1 above?
Good question. I haven't played with hotspot and session at the same
time. rule #1 is installed in the filter table which will be processed
before the nat table.
>> Obviously, the naming sucks.
>
> Hmm, let's see. It could be worse, of course :-)
Don't tease me :)
cheers,
daniel
------------------------------
Message: 6
Date: Fri, 26 Feb 2016 10:57:17 +0100
From: Marco Maniezzo <[email protected]>
To: [email protected]
Subject: Delete STORAGEDIR folders when services are removed
Message-ID:
<1456480639-8796-1-git-send-email-marco.manie...@magnetimarelli.com>
Hello,
currently when a service is removed (Remove d-bus method) some of its
properties are cleared but its folder and files in STORAGEDIR are not deleted.
This patch removes such data.
Immutable services have a .config file in STORAGEDIR, and if they have been
connected at least once they also have the same folder of mutable services: the
Remove method will delete the folder and force a re-provision of the service:
this will act as a reset of the service to its default.
Regards,
Marco Maniezzo
------------------------------
Message: 7
Date: Fri, 26 Feb 2016 10:57:18 +0100
From: Marco Maniezzo <[email protected]>
To: [email protected]
Subject: [PATCH 1/2] delete STORAGEDIR folders - documentation
Message-ID:
<1456480639-8796-2-git-send-email-marco.manie...@magnetimarelli.com>
---
doc/service-api.txt | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/doc/service-api.txt b/doc/service-api.txt
index e2e9e84..cb9021c 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -94,11 +94,14 @@ Methods dict GetProperties() [deprecated]
service is in the State=failure, this method can
also be used to reset the service.
- Calling this method on Ethernet devices, hidden WiFi
- services or provisioned services will cause an error
- message. It is not possible to remove these kind of
- services.
-
+ Calling this method on Ethernet devices and hidden WiFi
+ services will cause an error message. It is not
possible
+ to remove these kind of services.
+
+ For the other services the removal will cause the
+ deletion of their folder in STORAGEDIR. Immutable
+ services will be reprovisioned reading their .config
file.
+
Possible Errors: [service].Error.InvalidArguments
void MoveBefore(object service)
--
1.9.1
------------------------------
Message: 8
Date: Fri, 26 Feb 2016 10:57:19 +0100
From: Marco Maniezzo <[email protected]>
To: [email protected]
Subject: [PATCH 2/2] delete STORAGEDIR folders - sources
Message-ID:
<1456480639-8796-3-git-send-email-marco.manie...@magnetimarelli.com>
---
include/provision.h | 1 +
src/config.c | 9 +++++++++
src/service.c | 35 +++++++++++++++++++++++++++++++----
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/include/provision.h b/include/provision.h
index 3eb80a8..040f152 100644
--- a/include/provision.h
+++ b/include/provision.h
@@ -42,6 +42,7 @@ struct connman_config_entry {
bool hidden;
};
+void reload_config(const char * ident);
int connman_config_provision_mutable_service(GKeyFile *keyfile);
struct connman_config_entry **connman_config_get_entries(const char *type);
void connman_config_free_entries(struct connman_config_entry **entries);
diff --git a/src/config.c b/src/config.c
index 344b8ce..da95817 100644
--- a/src/config.c
+++ b/src/config.c
@@ -942,6 +942,15 @@ static void config_notify_handler(struct inotify_event
*event,
g_hash_table_remove(config_table, ident);
}
+void reload_config(const char * ident)
+{
+ struct inotify_event event;
+
+ event.mask = IN_MODIFY;
+
+ config_notify_handler(&event,ident);
+}
+
int __connman_config_init(void)
{
DBG("");
diff --git a/src/service.c b/src/service.c
index 8e07337..a0475f2 100644
--- a/src/service.c
+++ b/src/service.c
@@ -34,7 +34,7 @@
#include <connman/storage.h>
#include <connman/setting.h>
#include <connman/agent.h>
-
+#include <connman/provision.h>
#include "connman.h"
#define CONNECT_TIMEOUT 120
@@ -4081,11 +4081,15 @@ static DBusMessage *disconnect_service(DBusConnection
*conn,
bool __connman_service_remove(struct connman_service *service)
{
+ unsigned int *auto_connect_types;
+ char *ident;
+ int i;
+
if (service->type == CONNMAN_SERVICE_TYPE_ETHERNET ||
service->type == CONNMAN_SERVICE_TYPE_GADGET)
return false;
- if (service->immutable || service->hidden ||
+ if (service->hidden ||
__connman_provider_is_immutable(service->provider))
return false;
@@ -4116,9 +4120,32 @@ bool __connman_service_remove(struct connman_service
*service)
__connman_ipconfig_ipv6_reset_privacy(service->ipconfig_ipv6);
- service_save(service);
+ __connman_storage_remove_service(service->identifier);
- return true;
+ if (service->immutable == true && service->config_file)
+ {/* force reprovision of immutable services */
+
+ /* reset autoconnect to default, because it is not currently
(connman 1.31)
+ * managed by .config files
+ */
+ auto_connect_types =
connman_setting_get_uint_list("DefaultAutoConnectTechnologies");
+ service->autoconnect = false;
+ for (i = 0; auto_connect_types &&
+ auto_connect_types[i] != 0; i++) {
+ if (service->type == auto_connect_types[i]) {
+ service->autoconnect = true;
+ break;
+ }
+ }
+
+ DBG("reloading service %s", service->config_file);
+
+ ident = g_strdup_printf("%s.config", service->config_file);
+ reload_config(ident);
+ g_free(ident);
+ }
+
+ return(true);
}
static DBusMessage *remove_service(DBusConnection *conn,
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 34
**************************************
