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. would connman support pppoe ? (??)
2. RE: nftables (Zheng, Wu)
3. Re: nftables (Daniel Wagner)
4. Re: nftables (Patrik Flykt)
5. Re: would connman support pppoe ? (Patrik Flykt)
6. RE: nftables (Zheng, Wu)
7. Re: nftables (Patrik Flykt)
8. Re: [PATCH] Add AlwaysUseFallbackNameservers flag in the
configuration file. (Patrik Flykt)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 Feb 2016 13:57:32 +0800
From: ?? <[email protected]>
To: [email protected]
Subject: would connman support pppoe ?
Message-ID:
<CAKFk=cdxzic1x-+_zqze9lzevvd1b3m2gt_1vqxxegzi3zd...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Would connman plan to support pppoe? Or any existing implementations?
I looked up the upstream connman code, and there seems to no pppoe support.
I googled about this topic. See some discussions like below, while no answers.
https://01.org/jira/browse/CM-63
thanks.
------------------------------
Message: 2
Date: Mon, 29 Feb 2016 06:17:38 +0000
From: "Zheng, Wu" <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: nftables
Message-ID:
<2cf57a644018a745b8fe029c7223e16e12f69...@shsmsx104.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel Wagner,
>Indeed I was thinking to replace iptables and not have nftables and iptables
>to coexist.
Can we need to think about the compatibility for connman?
If some system don't use nftable, connman can't work well in the system.
At best, can we have nftables and iptables to coexist?
After checked iptable-1.6.0, I found that the feature of iptable over nftable
exists in iptable-1.6.0.
To my knowledge,
can we refer to the feature of iptable over nftable in iptables-1.6.0, we can
keep the all the existed iptable functions in Connman.
And we can implement iptable over nftable for the functions in Connman, Just
following the reference of iptable over nftable in iptables.
It should not be difficult in connman and iptable over nftable has been
implemented in iptables-1.6.0
Best Regards
Zheng Wu
-----Original Message-----
From: Daniel Wagner [mailto:[email protected]]
Sent: Friday, February 26, 2016 4:19 PM
To: Zheng, Wu <[email protected]>; Tomasz Bursztyka
([email protected]) <[email protected]>
Cc: [email protected]
Subject: Re: nftables
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: 3
Date: Mon, 29 Feb 2016 07:55:30 +0100
From: Daniel Wagner <[email protected]>
To: "Zheng, Wu" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi,
On 02/29/2016 07:17 AM, Zheng, Wu wrote:
>> Indeed I was thinking to replace iptables and not have nftables and iptables
>> to coexist.
> Can we need to think about the compatibility for connman?
Sure.
> If some system don't use nftable, connman can't work well in the system.
Unless we keep the current iptables implementation alive.
> At best, can we have nftables and iptables to coexist?
Someone told me that nftables and iptables can coexist in the kernel. I
haven't really verified it.
> After checked iptable-1.6.0, I found that the feature of iptable
> over nftable exists in iptable-1.6.0.
I think you are referring here to the userland part of iptables and
nftables. ConnMan does not use the command line tool iptables instead we
use libxtables directly. So we don't have this kind of compatibility
feature.
> To my knowledge,
> can we refer to the feature of iptable over nftable in
> iptables-1.6.0, we can keep the all the existed iptable functions in Connman.
> And we can implement iptable over nftable for the functions in Connman,
> Just following the reference of iptable over nftable in iptables.
>
> It should not be difficult in connman and iptable over nftable has
> been implemented in iptables-1.6.0
As I said we don't use the iptables command line tool to install the
rules. Also vice verse, I do not plan to use nft command line tool which
translates old iptable rules to nftable rules.
Anyway my plan was to have either iptables or nftables support enabled
at compile time. That means you need to decided which implementation you
need for you kernel. Both implementation will do the same thing (feature
parity).
Does that work for you?
cheers,
daniel
------------------------------
Message: 4
Date: Mon, 29 Feb 2016 09:02:04 +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"
On Mon, 2016-02-29 at 07:55 +0100, Daniel Wagner wrote:
> Anyway my plan was to have either iptables or nftables support enabled
> at compile time. That means you need to decided which implementation
> you need for you kernel. Both implementation will do the same thing
> (feature parity).
I think that is the most sane option of them all. Otherwise we'll be
dragging iptables libraries onto systems with native nftables support.
And that does not look very nice. Of course automake should figure out
what to build automatically in addition to the normal user overrides.
Cheers,
Patrik
------------------------------
Message: 5
Date: Mon, 29 Feb 2016 09:06:23 +0200
From: Patrik Flykt <[email protected]>
To: ?? <[email protected]>
Cc: [email protected]
Subject: Re: would connman support pppoe ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-02-29 at 13:57 +0800, ?? wrote:
> Would connman plan to support pppoe? Or any existing implementations?
>
> I looked up the upstream connman code, and there seems to no pppoe support.
>
> I googled about this topic. See some discussions like below, while no answers.
> https://01.org/jira/browse/CM-63
No pppoe support in ConnMan planned in upstream. I don't know any use
cases needing it nowadays.
Cheers,
Patrik
------------------------------
Message: 6
Date: Mon, 29 Feb 2016 07:10:10 +0000
From: "Zheng, Wu" <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: nftables
Message-ID:
<2cf57a644018a745b8fe029c7223e16e12f69...@shsmsx104.ccr.corp.intel.com>
Content-Type: text/plain; charset="us-ascii"
Hi Daniel Wagner,
>As I said we don't use the iptables command line tool to install the rules.
>Also vice verse, I do not plan to use nft command line tool which translates
>old iptable rules to nftable rules.
I mean that can we refer to the related source code of iptables and check how
the source code of iptables-1.6 implement the feature of iptable over nftable?
The source code of iptable just for reference.
Xtables is used in Iptable-1.6.0 for implementing the related features too.
If we can implement iptable over nftable in connman, the current iptables
functions names can be kept for implementing iptable and nftable.
>Anyway my plan was to have either iptables or nftables support enabled at
>compile time. That means you need to decided which implementation you need for
>you kernel. Both implementation will do the same thing (feature parity).
Yes, It works for me.
Best Regards
Zheng Wu
-----Original Message-----
From: Daniel Wagner [mailto:[email protected]]
Sent: Monday, February 29, 2016 2:56 PM
To: Zheng, Wu <[email protected]>
Cc: Tomasz Bursztyka ([email protected])
<[email protected]>; Patrik Flykt
<[email protected]>; [email protected]
Subject: Re: nftables
Hi,
On 02/29/2016 07:17 AM, Zheng, Wu wrote:
>> Indeed I was thinking to replace iptables and not have nftables and iptables
>> to coexist.
> Can we need to think about the compatibility for connman?
Sure.
> If some system don't use nftable, connman can't work well in the system.
Unless we keep the current iptables implementation alive.
> At best, can we have nftables and iptables to coexist?
Someone told me that nftables and iptables can coexist in the kernel. I haven't
really verified it.
> After checked iptable-1.6.0, I found that the feature of iptable over
> nftable exists in iptable-1.6.0.
I think you are referring here to the userland part of iptables and nftables.
ConnMan does not use the command line tool iptables instead we use libxtables
directly. So we don't have this kind of compatibility feature.
> To my knowledge,
> can we refer to the feature of iptable over nftable in iptables-1.6.0,
> we can keep the all the existed iptable functions in Connman.
> And we can implement iptable over nftable for the functions in
> Connman, Just following the reference of iptable over nftable in iptables.
>
> It should not be difficult in connman and iptable over nftable has
> been implemented in iptables-1.6.0
As I said we don't use the iptables command line tool to install the rules.
Also vice verse, I do not plan to use nft command line tool which translates
old iptable rules to nftable rules.
Anyway my plan was to have either iptables or nftables support enabled at
compile time. That means you need to decided which implementation you need for
you kernel. Both implementation will do the same thing (feature parity).
Does that work for you?
cheers,
daniel
------------------------------
Message: 7
Date: Mon, 29 Feb 2016 09:20:16 +0200
From: Patrik Flykt <[email protected]>
To: "Zheng, Wu" <[email protected]>
Cc: "[email protected]" <[email protected]>, Daniel Wagner
<[email protected]>
Subject: Re: nftables
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2016-02-29 at 07:10 +0000, Zheng, Wu wrote:
> I mean that can we refer to the related source code of iptables and
> check how the source code of iptables-1.6 implement the feature of
> iptable over nftable? The source code of iptable just for reference.
> Xtables is used in Iptable-1.6.0 for implementing the related features
> too.
We'd end up detecting whether to use nftables or iptables at run time in
any case. Plus linking against libxtables would drag in system libraries
that are not needed if only nftables is supported by the kernel.
Making the internal code work just by keeping iptables function calls to
achieve nftables output makes everything unnecessary complicated. We'd
better fix the abstraction level in the firewall_* or alike functions
instead, as proposed.
Cheers,
Patrik
------------------------------
Message: 8
Date: Mon, 29 Feb 2016 09:27:04 +0200
From: Patrik Flykt <[email protected]>
To: Grant Erickson <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Add AlwaysUseFallbackNameservers flag in the
configuration file.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Fri, 2016-02-26 at 07:52 -0800, Grant Erickson wrote:
> It?s easy to see how this is done one-off, statically for a provision
> or via a per-service-specific configuration setting using
> Nameservers.Configuration.
>
> However, what?s the recommended way to ensure that nameservers can be
> configured, via Nameservers.Configuration, and applied to all
> services, without regard to their technology type or the service name?
>
> The use case here is that a particular ISP supplies DNS servers in
> DHCP. However, their DNS servers are notoriously flaky and
> non-responsive (i.e. failed average response rate is high).
> Consequently, given how conman?s DNS proxy functions,
> statically-configured servers are a stopgap guarantee that will work
> even when the DHCP-provided servers do not.
So your use case actually continues that all services on the device end
up using the same ISP and it's flaky DNS servers, right?
Usually different WiFi, ethernet and cellular serivces end up using
different ISPs and therefore different DNS servers, leaving only a
subset of the services to be of the flaky kind. For these the option is
to configure them a priori through .config files or after empirical
evidence via D-Bus, as you pointed out.
Cheers,
Patrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 4, Issue 37
**************************************
