From: Patrick McHardy <kaber@trash.net>
To: Phil Oester <kernel@linuxace.com>
Cc: Harald Welte <laforge@netfilter.org>,
netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] MASQUERADE handling of device events
Date: Tue, 09 Nov 2004 18:44:39 +0100 [thread overview]
Message-ID: <41910207.1090309@trash.net> (raw)
In-Reply-To: <20041109165313.GA13205@linuxace.com>
Phil Oester wrote:
>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
>
>
Yes. It gives unpredictable behaviour and no way to avoid it.
If ppp1 comes up first - ppp0 is the loser. If only one goes
down at a time - nobody looses.
>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...
>
>
I think deterministic behaviour is more friendly than something
working only under certain conditions and doing strange stuff
the remaining time. I would like to hear Harald's opinion.
Regards
Patrick
next prev parent reply other threads:[~2004-11-09 17:44 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 [this message]
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=41910207.1090309@trash.net \
--to=kaber@trash.net \
--cc=kernel@linuxace.com \
--cc=laforge@netfilter.org \
--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.