10:38 a.m.
Hi,
On 02/22/2016 10:30 AM, Zheng, Wu wrote:
Hi Tomasz Bursztyka and Daniel Wagner,
We want to use nftable in our system.
Yes, it makes sense to abandon iptables.
Do you have an plan to implement nftable in Connman?
Well, as I said i was playing with the idea to do it as spare time project.
If so, do you have an plan when do upstream can implement the
feature?
I was asking Tomasz on how to use nftables. nftables doesn't enforce any
policies on the chain/table structure such as iptables. So that is first
thing we have to figure out.
Probably, we should also discuss it with the systemd-netwokd guys.
cheers,
daniel
10:37 a.m.
New subject: nftables
Hi Daniel Wagner,
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?
Best Regards
Zheng Wu
-----Original Message-----
From: Daniel Wagner [mailto:daniel.wagner@bmw-carit.de]
Sent: Monday, February 22, 2016 5:38 PM
To: Zheng, Wu <wu.zheng(a)intel.com>; Tomasz Bursztyka
<tomasz.bursztyka(a)linux.intel.com>
Cc: connman(a)connman.net
Subject: Re: nftables
Hi,
On 02/22/2016 10:30 AM, Zheng, Wu wrote:
Hi Tomasz Bursztyka and Daniel Wagner,
We want to use nftable in our system.
Yes, it makes sense to abandon iptables.
Do you have an plan to implement nftable in Connman?
Well, as I said i was playing with the idea to do it as spare time project.
If so, do you have an plan when do upstream can implement the
feature?
I was asking Tomasz on how to use nftables. nftables doesn't enforce any policies on
the chain/table structure such as iptables. So that is first thing we have to figure out.
Probably, we should also discuss it with the systemd-netwokd guys.
cheers,
daniel
9:19 a.m.
New subject: 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
9:51 a.m.
New subject: nftables
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
10:02 a.m.
New subject: nftables
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
7:17 a.m.
New subject: nftables
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:daniel.wagner@bmw-carit.de]
Sent: Friday, February 26, 2016 4:19 PM
To: Zheng, Wu <wu.zheng(a)intel.com>; Tomasz Bursztyka
(tomasz.bursztyka(a)linux.intel.com) <tomasz.bursztyka(a)linux.intel.com>
Cc: connman(a)connman.net
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
7:55 a.m.
New subject: 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
8:02 a.m.
New subject: nftables
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
8:10 a.m.
New subject: nftables
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:daniel.wagner@bmw-carit.de]
Sent: Monday, February 29, 2016 2:56 PM
To: Zheng, Wu <wu.zheng(a)intel.com>
Cc: Tomasz Bursztyka (tomasz.bursztyka(a)linux.intel.com)
<tomasz.bursztyka(a)linux.intel.com>; Patrik Flykt
<Patrik.Flykt(a)linux.intel.com>; connman(a)connman.net
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
8:20 a.m.
New subject: nftables
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
1790
days inactive
1797
days old
9 comments
3 participants
participants (3)
-
Daniel Wagner -
Patrik Flykt -
Zheng, Wu