br_netfilter post routing hook question...

br_netfilter post routing hook question...

[Gareth Williams]

Hello chaps.

I have a module which hooks into the bridge on the post routing hook
(PF_BRIDGE).

I also enable bridge netfilter to allow iptables rules to process
packets - I set rules on the post_routing chain (mangle table) to set
marks on packets.

Unfortunately I cannot see these marks in my code because the priority
on the bridge_netfilter post routing hook is PRI_LAST.

Since it is PRI_LAST I have no room to put my hook lower than it - so I
will never see these marks.

The comment in br_netfilter.c for this hook says it has to be PRI_LAST
because ip_refrag() can return STOLEN - but does it really have to be
LAST???  Can't it be say, last-1 so I have at least some room to move my
module to see those marks?

I know I could enable ebtables and do it that way but I am happy using
the conntrack facilities within the iptables framework to monitor
connections over the bridge.  The product I am working on also has
limited power and adding yet another set of tables and hooks would just
cause more slowdown in the fast path - something I don't think we can
stand right now.

Am I missing something obvious?

Cheers for any advice.

Gareth

Re: br_netfilter post routing hook question...

[agashi shipora]

Hi,

I don't know if br_nf_post_routing can be assigned a priority
NF_BR_PRI_LAST-1. I couldn't find ip_refrag definition in 2.6.30.

As br_netfilter.c invokes the NF_INET_POST_ROUTING hook.I was thinking
if registering your module at NF_INET_POST_ROUTING (PF_INET) after
ipt_post_routing_hook(mangle table), nf_nat_out(nat table) and before
ipv4_confirm (conntrack) would help.

Ofcourse this would mean your module would come into picture for
routed packets too.

Thanks
GP

On Fri, Apr 2, 2010 at 7:48 PM, Gareth Williams <gwilliams@ubicom.com> wrote:
> Hello chaps.
>
> I have a module which hooks into the bridge on the post routing hook
> (PF_BRIDGE).
>
> I also enable bridge netfilter to allow iptables rules to process
> packets - I set rules on the post_routing chain (mangle table) to set
> marks on packets.
>
> Unfortunately I cannot see these marks in my code because the priority
> on the bridge_netfilter post routing hook is PRI_LAST.
>
> Since it is PRI_LAST I have no room to put my hook lower than it - so I
> will never see these marks.
>
> The comment in br_netfilter.c for this hook says it has to be PRI_LAST
> because ip_refrag() can return STOLEN - but does it really have to be
> LAST???  Can't it be say, last-1 so I have at least some room to move my
> module to see those marks?
>
> I know I could enable ebtables and do it that way but I am happy using
> the conntrack facilities within the iptables framework to monitor
> connections over the bridge.  The product I am working on also has
> limited power and adding yet another set of tables and hooks would just
> cause more slowdown in the fast path - something I don't think we can
> stand right now.
>
> Am I missing something obvious?
>
> Cheers for any advice.
>
> Gareth
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: br_netfilter post routing hook question...

[Gareth Williams]

The product is a router and the bridge (br0) is connecting the lan to wlan.  The module only wants to examine packets on the bridge for qos purposes - to wlan and so I can, at the bridge layer, check for packets to/from ath0 (the wireless port).  At PF_INET I would only see br0 so my qos scope would be too wide.

TBH I wondered if I could have implemented a qdisc on ath0 and that might have been more efficient to track packets to/from wlan.  Though I don't know if qdisc can monitor rx packets - I know they can do tx as I have implemented them before.

The forward path would also expose me (at pf_inet) to wan<->bridge traffic too - I am conscious of the exposure to traffic volume and slowing the system down - I have a performance target to hit and am struggling to do so at the moment.

But I am also new to all this so am still in learning mode.

Oh and the comment in the c code says ip_refrag() but it actually calls ip_fragment() at the end of the post routing operation.  The bridge always returns STOLEN so maybe that is why it needs to be PRI_LAST???

Cheers for the advice. 

Gareth



-----Original Message-----
From: agashi shipora [mailto:gashipo@gmail.com] 
Sent: 02 April 2010 18:26
To: Gareth Williams
Cc: netfilter-devel@vger.kernel.org
Subject: Re: br_netfilter post routing hook question...

Hi,

I don't know if br_nf_post_routing can be assigned a priority
NF_BR_PRI_LAST-1. I couldn't find ip_refrag definition in 2.6.30.

As br_netfilter.c invokes the NF_INET_POST_ROUTING hook.I was thinking
if registering your module at NF_INET_POST_ROUTING (PF_INET) after
ipt_post_routing_hook(mangle table), nf_nat_out(nat table) and before
ipv4_confirm (conntrack) would help.

Ofcourse this would mean your module would come into picture for
routed packets too.

Thanks
GP

On Fri, Apr 2, 2010 at 7:48 PM, Gareth Williams <gwilliams@ubicom.com> wrote:
> Hello chaps.
>
> I have a module which hooks into the bridge on the post routing hook
> (PF_BRIDGE).
>
> I also enable bridge netfilter to allow iptables rules to process
> packets - I set rules on the post_routing chain (mangle table) to set
> marks on packets.
>
> Unfortunately I cannot see these marks in my code because the priority
> on the bridge_netfilter post routing hook is PRI_LAST.
>
> Since it is PRI_LAST I have no room to put my hook lower than it - so I
> will never see these marks.
>
> The comment in br_netfilter.c for this hook says it has to be PRI_LAST
> because ip_refrag() can return STOLEN - but does it really have to be
> LAST???  Can't it be say, last-1 so I have at least some room to move my
> module to see those marks?
>
> I know I could enable ebtables and do it that way but I am happy using
> the conntrack facilities within the iptables framework to monitor
> connections over the bridge.  The product I am working on also has
> limited power and adding yet another set of tables and hooks would just
> cause more slowdown in the fast path - something I don't think we can
> stand right now.
>
> Am I missing something obvious?
>
> Cheers for any advice.
>
> Gareth
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: br_netfilter post routing hook question...

[Bart De Schuymer]

Gareth Williams schreef:
> The product is a router and the bridge (br0) is connecting the lan to wlan.  The module only wants to examine packets on the bridge for qos purposes - to wlan and so I can, at the bridge layer, check for packets to/from ath0 (the wireless port).  At PF_INET I would only see br0 so my qos scope would be too wide.
>
>   
The iptables physdev match will probably save your day.


cheers,
Bart


-- 
Bart De Schuymer
www.artinalgorithms.be

RE: br_netfilter post routing hook question...

[Gareth Williams]

Ahh but I already tried physdev - and it throws warnings that it will
not work on forward or post routing paths when it's not on a bridge
interface.

But I was specifying the rule with "-o br0" which is a bridge so the
physdev rule should have been sane?

Even though it threw this warning it did add into iptables but still
didn't work for me.

I might revisit it and see if I can figure out what was wrong.

Gareth

-----Original Message-----
From: Bart De Schuymer [mailto:bdschuym@pandora.be] 
Sent: 02 April 2010 19:48
To: Gareth Williams
Cc: agashi shipora; netfilter-devel@vger.kernel.org
Subject: Re: br_netfilter post routing hook question...

Gareth Williams schreef:
> The product is a router and the bridge (br0) is connecting the lan to
wlan.  The module only wants to examine packets on the bridge for qos
purposes - to wlan and so I can, at the bridge layer, check for packets
to/from ath0 (the wireless port).  At PF_INET I would only see br0 so my
qos scope would be too wide.
>
>   
The iptables physdev match will probably save your day.


cheers,
Bart


-- 
Bart De Schuymer
www.artinalgorithms.be

Re: br_netfilter post routing hook question...

[Bart De Schuymer]

Gareth Williams schreef:
> Ahh but I already tried physdev - and it throws warnings that it will
> not work on forward or post routing paths when it's not on a bridge
> interface.
>
> But I was specifying the rule with "-o br0" which is a bridge so the
> physdev rule should have been sane?
>
> Even though it threw this warning it did add into iptables but still
> didn't work for me.
>
> I might revisit it and see if I can figure out what was wrong.
>
>   
I'd do that if I were you :-)
First figure out what's going on e.g. by adding rules, sending traffic
and looking at the rule counters. The iptables LOG target should produce
a string containing the physindev and physoutdev device name (the bridge
input and output port for the packet).

cheers,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

RE: br_netfilter post routing hook question...

[Gareth Williams]

You've convinced me to try again!!

Cheers

Gareth

-----Original Message-----
From: Bart De Schuymer [mailto:bdschuym@pandora.be] 
Sent: 02 April 2010 20:55
To: Gareth Williams
Cc: agashi shipora; netfilter-devel@vger.kernel.org
Subject: Re: br_netfilter post routing hook question...

Gareth Williams schreef:
> Ahh but I already tried physdev - and it throws warnings that it will
> not work on forward or post routing paths when it's not on a bridge
> interface.
>
> But I was specifying the rule with "-o br0" which is a bridge so the
> physdev rule should have been sane?
>
> Even though it threw this warning it did add into iptables but still
> didn't work for me.
>
> I might revisit it and see if I can figure out what was wrong.
>
>   
I'd do that if I were you :-)
First figure out what's going on e.g. by adding rules, sending traffic
and looking at the rule counters. The iptables LOG target should produce
a string containing the physindev and physoutdev device name (the bridge
input and output port for the packet).

cheers,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: br_netfilter post routing hook question...

[Bart De Schuymer]

agashi shipora wrote:
> Hi,
> 
> I don't know if br_nf_post_routing can be assigned a priority
> NF_BR_PRI_LAST-1. I couldn't find ip_refrag definition in 2.6.30.
> 

The comment about ip_refrag() is outdated. I sent a patch containing an
updated comment to Patrick earlier this week. The priority still has to
be NF_BR_PRI_LAST, because br_nf_post_routing() returns NF_STOLEN.
This is because the function ip_fragment(), which can be called by
br_nf_dev_queue_xmit(), will free the skb. If you won't use connection
tracking, I guess you could alter the code so you can still look at it
after br_nf_post_routing().

cheers,
Bart

-- 
Bart De Schuymer
www.artinalgorithms.be

Re: br_netfilter post routing hook question...

[Jan Engelhardt]

On Friday 2010-04-02 16:18, Gareth Williams wrote:
>
>Unfortunately I cannot see these marks in my code because the priority
>on the bridge_netfilter post routing hook is PRI_LAST.
>
>Since it is PRI_LAST I have no room to put my hook lower than it - so I
>will never see these marks.

Yeah I'll schedule proposing a patch.