All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: xt_addrtype limit-iface-in is broken for ipv6
Date: Tue, 7 May 2013 11:48:06 +0200	[thread overview]
Message-ID: <20130507094806.GA20003@breakpoint.cc> (raw)
In-Reply-To: <20130507004606.GA5088@localhost>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > Because xt_addrtype uses ip6_route_output, the ipv6 routing
> > implementation creates an unwanted cached entry, and the packet
> > won't make it to the real/expected destination.
> > 
> > Silently ignoring --limit-iface-in makes the routing work
> > but it breaks rule matching (--dst-type LOCAL with limit-iface-in
> > is supposed to only match if the dst address is configured on
> > the incoming interface; without --limit-iface-in it will match if
> > the address is reachable via lo).
> > 
> > AFAIU the only solution is to use ipv6_chk_addr() when
> > LOCAL is requested instead of a route lookup.
> > 
> > Since this would create a dependeny on ipv6 its a no-go.
> > So, it boils down to two possible solutions:
> > 
> > a), extend struct nf_afinfo to also register
> >     ipv6_chk_addr(), OR
> > b), revert the commit that moved ipt_addrtype to xt_addrtype,
> >     and keep the ipv6 code in ip6t_addrtype.
> 
> I'd prefer something smaller  so I can pass a fix to -stable. We
> cannot pass patches bigger than 100 lines including context.

This will be tough.  Extending struct nf_afinfo for
ipv6_chk_addr MIGHT come in just under 100 lines.  I'll have go at this.

[ i don't like this solution because we add a something for the sake
  of a single ipv6 special case ].

      reply	other threads:[~2013-05-07  9:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-05  9:36 xt_addrtype limit-iface-in is broken for ipv6 Florian Westphal
2013-05-07  0:46 ` Pablo Neira Ayuso
2013-05-07  9:48   ` Florian Westphal [this message]

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=20130507094806.GA20003@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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.