From: Rusty Russell <rusty@rustcorp.com.au>
To: Phil Oester <kernel@linuxace.com>
Cc: Netfilter development mailing list <netfilter-devel@lists.netfilter.org>
Subject: Re: [PATCH] MASQUERADE handling of device events
Date: Wed, 24 Nov 2004 14:37:34 +1100 [thread overview]
Message-ID: <1101267454.6186.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20041123211623.GA20289@linuxace.com>
On Tue, 2004-11-23 at 13:16 -0800, Phil Oester wrote:
> On Sun, Nov 21, 2004 at 01:58:28PM +1100, Rusty Russell wrote:
> > The MASQUERADE target use to destroy connections when an interface
> > went down. We changed this to merely remove the ASSURED bit, and
> > destroy them if the same interface came up with a different IP
> > address. Unfortunately, as Phil Oester pointed out, that code was
> > crap for PPP connections, since we (1) compared ifa_address instead of
> > ifa_local, (2) identified interfaces by ifindex, which increments as a
> > PPP device downs and ups, and (3) caused all connections to be flushed
> > when we added an IP address.
> >
> > So that code was reverted after 2.6.10-rc2.
> >
> > This code stores the interface name, rather than trying to use the
> > ifindex, and only deletes connections if *no* ifa_local on the
> > interface matches the connection, so simply adding a new IP address is
> > a NOOP.
>
> But even using the interface name is unreliable. Consider the user who
> uses multiple PPP connections. Both go down at the same time, and
> come back with the 'old' ppp1 now named ppp0.
Sure, in which case the connections will be dropped, as they would be in
the naive case. This entire idea is best-effort, like NAT itself 8)
I think it's worth trying, at least, but obviously the core team can
override me.
> Perhaps my original patch which special-cased ppp would be better?
Drawing a link between point-to-point and addresses being static is
wrong, IMHO.
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
next prev parent reply other threads:[~2004-11-24 3:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-07 18:18 [PATCH] MASQUERADE handling of device events Phil Oester
2004-11-08 1:06 ` Henrik Nordstrom
2004-11-08 13:50 ` Harald Welte
2004-11-11 22:58 ` David S. Miller
2004-11-08 16:05 ` Patrick McHardy
2004-11-08 16:15 ` Phil Oester
2004-11-08 16:24 ` Patrick McHardy
2004-11-08 16:34 ` Phil Oester
2004-11-08 21:55 ` Phil Oester
2004-11-09 11:04 ` Patrick McHardy
2004-11-09 16:53 ` Phil Oester
2004-11-09 17:44 ` Patrick McHardy
2004-11-21 2:58 ` Rusty Russell
2004-11-23 21:16 ` Phil Oester
2004-11-24 3:37 ` Rusty Russell [this message]
2004-11-24 9:24 ` Henrik Nordstrom
2004-11-24 15:39 ` Herve Eychenne
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=1101267454.6186.13.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=kernel@linuxace.com \
--cc=netfilter-devel@lists.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.