All of lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Quartulli <antonio@meshcoding.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Antonio Quartulli <antonio@open-mesh.com>,
	"David S. Miller" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH net] bridge: clean the nf_bridge status when forwarding the skb
Date: Fri, 18 Oct 2013 13:35:55 +0200	[thread overview]
Message-ID: <20131018113555.GK2596@neomailbox.net> (raw)
In-Reply-To: <20131018111041.GA10964@localhost>

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Fri, Oct 18, 2013 at 01:10:41PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Oct 17, 2013 at 01:37:35PM +0200, Antonio Quartulli wrote:
> > On Thu, Oct 17, 2013 at 04:28:57AM -0700, Pablo Neira Ayuso wrote:
> > > Hi,
> > > > +
> > > > +/**
> > > > + * br_netfilter_skb_free - clean the NF bridge data in an skb
> > > > + * @skb: the skb which the data to free belongs to
> > > > + */
> > > > +void br_netfilter_skb_free(struct sk_buff *skb)
> > > > +{
> > > > +	nf_bridge_put(skb->nf_bridge);
> > > > +	skb->nf_bridge = NULL;
> > > > +}
> > > 
> > > This should be nf_reset.
> > 
> > You think I should directly use nf_reset instead of this function?
> > 
> > I see that nf_reset() cleans up the conntrack part too: does it also become
> > useless once the packet exits the bridge interface?
> 
> The conntrack should not attached if it's forwarded to another netif,
> see dev_forward_skb.
> 
> But I'm not sure what scenario you're trying to handle with this
> change, if you could please elaborate.


This is a sample scenario (nf bridge is on):

[eth0] ---> [br0] ---> [bat0] ---> [br1]

where the relation '[a] ---> [b]' means 'a is enslaved in b' (bat0 is a
batman-adv virtual interface..in this situation it should not matter: it
just removs an header from an incoming skb and delivers it).

The problem I was having was due to an skb entering br0 first and br1 later.
When reaching br1 skb->nf_bridge was != NULL because of the previous processing
in br0.

To clarify, the packet arriving on eth0 is 'delivered' to br0. It is not
forwarded to another port of the bridge. Therefore I am not sure that we should
clean the conntrack part too.

> 
> Perhaps your fix is more conservative to avoid breaking strange setups
> that have been relying on this behaviour. I know of people deploying
> strange configurations using netfilter bridge.
> 

could be.

Cheers,

-- 
Antonio Quartulli

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-10-18 11:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-14 22:51 [PATCH net] bridge: clean the nf_bridge status when forwarding the skb Antonio Quartulli
2013-10-17 11:28 ` Pablo Neira Ayuso
2013-10-17 11:37   ` Antonio Quartulli
2013-10-18 11:10     ` Pablo Neira Ayuso
2013-10-18 11:35       ` Antonio Quartulli [this message]
2013-10-18 14:32         ` Vlad Yasevich
2013-10-18 14:46           ` Antonio Quartulli
2013-10-18 15:33             ` Vlad Yasevich
2013-10-18 15:41               ` Antonio Quartulli
2013-10-21 15:00                 ` Vlad Yasevich
2013-10-21 15:06                   ` Antonio Quartulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131018113555.GK2596@neomailbox.net \
    --to=antonio@meshcoding.com \
    --cc=antonio@open-mesh.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.