From: Andi Kleen <ak@muc.de>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: John Fremlin <vii@altern.org>,
linux-kernel@vger.kernel.org, netdev@oss.sgi.com,
paulus@linuxcare.com, linux-ppp@vger.kernel.org,
linux-net@vger.kernel.org
Subject: Re: [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR)
Date: Mon, 29 Jan 2001 13:59:05 +0100 [thread overview]
Message-ID: <20010129135905.B1591@fred.local> (raw)
In-Reply-To: <m2d7d838sj.fsf@boreas.yi.org.> <200101290245.f0T2j2Y438757@saturn.cs.uml.edu>
In-Reply-To: <200101290245.f0T2j2Y438757@saturn.cs.uml.edu>; from acahalan@cs.uml.edu on Mon, Jan 29, 2001 at 03:46:42AM +0100
On Mon, Jan 29, 2001 at 03:46:42AM +0100, Albert D. Cahalan wrote:
> John Fremlin writes:
>
> > When the IP address of an interface changes, TCP connections with the
> > old source address are useless. Applications are not notified of this
> > and time out ordinarily, just as if nothing had happened. This is
> > behaviour isn't very helpful when you have a dynamic IP and know
> > you're probably not going to get the old one back. In that case, you
> ...
> > I patched userspace ppp-2.4.0 to use this functionality. It would be
> > better if SIOCKILLADDR were not used until we are sure that the new IP
> > is in fact different from the old one, but pppd in demand mode would
>
> I get the same IP about 2/3 of the time, so it is pretty important
> to avoid killing connections until after the new IP is known.
I prefer it when the IP is killed as soon as possible so that I can see
when the connection is lost (ssh sessions get killed etc.)
Another reason for killing as soon as possible is the last-ack problem.
When the other end goes away suddenly TCP often gets into last-ack state.
This means it'll retransmit a FIN until it times out or the other end
answers. Each such retransmitted FIN triggers a new dialin, which can
get quite costly when you don't have flat rate (like still most of Europe).
With your approach (waiting until the new IP is known) it would cost
at least another dialin in this case.
When you have flatrate your way may be better of course, so a final
user space solution could switch it via a pppd flag.
[I agree that the user space way is better than my kernel hacks]
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-01-29 13:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-27 22:54 [PATCH] dynamic IP support for 2.4.0 (SIOCKILLADDR) John Fremlin
2001-01-29 2:45 ` Albert D. Cahalan
2001-01-29 12:59 ` Andi Kleen [this message]
2001-01-29 18:31 ` Jamie Lokier
2001-01-29 21:08 ` Andi Kleen
2001-01-30 0:47 ` John Fremlin
2001-02-01 5:56 ` Ralf Baechle
2001-02-04 22:21 ` Mark Cooke
2001-01-30 0:43 ` John Fremlin
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=20010129135905.B1591@fred.local \
--to=ak@muc.de \
--cc=acahalan@cs.uml.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=linux-ppp@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=paulus@linuxcare.com \
--cc=vii@altern.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox