I just ran a couple tests in gdb on my linux box, and (with the patch I
sent) I get a connection failed response when trying to connect to a
non-existent server (RST received in response to connect()).

It seems to me the fact that RST is being received indicates that it's
not a network latency issue. The tcpdump output you sent shows the RST
coming in a fraction of a second after the SYN. Also, Curl_connecthost()
calls connect() and then calls waitconnect() with a timeout of 0, so
there's very little time to decide that the connection succeeded or failed.

Assuming the server really is running on the host and port you're
connecting to, it does seem likely that there's a firewall or something
in the middle that's sending the RST.

I've been told Windows does some goofy things with RST, and that may be
the case here, but I don't know enough about Windows to say.

Joe

Richard Bramante wrote:
> This does seem horribly broken it it appears specific to this network
> environment. I duplicated the issue with just a small socket program.
>
> On the network having the problem, when I try the connect to 1.1.1.1 I get
> the SYN - RST behavior and we go off into the error 52 code path.
>
>>From home, when I try the same thing, I see 3 SYNs go out, no reply at all
> come back, and then get an error 7 as expected.
>
> I'm not a network infrustructure guru, but it would appear that there is
> some switch/router/whatever issuing the RSTs and this appears to be
> confusing the hell out of the Windows TCP/IP stack.
>
> This is the best I can come up with. I'm not sure if the problem lies in
> the Window's stack or if this network shouldn't be issuing the RST. I'll
> try a Linux client from the "problem" network on Monday and see how it
> behaves.
>
> ----- Original Message -----
> From: "Joe Halpin" <j.p.h_at_comcast.net>
> To: "libcurl development" <curl-library_at_cool.haxx.se>
> Sent: Friday, February 27, 2004 8:21 PM
> Subject: Re: CURLE_GOT_NOTHING on slow connections
>
>
>>That sounds horribly broken. Can you reproduce this behavior with a
>>small C program that just tries the connect, and checks it the same way
>>curl does? I'm thinking there must be some kind of disconnect someplace.
>>
>>Joe
>
>
Received on 2004-02-28