cURL / Mailing Lists / curl-users / Single Mail


Re: 7.9.6 sparc-sun-solaris2.4 ftp timeout after connect?

From: Daniel Stenberg <>
Date: Thu, 25 Apr 2002 23:10:19 +0200 (MET DST)

On Thu, 25 Apr 2002, Rich Gray wrote:

> Hello cURLers!

Hey Rich!

> I successfully built and ran 7.9.6 on our i386-pc-solaris2.7 system (once I
> figured out that I needed to do --disable-shared to build a stand-alone
> curl binary.)

Right, we have plenty other programs these days that use the library...!

> Ran into trouble with our sparc-sun-solaris2.4 system. Had some telnet
> warnings and sws failed to link but I got a good(?) curl binary anyway.

Yes, that's the test suite that doesn't build properly on all systems, mainly
because I use snprintf() in there and not all systems have that function.
This needs to be corrected...

> Solaris>./curl -vqm 30 -u UUUU:PPPPPP -T /etc/profile ftp://aix//tmp/rich
> * About to connect() to aix:21
> * Connected to aix ( port 21
> [roughly 3-5 second pause here...]
> * Closing connection #0
> curl: (28) Connection aborted

This error message originates from lib/ftp.c (around line 287) and should
only happen when curl reads... when curl recv()s zero or a negative number of

Reading the code tells me this:

 1. I can easily see how this could be made to not timeout within the given
    time scope, as the timeout isn't being reset properly between the
    select() calls. This shouldn't cause this problem though.

 2. This must be happening because the comparison says "gotbytes <= 0". Could
    you verify this by adding the gotbytes number in the error string or by
    changing the comparison to be "gotbytes < 0" ?

> Interestingly, 'telnet aix' gets the same several second delay between the
> connect and the login prompt. I might speculate that perhaps the aix
> system is doing some sort of reverse dns lookup on the connecting host and
> encountering some sort of short timeout? Further testing shows that there
> is a multi-second delay for curl/ftp/telnet to MOST (but not all?!) of our
> development systems. Curl 7.9.6 seems to not tolerate this. 6.5.2 does:

Of course it seems like development has been going the wrong way when a
release that's over two years old actually performs better than the

> I'm going to drop back and fix 6.2.5 to handle the 250 status to get our
> customer going

I'm pretty sure that operation will be straight-forward.

    Daniel Stenberg -- curl groks URLs --
Received on 2002-04-25