From: Phil Oester <kernel@linuxace.com>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] MASQUERADE handling of device events
Date: Tue, 9 Nov 2004 08:53:13 -0800 [thread overview]
Message-ID: <20041109165313.GA13205@linuxace.com> (raw)
In-Reply-To: <4190A44F.7010509@trash.net>
On Tue, Nov 09, 2004 at 12:04:47PM +0100, Patrick McHardy wrote:
> You're right. I have to admit, I'm not too happy about the unpredictable
> behaviour we get with this patch and multiple ppp devices. So one last
> attempt to convince people. The old behaviour was to kill conntracks once
> the device goes down. I think killing conntracks when the IP is deleted
> makes more sense. Since the IP has to be deleted manually, except when
> the device goes away, people can simply not delete IP addresses for
> devices that don't go away, than nothing will get removed. pppd can be
> taught to keep the device alive. The attached patch adds a program
> alloc-ppp to pre-allocate ppp-devices and teaches pppd to attach to them.
> The device never goes away, if ppp doesn't delete the IP address the
> conntracks won't be killed. It could easily be integrated in a more handy
> way in pppd. So this could also be done entirely in userspace, without
> the unpredictable behaviour.
Is this the unpredictable behaviour you refer to:
ppp0 down -> clear assured bit on ppp0 conntracks
ppp1 down -> clear assured bit on ppp1 conntracks
ppp0 up with same ip -> all ppp1 conntracks get cleared since that ip
no longer exists on box
ppp1 up with same ip -> loser
Not much we can do about that except revert to the old behaviour of
dropping all conntracks on interface down, but that does seem silly
for 'mostly static' pppoe users.
Obviously I'd vote for the 'friendlier' method, but bottom line is current
behaviour is broken and should be fixed somehow...
Phil
next prev parent reply other threads:[~2004-11-09 16:53 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 [this message]
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
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=20041109165313.GA13205@linuxace.com \
--to=kernel@linuxace.com \
--cc=kaber@trash.net \
--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.