(2) returns error 54 (connection reset by
peer) wrongly
Date: Sun, 30 May 2010 11:05:45 +0300
--=-=-=
On Fri, 28 May 2010 04:40:03 GMT Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> IMHO, it is not, unfortunately, a solution: it seems to clear ECONNRESET
> blindly and w/o distinguishing the
all data written from the
> local end) -- and that qualifies for the true "connection reset by peer"
> from close()...
I did some experiments the results I would like to share here. The idea is
following: the client sends data in one write() more then a win, while the
ser
uation when the remote end closes
the
LA> connection prematurely (i.e. before acknowledging all data written from
the
LA> local end) -- and that qualifies for the true "connection reset by peer"
LA> from close()...
I am not very familiar with the socket/tcp code bu
owledging all data written from
the
LA> local end) -- and that qualifies for the true "connection reset by peer"
LA> from close()...
I am not very familiar with the socket/tcp code but it looks for me that it
might not make any difference.
I can be wrong here but the situat
The following reply was made to PR kern/146845; it has been noted by GNATS.
From: "Lavrentiev, Anton (NIH/NLM/NCBI) [C]"
To: "bug-follo...@freebsd.org"
Cc:
Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset
by peer) wrongly
Date: Fri, 28 May 2010
The following reply was made to PR kern/146845; it has been noted by GNATS.
From: "Robert N. M. Watson"
To: Mikolaj Golub
Cc: bug-follo...@freebsd.org,
Anton Lavrentiev ,
freebsd-net@FreeBSD.org
Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by
pee
On 27 May 2010, at 22:25, Mikolaj Golub wrote:
> We observed the same issue on our FreeBSD6 and 7 servers. I tried to reproduce
> the problem writing a simple test case but failed -- I didn't come to the idea
> of shutdown()/close() sequence (as Anton did). Although looking now at the
> code we h
The following reply was made to PR kern/146845; it has been noted by GNATS.
From: Mikolaj Golub
To: bug-follo...@freebsd.org
Cc: Anton Lavrentiev , Robert Watson
, freebsd-net@FreeBSD.org
Subject: Re: kern/146845: [libc] close(2) returns error 54 (connection reset by
peer) wrongly
Date: Fri
Hi,
We observed the same issue on our FreeBSD6 and 7 servers. I tried to reproduce
the problem writing a simple test case but failed -- I didn't come to the idea
of shutdown()/close() sequence (as Anton did). Although looking now at the
code we had the issue with I see that shutdown()/close() sequ
Synopsis: [libc] close(2) returns error 54 (connection reset by peer) wrongly
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Sun May 23 14:03:41 UTC 2010
Responsible-Changed-Why:
Pass this over to maintainers. Thanks for the g
> Then my guess is that something is wrong with your redirection setup.
> Unfortunately, tcpdump sees the packets as they enter the network card,
> before the redirection occurs, so we can't see exactly what is really
> happening.
No actually that's the packets after they have been redirected.
On Thu, 8 Sep 2005, Olivier Nicole wrote:
Hi Mike,
First of all, the redirection you speak of - is that occuring on the local
machine itself, or a physically seperate machine?
Yes same machine.
Then my guess is that something is wrong with your redirection setup.
Unfortunately, tcpdump s
Hi Mike,
> First of all, the redirection you speak of - is that occuring on the local
> machine itself, or a physically seperate machine?
Yes same machine.
> Secondly, please
> provide a tcpdump log of the aborted connection in question, if you can.
Here I could add more details if needed.
On Thu, 8 Sep 2005, Olivier Nicole wrote:
When I try to connect via a redirection through the firewall, I got a
RST after the SYN, SYN/ACK, ACK.
OK here is a step further, the rest occures because of syncache_expand
that return 0 on line 722 of tcp_input.
Any reason why the syncache is empty
> When I try to connect via a redirection through the firewall, I got a
> RST after the SYN, SYN/ACK, ACK.
OK here is a step further, the rest occures because of syncache_expand
that return 0 on line 722 of tcp_input.
Any reason why the syncache is empty after the SYN and SYN,ACK?
Olivier
__
Hi,
I am trying to run NoCat (from the ports). One thing NoCat does is run
a TCP listener on port 5280.
When I try to connect to that port "by hand" (telnet xxx 5280)
everything goes fine.
When I try to connect via a redirection through the firewall, I got a
RST after the SYN, SYN/ACK, ACK.
Wha
On Sat, 3 Jan 2004, Gleb Smirnoff wrote:
> On Wed, Dec 31, 2003 at 05:26:46AM +0300, Nguyen Tam Chinh wrote:
> N> I get tons of messages with syntax like my line, all has
> N> begun after I set up a qpopper/tsl and a smbd, but i seems not to be the
> N> deal. I've searched through google and foun
On Wed, Dec 31, 2003 at 05:26:46AM +0300, Nguyen Tam Chinh wrote:
N> I get tons of messages with syntax like my line, all has
N> begun after I set up a qpopper/tsl and a smbd, but i seems not to be the
N> deal. I've searched through google and found some messages saying about
N> kind of attacking.
Good morning everybody,
I get tons of messages with syntax like my line, all has
begun after I set up a qpopper/tsl and a smbd, but i seems not to be the
deal. I've searched through google and found some messages saying about
kind of attacking. I now just can't find any detail logs in my freebsd
19 matches
Mail list logo
