From: David Miller <davem@davemloft.net>
To: herbert@gondor.apana.org.au
Cc: simon@fire.lp0.eu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: sockets affected by IPsec always block (2.6.23)
Date: Tue, 04 Dec 2007 23:12:00 -0800 (PST) [thread overview]
Message-ID: <20071204.231200.117152338.davem@davemloft.net> (raw)
In-Reply-To: <20071205065132.GA11476@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 5 Dec 2007 17:51:32 +1100
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I bet there are UDP apps out there that would break if we
didn't do this.
Actually, consider even a case like DNS. Let's say the timeout
is set to 2 seconds or something and you have 3 DNS servers
listed, on different IPSEC destinations, in your resolv.conf
Each IPSEC route that isn't currently resolved will cause packet loss
of the DNS lookup request with xfrm_larval_drop set to '1'.
If all 3 need to be resolved, the DNS lookup will fully fail
which defeats the purpose of listing 3 servers for redundancy
don't you think? :-)
As much as I even personally prefer the xfrm_larval_drop=1
behavior, it cases like above that keep me from jumping at
making it the default.
Arguably, potentially blocking forever (which is what can easily
happen with xfrm_larval_drop=0 if your IPSEC daemon cannot resolve the
IPSEC path for whatever reason) is worse than the above, but the
other cases are still something to consider as well.
next prev parent reply other threads:[~2007-12-05 7:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-04 18:53 sockets affected by IPsec always block (2.6.23) Simon Arlott
2007-12-05 0:12 ` Herbert Xu
2007-12-05 6:30 ` David Miller
2007-12-05 6:51 ` Herbert Xu
2007-12-05 7:12 ` David Miller [this message]
2007-12-05 7:16 ` Herbert Xu
2007-12-05 7:34 ` David Miller
2007-12-05 7:39 ` Herbert Xu
2007-12-05 9:55 ` David Miller
2007-12-05 9:57 ` Herbert Xu
2007-12-05 18:42 ` Stefan Rompf
2007-12-05 18:39 ` Stefan Rompf
2007-12-06 2:25 ` David Miller
2007-12-06 8:49 ` Stefan Rompf
2007-12-06 8:53 ` David Miller
2007-12-06 10:56 ` Stefan Rompf
2007-12-06 11:13 ` David Miller
2007-12-06 11:35 ` Stefan Rompf
2007-12-06 11:39 ` David Miller
2007-12-06 12:30 ` Stefan Rompf
2007-12-06 13:55 ` David Miller
2007-12-06 14:31 ` Stefan Rompf
2007-12-07 3:20 ` David Miller
2007-12-07 9:29 ` Stefan Rompf
2007-12-16 22:47 ` Bill Davidsen
2007-12-16 23:22 ` David Miller
2007-12-05 6:06 ` David Miller
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=20071204.231200.117152338.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=simon@fire.lp0.eu \
/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;
as well as URLs for NNTP newsgroup(s).