Herbert Xu wrote:
dean gaudet [EMAIL PROTECTED] wrote:
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr(127.0.0.1)},
On Tue, Jan 23, 2007 at 02:10:39PM +0300, Michael Tokarev wrote:
Well, but why getsockname() didn't just return ENOTCONN?
It's perfectly valid to have a local port number without being connected.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL
Herbert Xu wrote:
On Tue, Jan 23, 2007 at 02:10:39PM +0300, Michael Tokarev wrote:
Well, but why getsockname() didn't just return ENOTCONN?
It's perfectly valid to have a local port number without being connected.
Er. You're right - I was confusing getSOCKname() and getPEERname().
Still,
On Tue, Jan 23, 2007 at 02:15:45PM +0300, Michael Tokarev wrote:
Still, after the connection has been closed, there's no chance to do
anything with the filedescriptor but to close it as well, right? Or
can the fd be reused by making new connection with it, as if it were
just returned from
Herbert Xu wrote:
dean gaudet [EMAIL PROTECTED] wrote:
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr(127.0.0.1)},
On Tue, 23 Jan 2007, Rick Jones wrote:
Herbert Xu wrote:
Prior to the last write, the socket entered the CLOSED state meaning
that the old port is no longer allocated to it. As a result, the
last write operates on an unconnected socket which causes a new local
port to be allocated as an
On Tue, 23 Jan 2007 16:44:10 +1100
Herbert Xu [EMAIL PROTECTED] wrote:
dean gaudet [EMAIL PROTECTED] wrote:
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3,
From: dean gaudet [EMAIL PROTECTED]
Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST)
libnss-ldap has some code which attempts to determine if its private
socket has been trampled on in between calls to the library... and to do
this it caches getsockname/getpeername results and compares them every
On Tue, 23 Jan 2007, David Miller wrote:
From: dean gaudet [EMAIL PROTECTED]
Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST)
libnss-ldap has some code which attempts to determine if its private
socket has been trampled on in between calls to the library... and to do
this it caches
On Tue, Jan 23, 2007 at 12:26:52PM -0800, Stephen Hemminger wrote:
Why does write cause an autobind? One would think that on a
SOCK_STREAM socket, the write should just fail with ENOTCONN
The autobind is occuring in generic code, i.e., inet_sendmsg().
It will subsequently fail because the
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 24 Jan 2007 16:58:33 +1100
On Tue, Jan 23, 2007 at 12:26:52PM -0800, Stephen Hemminger wrote:
Why does write cause an autobind? One would think that on a
SOCK_STREAM socket, the write should just fail with ENOTCONN
The autobind is occuring
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr(127.0.0.1)}, [17863593746633850896]) = 0
...
write(3, hi!\n, 4)
dean gaudet [EMAIL PROTECTED] wrote:
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr(127.0.0.1)},
13 matches
Mail list logo
