From: Bill Davidsen <[EMAIL PROTECTED]>
Date: Sun, 16 Dec 2007 17:47:24 -0500
> David Miller wrote:
> > From: Herbert Xu <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 11:12:32 +1100
> >
> >> [INET]: Export non-blocking flags to proto connect call
> >>
> >> Previously we made connect(2) block on
David Miller wrote:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution. This is
good in general but not desirable for non-blocking sockets.
To fix this
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution. This is
good in general but not desirable for non-blocking sockets.
To fix this
From: Bill Davidsen [EMAIL PROTECTED]
Date: Sun, 16 Dec 2007 17:47:24 -0500
David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution.
Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
> If IPSEC takes a long time to resolve, and we don't block, the
> connect() can hard fail (we will just keep dropping the outgoing SYN
> packet send attempts, eventually hitting the retry limit) in cases
> where if we did block it would
Am Freitag, 7. Dezember 2007 04:20 schrieb David Miller:
If IPSEC takes a long time to resolve, and we don't block, the
connect() can hard fail (we will just keep dropping the outgoing SYN
packet send attempts, eventually hitting the retry limit) in cases
where if we did block it would not
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 15:31:53 +0100
> as far as I've understood Herbert's patch, at least TCP connect can be fixed
> so that non blocking connect() will neither fail nor block, but just use the
> first or second retransmission of the SYN packet to
Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:
> You keep ignoring the fact that, as Herbert and I discussed, not
> blocking for IPSEC resolution will make some connect() cases fail that
> would otherwise not fail.
>
> There are two sides to this issue, and we need to consider them
>
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 13:30:20 +0100
> IMHO this is what developers expect, and is also consistent with the
> fact that POSIX does not define O_NONBLOCK behaviour for local
> files.
You keep ignoring the fact that, as Herbert and I discussed, not
blocking
Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
> > Because you just will put enough RAM modules into you server when
> > setting up a scalable system.
>
> This suggestion is avoiding the important semantic issue, and
> won't lead to a real discussion of the core problem.
When
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 12:35:05 +0100
> Because you just will put enough RAM modules into you server when
> setting up a scalable system.
This suggestion is avoiding the important semantic issue, and
won't lead to a real discussion of the core problem.
--
Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller:
> And that's why this is a grey area. Why is waiting for memory
> allocation on a O_NONBLOCK socket OK but waiting for IPSEC route
> resolution is not?
Because you just will put enough RAM modules into you server when setting up a
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 11:56:48 +0100
> Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
>
> > > I think the words "shall fail" and "immediately" are quite clear.
> >
> > They are, but the context in which they apply is vague.
>
> "socket is
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
> > I think the words "shall fail" and "immediately" are quite clear.
>
> They are, but the context in which they apply is vague.
"socket is connection-mode" => SOCK_STREAM
> I can equally generate examples where the non-blocking
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Thu, 6 Dec 2007 09:49:01 +0100
> "If the connection cannot be established immediately and O_NONBLOCK is set
> for
> the file descriptor for the socket, connect() shall fail and set errno to
> [EINPROGRESS], but the connection request shall not be
Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:
> POSIX says nothing about the semantics of route resolution.
Of course not. Applications must not care about what happens at the transport
layer.
> Non-blocking doesn't mean "cannot sleep no matter what".
... and as O_CREAT on
Am Donnerstag, 6. Dezember 2007 03:25 schrieb David Miller:
POSIX says nothing about the semantics of route resolution.
Of course not. Applications must not care about what happens at the transport
layer.
Non-blocking doesn't mean cannot sleep no matter what.
... and as O_CREAT on open()
From: Stefan Rompf [EMAIL PROTECTED]
Date: Thu, 6 Dec 2007 09:49:01 +0100
If the connection cannot be established immediately and O_NONBLOCK is set
for
the file descriptor for the socket, connect() shall fail and set errno to
[EINPROGRESS], but the connection request shall not be aborted,
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
I think the words shall fail and immediately are quite clear.
They are, but the context in which they apply is vague.
socket is connection-mode = SOCK_STREAM
I can equally generate examples where the non-blocking behavior you
are
From: Stefan Rompf [EMAIL PROTECTED]
Date: Thu, 6 Dec 2007 11:56:48 +0100
Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller:
I think the words shall fail and immediately are quite clear.
They are, but the context in which they apply is vague.
socket is connection-mode =
Am Donnerstag, 6. Dezember 2007 12:13 schrieb David Miller:
And that's why this is a grey area. Why is waiting for memory
allocation on a O_NONBLOCK socket OK but waiting for IPSEC route
resolution is not?
Because you just will put enough RAM modules into you server when setting up a
From: Stefan Rompf [EMAIL PROTECTED]
Date: Thu, 6 Dec 2007 12:35:05 +0100
Because you just will put enough RAM modules into you server when
setting up a scalable system.
This suggestion is avoiding the important semantic issue, and
won't lead to a real discussion of the core problem.
--
To
Am Donnerstag, 6. Dezember 2007 12:39 schrieb David Miller:
Because you just will put enough RAM modules into you server when
setting up a scalable system.
This suggestion is avoiding the important semantic issue, and
won't lead to a real discussion of the core problem.
When writing
From: Stefan Rompf [EMAIL PROTECTED]
Date: Thu, 6 Dec 2007 13:30:20 +0100
IMHO this is what developers expect, and is also consistent with the
fact that POSIX does not define O_NONBLOCK behaviour for local
files.
You keep ignoring the fact that, as Herbert and I discussed, not
blocking for
Am Donnerstag, 6. Dezember 2007 14:55 schrieb David Miller:
You keep ignoring the fact that, as Herbert and I discussed, not
blocking for IPSEC resolution will make some connect() cases fail that
would otherwise not fail.
There are two sides to this issue, and we need to consider them
both.
From: Stefan Rompf [EMAIL PROTECTED]
Date: Thu, 6 Dec 2007 15:31:53 +0100
as far as I've understood Herbert's patch, at least TCP connect can be fixed
so that non blocking connect() will neither fail nor block, but just use the
first or second retransmission of the SYN packet to complete the
From: Stefan Rompf <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 19:39:07 +0100
> I'd strongly suggest doing so. AFAIK, behaviour of connect() on nonblocking
> sockets is quite well defined in POSIX.
You are entitled to your opinion.
POSIX says nothing about the semantics of route resolution.
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
> > If he sets this sysctl to "1" as I detailed in my reply, he'll
> > get the behavior he wants.
>
> Does anybody actually need the 0 setting? What would we break if
> the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
> 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
On Wed, Dec 05, 2007 at 01:55:58AM -0800, David Miller wrote:
>
> If it hits sysctl_tcp_syn_retries SYN attempts, the connect will hard
> fail.
Right. Let's just forget about this until we have a queueing system :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:39:27 +1100
> On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
> >
> > TCP has some built-in assumptions about characteristics of
> > interent links and what constitutes a timeout which is "too long"
> > and should thus
Am Mittwoch, 5. Dezember 2007 07:51 schrieb Herbert Xu:
If he sets this sysctl to 1 as I detailed in my reply, he'll
get the behavior he wants.
Does anybody actually need the 0 setting? What would we break if
the default became 1?
I'd strongly suggest doing so. AFAIK, behaviour of
Am Mittwoch, 5. Dezember 2007 08:12 schrieb David Miller:
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
On Wed, Dec 05, 2007 at 01:55:58AM -0800, David Miller wrote:
If it hits sysctl_tcp_syn_retries SYN attempts, the connect will hard
fail.
Right. Let's just forget about this until we have a queueing system :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~}
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 18:39:27 +1100
On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
TCP has some built-in assumptions about characteristics of
interent links and what constitutes a timeout which is too long
and should thus result in a
From: Stefan Rompf [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 19:39:07 +0100
I'd strongly suggest doing so. AFAIK, behaviour of connect() on nonblocking
sockets is quite well defined in POSIX.
You are entitled to your opinion.
POSIX says nothing about the semantics of route resolution.
On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
>
> TCP has some built-in assumptions about characteristics of
> interent links and what constitutes a timeout which is "too long"
> and should thus result in a full connection failure.
>
> IPSEC changes this because of IPSEC route
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 18:16:07 +1100
> Right. This is definitely bad for protocols without a retransmission
> mechanism.
>
> However, is the 0 setting ever useful for TCP and in particular, TCP's
> connect(2) call? Perhaps we can just make that one always
On Tue, Dec 04, 2007 at 11:12:00PM -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> 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
From: Herbert Xu <[EMAIL PROTECTED]>
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
On Tue, Dec 04, 2007 at 10:30:23PM -0800, David Miller wrote:
>
> We made an explicit decision not to do things this way.
Thanks for pointing this out.
> Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
> setting, and this is across the board. If xfrm_larval_drop is zero,
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 11:12:32 +1100
> [INET]: Export non-blocking flags to proto connect call
>
> Previously we made connect(2) block on IPsec SA resolution. This is
> good in general but not desirable for non-blocking sockets.
>
> To fix this properly
From: Simon Arlott <[EMAIL PROTECTED]>
Date: Tue, 04 Dec 2007 18:53:19 +
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will
On Tue, Dec 04, 2007 at 06:53:19PM +, Simon Arlott wrote:
> If I have a IPsec rule like:
> spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
> (i.e. a remote host 1.2.3.4 which will not respond)
>
> Then any attempt to communicate with 1.2.3.4 will block, even when
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
non-blocking sockets:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) =
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
non-blocking sockets:
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) =
On Tue, Dec 04, 2007 at 06:53:19PM +, Simon Arlott wrote:
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even when using
From: Simon Arlott [EMAIL PROTECTED]
Date: Tue, 04 Dec 2007 18:53:19 +
If I have a IPsec rule like:
spdadd 192.168.7.8 1.2.3.4 any -P out ipsec esp/transport//require;
(i.e. a remote host 1.2.3.4 which will not respond)
Then any attempt to communicate with 1.2.3.4 will block, even
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 11:12:32 +1100
[INET]: Export non-blocking flags to proto connect call
Previously we made connect(2) block on IPsec SA resolution. This is
good in general but not desirable for non-blocking sockets.
To fix this properly we'd need
On Tue, Dec 04, 2007 at 10:30:23PM -0800, David Miller wrote:
We made an explicit decision not to do things this way.
Thanks for pointing this out.
Non-blocking has a meaning dependant upon the xfrm_larval_drop sysctl
setting, and this is across the board. If xfrm_larval_drop is zero,
From: Herbert Xu [EMAIL PROTECTED]
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
On Tue, Dec 04, 2007 at 11:12:00PM -0800, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
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
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 18:16:07 +1100
Right. This is definitely bad for protocols without a retransmission
mechanism.
However, is the 0 setting ever useful for TCP and in particular, TCP's
connect(2) call? Perhaps we can just make that one always drop.
On Tue, Dec 04, 2007 at 11:34:32PM -0800, David Miller wrote:
TCP has some built-in assumptions about characteristics of
interent links and what constitutes a timeout which is too long
and should thus result in a full connection failure.
IPSEC changes this because of IPSEC route resolution
54 matches
Mail list logo
