For Explicit FTPS mode, libcurl incorrectly reports connect timing.

[GLaDOS-418]

I did this

Here's a simple program that can reproduce this:

#include <curl/curl.h>
#include <cstdio>

void version();
void print_duration(CURL* curl);

int main(int argc, char **argv) {
    if (argc != 4) {
        std::fprintf(stderr, "Usage: %s URL USER PWD\n", argv[0]);
        return 1;
    }

    curl_global_init(CURL_GLOBAL_DEFAULT);

    version();

    CURL *curl = curl_easy_init();
    if (!curl) {
        curl_global_cleanup();
        return 1;
    }

    curl_easy_setopt(curl, CURLOPT_URL, argv[1]);
    curl_easy_setopt(curl, CURLOPT_USERNAME, argv[2]);
    curl_easy_setopt(curl, CURLOPT_PASSWORD, argv[3]);

    // explicit ftps: connect using ftp://, then issue AUTH TLS.
    curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_ALL);

    CURLcode rc = curl_easy_perform(curl);
    if (rc != CURLE_OK)
        std::fprintf(stderr, "curl: %s\n", curl_easy_strerror(rc));

    print_duration(curl);

    curl_easy_cleanup(curl);
    curl_global_cleanup();

    return 0;
}

void version() {
    const curl_version_info_data* const info = curl_version_info(CURLVERSION_NOW);

    std::fprintf(stderr,
        "\nlibcurl metadata:\n"
        "  version:     %s\n"
        "  host:        %s\n"
        "  ssl_version: %s\n",
        info->version ? info->version : "(none)",
        info->host ? info->host : "(none)",
        info->ssl_version ? info->ssl_version : "(none)");

    std::fprintf(stderr, "\n");
}

void print_duration(CURL* curl) {
    curl_off_t dns_us     = 0;
    curl_off_t connect_us = 0;
    curl_off_t tls_us     = 0;
    curl_off_t total_us   = 0;

    curl_easy_getinfo(curl, CURLINFO_NAMELOOKUP_TIME_T, &dns_us);
    curl_easy_getinfo(curl, CURLINFO_CONNECT_TIME_T,    &connect_us);
    curl_easy_getinfo(curl, CURLINFO_APPCONNECT_TIME_T, &tls_us);
    curl_easy_getinfo(curl, CURLINFO_TOTAL_TIME_T,      &total_us);

    const curl_off_t dns_duration_us = dns_us;
    const curl_off_t connect_duration_us = connect_us - dns_us;
    const curl_off_t tls_duration_us = tls_us > connect_us ? tls_us - connect_us : 0;

    std::fprintf(stderr,
        "\nTimings:\n"
        "  DNS:     %.3f ms\n"
        "  Connect: %.3f ms\n"
        "  TLS:     %.3f ms\n"
        "  Total:   %.3f ms\n",
        dns_duration_us     / 1000.0,
        connect_duration_us / 1000.0,
        tls_duration_us     / 1000.0,
        total_us            / 1000.0);
}

Now I compiled this against two libcurl versions 8.20 and 7.61 and tested against a public FTPS server:

url: ftp://demo.wftpserver.com
uname/pwd: demo demo

libcurl v8.20

Here's what it reported with 8.20:

$ ./eftps.new ftp://demo.wftpserver.com demo demo                                                        

libcurl metadata:
  version:     8.20.0
  host:        x86_64-pc-linux-gnu
  ssl_version: OpenSSL/3.5.5

drwxr-xr-x 2 user group              0  Aug 14 16:29 upload
drwxr-xr-x 2 user group              0  Jun 18 05:42 download

Timings:
  DNS:     5.916 ms
  Connect: 260.026 ms
  TLS:     58.061 ms
  Total:   316.231 ms

which is wildly off from what was reported in wireshark (6ms):

See this capture (remove the .txt from the end): eftps.new.pcapng.txt.

libcurl v7.61.1

Interestingly, when I tried out on a way older libcurl + openssl build, I did not see that issue:

$ ./eftps.old ftp://demo.wftpserver.com demo demo

libcurl metadata:
  version:     7.61.1
  host:        x86_64-redhat-linux-gnu
  ssl_version: OpenSSL/1.1.1k

drwxr-xr-x 2 user group              0  Aug 14 16:28 upload
drwxr-xr-x 2 user group              0  Jun 18 05:42 download

Timings:
  DNS:     2.504 ms
  Connect: 28.325 ms
  TLS:     731.917 ms
  Total:   698.976 ms

The wireshark timings for this are accurate enough (27ms):

see the wireshark capture below (remove the .txt).

eftps.old.pcapng.txt

libcurl 8.18.0

I do have a bigger program that's compiled with 8.18.0 with openssl 3.6.x which has the same issue. But, it was consistently producing 2x the connect time at the time (or so I believed but, 8.20 breaks that assumption so please ignore the annotations in the screenshot below).

It's on the same platform, unfortunately I lost the wireshark file for that. Here's the screenshot:

Note

• both the wireshark captures are recorded using the command:

$ sudo tshark -i any -f 'tcp port 21' -w /tmp/eftps.pcapng

• I did not find this deviation in Implicit FTPS (or Active/Passive FTP).
• MY GUESS is that for some reason it's "accumulating" connect time over various operations. Maybe because Explicit FTPS establishes the TCP connection, does a request-response round (AUTH SSL/AUTH TLS) with the server and THEN it starts the TLS connection. This is (afaik) a unique behaviour to Explicit FTPS alone. Coupled with the 8.18.0 analysis, I thought that was double counting only.

---

Let me know if my understanding is incorrect or what am I doing wrong.

I expected the following

I expect the connect time to accurately report the TCP connection time for Explicit FTPS mode (closely matching the Wireshark).

curl/libcurl version

libcurl 8.20.0 + OpenSSL 3.5.5
libcurl 8.18.0 + OpenSSL 3.6.x

operating system

$ uname -a
Linux <host_name> 5.15.0-322.203.3.4.el8uek.x86_64 #2 SMP Mon Jul 13 18:18:42 PDT 2026 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.10"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.10"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:10:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.10
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.10

[bagder]

It seems to reproduce with just this:

curl -u demo:demo ftp://demo.wftpserver.com -w '%{time_connect}\n'

[bagder]

For a while I suspected that it accidentally got the time until the second connection had connected, but that doesn't seem to be the case either. It reports an even larger time than that...

[GLaDOS-418]

@icing Thanks for the quick resolution.

I think the FIRSTSOCKET check is only partially fixing this.

I just pulled the latest master and it's still giving inflated data.

Can you please verify once with the Wireshark? 😅

[icing]

How would wireshark now when curl started the transfer?

There might be some confusion on what the reported duration really indicates: it is the time when curl started on the transfer up to the time the socket that finally succeeded (happy eyeballing) was TCP connected. This is not the time from the creation of the socket to its connect.

On my machine:

> curl -u demo:demo ftp://demo.wftpserver.com -w '%{time_connect} %{time_appconnect} %{time_namelookup}\n'
0.165626 0.000000 0.008294
> ping demo.wftpserver.com
PING demo.wftpserver.com (108.181.19.185): 56 data bytes
64 bytes from 108.181.19.185: icmp_seq=0 ttl=46 time=153.910 ms

and from the trace this looks correct on my end.

Update: added ping times

[GLaDOS-418]

@icing

How would wireshark now when curl started the transfer?

It's not like wireshark needs to know about curl.

But there needs to be some way to determine if the reported metrics is "good" or not. How do I do that?

So far I'm using wireshark to determine whether the reported time is close enough or not.

If you see the program I put in the issue, i calculated:

TCP duration = connect_time - namelookup_time
TLS duration = appconnect_time - connect_time

So for TCP, it should be close enough to the duration between syn,synack,syn (TCP handshake).

For TLS there're two things:

1. Implicit Ftps: it's the TLS handshake right after TCP.
2. Explicit ftps: along with TLS handshake, I think the duration would typically also include the 220 response and the AUTH SSL/AUTH TLS ping pong.

(I did attach one such example in the post).

---

Also, in your example, shouldn't appconnect be non zero given the use_ssl is supposed to be true? 🤔

[icing]

if I use ftps: in the url, it reports the TLS handshake:

> url -u demo:demo ftps://demo.wftpserver.com -w '%{time_connect} %{time_appconnect} %{time_namelookup}\n'
0.166243 0.551676 0.008199

Your calculation of the TCP duration should work in simple connect cases. However, due to how Happy Eyeballing and asynchronous resolving (if built) works nowadays, this is not always true. A socket may be created before the name resolve is complete.

If you want a true "this is how long it took the TCP socket that succeeded to connect", curl would need to expose another timer statistics.

[GLaDOS-418]

@icing

I think ftps:// for Implicit FTPS? Explicit FTPS uses ftp:// itself. I guess --ssl-reqd is needed maybe.

• REF: https://everything.curl.dev/ftp/ftps.html

I understood the point about happy eyeballs and async resolving but, I'm deliberately trying to constrain the scope here to a specific query to determine if the metrics are fixed or not (since the issue is closed by @bagder ).

I mean, it's your call anyway since you're the maintainer and I can give only so much evidence. But, I'd request you to revisit this please (and hopefully reopen 😅).

So for this I slightly modified the original program to resolve only to a pre-determined IPv4, and added verbose, timestamped logging. See this:

Program for Explicit FTPS

#include <curl/curl.h>
#include <chrono>
#include <cstdio>
#include <ctime>
#include <string>

struct DebugContext { std::string partial_line; };

int debug_callback(CURL*, curl_infotype, char*, size_t, void*);
void flush_debug(DebugContext*);
void print_duration(CURL*);

int main() {
    // Explicit FTP uses ftp:// scheme.
    constexpr const char* url = "ftp://demo.wftpserver.com";
    constexpr const char* username = "demo";
    constexpr const char* password = "demo";

    // port 21 is default FTP/ Explicit FTPS port.
    // For the IP, see the below nslookup/dig queries.
    constexpr const char* resolve_rule = "demo.wftpserver.com:21:108.181.19.185";

    curl_global_init(CURL_GLOBAL_DEFAULT);

    std::fprintf(stderr, "\n%s\n", curl_version());

    CURL *curl = curl_easy_init();
    if (!curl) {
        curl_global_cleanup();
        return 1;
    }

    curl_easy_setopt(curl, CURLOPT_URL, url);
    curl_easy_setopt(curl, CURLOPT_USERNAME, username);
    curl_easy_setopt(curl, CURLOPT_PASSWORD, password);

    // Force IPv4 resolution for the hostname to avoid DNS.
    curl_slist* resolve = curl_slist_append(nullptr, resolve_rule);
    curl_easy_setopt(curl, CURLOPT_RESOLVE, resolve);
    curl_easy_setopt(curl, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4);

    // explicit ftps: connect using ftp://, then issue AUTH TLS.
    curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_ALL);

    curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);

    DebugContext debug_context;
    curl_easy_setopt(curl, CURLOPT_DEBUGFUNCTION, debug_callback);
    curl_easy_setopt(curl, CURLOPT_DEBUGDATA, &debug_context);

    CURLcode rc = curl_easy_perform(curl);
    if (rc != CURLE_OK)
        std::fprintf(stderr, "curl: %s\n", curl_easy_strerror(rc));

    flush_debug(&debug_context);
    print_duration(curl);

    curl_slist_free_all(resolve);
    curl_easy_cleanup(curl);
    curl_global_cleanup();

    return 0;
}

void print_debug_line(const std::string& line) {
    using namespace std::chrono;
    const auto now = system_clock::now();
    const auto epoch_milliseconds = duration_cast<milliseconds>(now.time_since_epoch());
    const auto epoch_seconds = duration_cast<seconds>(epoch_milliseconds);
    const auto milliseconds_part = static_cast<int>(
        (epoch_milliseconds - epoch_seconds).count());

    const std::time_t time = static_cast<std::time_t>(epoch_seconds.count());
    std::tm local_time{};
    localtime_r(&time, &local_time);

    std::fprintf(stderr,
        "%04d-%02d-%02d [%02d:%02d:%02d.%03d] %s\n",
        local_time.tm_year + 1900,
        local_time.tm_mon + 1,
        local_time.tm_mday,
        local_time.tm_hour,
        local_time.tm_min,
        local_time.tm_sec,
        milliseconds_part,
        line.c_str());
}

int debug_callback(CURL*, curl_infotype type, char* data, size_t size, void* userptr) {
    if (type != CURLINFO_TEXT && type != CURLINFO_HEADER_IN && type != CURLINFO_HEADER_OUT) {
        // do not print transfer payloads or raw tls records.
        return 0;
    }

    auto* const context = static_cast<DebugContext*>(userptr);
    context->partial_line.append(data, size);

    std::size_t newline = 0;
    while ((newline = context->partial_line.find('\n')) != std::string::npos) {
        std::string line = context->partial_line.substr(0, newline);
        if (!line.empty() && line.back() == '\r')
            line.pop_back();

        print_debug_line(line);
        context->partial_line.erase(0, newline + 1);
    }

    return 0;
}

void flush_debug(DebugContext* context) {
    if (!context->partial_line.empty()) {
        print_debug_line(context->partial_line);
        context->partial_line.clear();
    }
}

void print_duration(CURL* curl) {
    curl_off_t dns_us     = 0;
    curl_off_t connect_us = 0;
    curl_off_t tls_us     = 0;
    curl_off_t total_us   = 0;

    curl_easy_getinfo(curl, CURLINFO_NAMELOOKUP_TIME_T, &dns_us);
    curl_easy_getinfo(curl, CURLINFO_CONNECT_TIME_T,    &connect_us);
    curl_easy_getinfo(curl, CURLINFO_APPCONNECT_TIME_T, &tls_us);
    curl_easy_getinfo(curl, CURLINFO_TOTAL_TIME_T,      &total_us);

    const curl_off_t dns_duration_us = dns_us;
    const curl_off_t connect_duration_us = connect_us - dns_us;
    const curl_off_t tls_duration_us = tls_us > connect_us ? tls_us - connect_us : 0;

    std::fprintf(stderr,
        "\nTimings:\n"
        "  DNS:     %.3f ms\n"
        "  Connect: %.3f ms\n"
        "  TLS:     %.3f ms\n"
        "  Total:   %.3f ms\n",
        dns_duration_us     / 1000.0,
        connect_duration_us / 1000.0,
        tls_duration_us     / 1000.0,
        total_us            / 1000.0);
}

IP for demo.wftpserver.com

So, for the given server demo.wftpserver.com, I see only IPv4 records (see the nslookup and the dig outputs below containing only A records -- 108.181.19.185). I hardcoded the same in the program.

$ nslookup demo.wftpserver.com
Server:		172.21.82.66
Address:	172.21.82.66#53

Non-authoritative answer:
Name:	demo.wftpserver.com
Address: 108.181.19.185

$ dig demo.wftpserver.com

; <<>> DiG 9.11.36-RedHat-9.11.36-16.el8_10.8 <<>> demo.wftpserver.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41826
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;demo.wftpserver.com.		IN	A

;; ANSWER SECTION:
demo.wftpserver.com.	1463	IN	A	108.181.19.185

;; Query time: 0 msec
;; SERVER: 172.21.82.66#53(172.21.82.66)
;; WHEN: Sat Aug 15 12:08:19 UTC 2026
;; MSG SIZE  rcvd: 64

Program log

This is the complete log it produced:

$ ./eftps
libcurl/8.22.0-DEV OpenSSL/3.5.5 zlib/1.2.11 zstd/1.4.4 libpsl/0.20.2
2026-08-15 [12:40:48.558] !!! WARNING !!!
2026-08-15 [12:40:48.558] This is a debug build of libcurl, do not use in production.
2026-08-15 [12:40:48.558] [DNS] added demo.wftpserver.com:21:108.181.19.185 to cache
2026-08-15 [12:40:48.558] Hostname demo.wftpserver.com was found in DNS cache
2026-08-15 [12:40:48.558] Host demo.wftpserver.com:21 was resolved.
2026-08-15 [12:40:48.558] IPv6: (none)
2026-08-15 [12:40:48.558] IPv4: 108.181.19.185
2026-08-15 [12:40:48.559]   Trying 108.181.19.185:21...
2026-08-15 [12:40:48.566] Established connection to demo.wftpserver.com (108.181.19.185 port 21) from 172.21.82.23 port 38558
2026-08-15 [12:40:48.572] 220 Wing FTP Server ready...
2026-08-15 [12:40:48.572] AUTH SSL
2026-08-15 [12:40:48.578] 234 AUTH command OK. Initializing SSL connection.
2026-08-15 [12:40:48.584] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.584] SSL Trust Anchors:
2026-08-15 [12:40:48.601]   CAfile: /etc/pki/tls/certs/ca-bundle.crt
2026-08-15 [12:40:48.602] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.602] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.602] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.602] TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.611] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.612] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
2026-08-15 [12:40:48.612] TLSv1.3 (IN), TLS handshake, Certificate (11):
2026-08-15 [12:40:48.617] TLSv1.3 (IN), TLS handshake, CERT verify (15):
2026-08-15 [12:40:48.618] TLSv1.3 (IN), TLS handshake, Finished (20):
2026-08-15 [12:40:48.618] TLSv1.3 (OUT), TLS handshake, Finished (20):
2026-08-15 [12:40:48.618] SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp256r1 / id-ecPublicKey
2026-08-15 [12:40:48.618] Server certificate:
2026-08-15 [12:40:48.618]   subject: CN=demo.wftpserver.com
2026-08-15 [12:40:48.618]   start date: Jul  1 12:07:35 2026 GMT
2026-08-15 [12:40:48.618]   expire date: Sep 29 12:07:34 2026 GMT
2026-08-15 [12:40:48.619]   issuer: C=US; O=Let's Encrypt; CN=YE2
2026-08-15 [12:40:48.619]   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   subjectAltName: "demo.wftpserver.com" matches cert's "demo.wftpserver.com"
2026-08-15 [12:40:48.619] OpenSSL verify result: 0
2026-08-15 [12:40:48.619] SSL certificate verified via OpenSSL.
2026-08-15 [12:40:48.619] Established connection to demo.wftpserver.com (108.181.19.185 port 21) from 172.21.82.23 port 38558
2026-08-15 [12:40:48.619] USER demo
2026-08-15 [12:40:48.625] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
2026-08-15 [12:40:48.625] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
2026-08-15 [12:40:48.672] 331 Password required for demo
2026-08-15 [12:40:48.673] PASS demo
2026-08-15 [12:40:48.726] 230 User demo logged in.
2026-08-15 [12:40:48.726] PBSZ 0
2026-08-15 [12:40:48.733] 200 PBSZ=0
2026-08-15 [12:40:48.733] PROT P
2026-08-15 [12:40:48.739] 200 Data channel will be encrypted.
2026-08-15 [12:40:48.740] PWD
2026-08-15 [12:40:48.746] 257 "/" is current directory.
2026-08-15 [12:40:48.746] Entry path is '/'
2026-08-15 [12:40:48.746] Request has same path as previous transfer
2026-08-15 [12:40:48.746] EPSV
2026-08-15 [12:40:48.746] Connect data stream passively
2026-08-15 [12:40:48.752] 229 Entering Extended Passive Mode (|||1248|)
2026-08-15 [12:40:48.752] Connecting to 108.181.19.185 port 1248
2026-08-15 [12:40:48.753]   Trying 108.181.19.185:1248...
2026-08-15 [12:40:48.760] SSL reusing session with ALPN '-'
2026-08-15 [12:40:48.760] SSL verify result: 0
2026-08-15 [12:40:48.761] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.761] TYPE A
2026-08-15 [12:40:48.767] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.767] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.768] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.768] TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.768] 200 Type is set.
2026-08-15 [12:40:48.768] LIST
2026-08-15 [12:40:48.775] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.775] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
2026-08-15 [12:40:48.775] TLSv1.3 (IN), TLS handshake, Finished (20):
2026-08-15 [12:40:48.775] TLSv1.3 (OUT), TLS handshake, Finished (20):
2026-08-15 [12:40:48.775] SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp256r1 / UNDEF
2026-08-15 [12:40:48.775] Server certificate:
2026-08-15 [12:40:48.775]   subject: CN=demo.wftpserver.com
2026-08-15 [12:40:48.775]   start date: Jul  1 12:07:35 2026 GMT
2026-08-15 [12:40:48.776]   expire date: Sep 29 12:07:34 2026 GMT
2026-08-15 [12:40:48.776]   issuer: C=US; O=Let's Encrypt; CN=YE2
2026-08-15 [12:40:48.776]   subjectAltName: "demo.wftpserver.com" matches cert's "demo.wftpserver.com"
2026-08-15 [12:40:48.776] OpenSSL verify result: 0
2026-08-15 [12:40:48.776] SSL certificate verified via OpenSSL.
2026-08-15 [12:40:48.776] Established 2nd connection to demo.wftpserver.com (108.181.19.185 port 1248) from 172.21.82.23 port 35210
2026-08-15 [12:40:48.776] 150 Opening data channel for directory list.
2026-08-15 [12:40:48.776] Maxdownload = -1
2026-08-15 [12:40:48.784] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
drwxr-xr-x 2 user group              0  Aug 15 12:40 upload
drwxr-xr-x 2 user group              0  Jun 18 05:42 download
2026-08-15 [12:40:48.832] TLSv1.3 (IN), TLS alert, close notify (256):
2026-08-15 [12:40:48.832] TLSv1.3 (OUT), TLS alert, close notify (256):
2026-08-15 [12:40:48.832] sendrecv_dl: we are done
2026-08-15 [12:40:48.832] Remembering we are in directory ""
2026-08-15 [12:40:48.832] 226 Transfer successful.
2026-08-15 [12:40:48.832] Connection #0 to host demo.wftpserver.com:21 left intact

Timings:
  DNS:     0.096 ms
  Connect: 16.112 ms
  TLS:     44.917 ms
  Total:   274.655 ms

Connect (TCP) Duration

Now, if you see the Connect (appconnect - namelookup) is posted as: ~16ms.

I would have assumed it to be around ~8ms from the below log slice (so the reported value is 2x the expected one):

2026-08-15 [12:40:48.558] Host demo.wftpserver.com:21 was resolved.
2026-08-15 [12:40:48.558] IPv6: (none)
2026-08-15 [12:40:48.558] IPv4: 108.181.19.185
2026-08-15 [12:40:48.559]   Trying 108.181.19.185:21...
2026-08-15 [12:40:48.566] Established connection to demo.wftpserver.com (108.181.19.185 port 21) from 172.21.82.23 port 38558

Secure Handshake Duration (~TLS)

For TLS, the reported time is ~45ms.

and I would've assumed that TLS time would be ~53ms (appconnect - connect) based on the following slice (i.e. for Explicit FTPS it's 220 response -> AUTH SSL ping pong -> TLS Handshake).

Interestingly, the amount for which the TLS duration is similar to the amount by which the TCP duration was inflated (could be a coincidence, or not -- earlier I assumed it was double counting connect time for explicit because unlike other protocols, TCP is done, and after FTP ping pong, TLS is done so the SSL filter for time progress is counting extra the second time -- but, ignore this):

2026-08-15 [12:40:48.566] Established connection to demo.wftpserver.com (108.181.19.185 port 21) from 172.21.82.23 port 38558
2026-08-15 [12:40:48.572] 220 Wing FTP Server ready...
2026-08-15 [12:40:48.572] AUTH SSL
2026-08-15 [12:40:48.578] 234 AUTH command OK. Initializing SSL connection.
2026-08-15 [12:40:48.584] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.584] SSL Trust Anchors:
2026-08-15 [12:40:48.601]   CAfile: /etc/pki/tls/certs/ca-bundle.crt
2026-08-15 [12:40:48.602] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.602] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.602] TLSv1.3 (OUT), TLS handshake, Client hello (1):
2026-08-15 [12:40:48.602] TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
2026-08-15 [12:40:48.611] TLSv1.3 (IN), TLS handshake, Server hello (2):
2026-08-15 [12:40:48.612] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
2026-08-15 [12:40:48.612] TLSv1.3 (IN), TLS handshake, Certificate (11):
2026-08-15 [12:40:48.617] TLSv1.3 (IN), TLS handshake, CERT verify (15):
2026-08-15 [12:40:48.618] TLSv1.3 (IN), TLS handshake, Finished (20):
2026-08-15 [12:40:48.618] TLSv1.3 (OUT), TLS handshake, Finished (20):
2026-08-15 [12:40:48.618] SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp256r1 / id-ecPublicKey
2026-08-15 [12:40:48.618] Server certificate:
2026-08-15 [12:40:48.618]   subject: CN=demo.wftpserver.com
2026-08-15 [12:40:48.618]   start date: Jul  1 12:07:35 2026 GMT
2026-08-15 [12:40:48.618]   expire date: Sep 29 12:07:34 2026 GMT
2026-08-15 [12:40:48.619]   issuer: C=US; O=Let's Encrypt; CN=YE2
2026-08-15 [12:40:48.619]   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
2026-08-15 [12:40:48.619]   subjectAltName: "demo.wftpserver.com" matches cert's "demo.wftpserver.com"
2026-08-15 [12:40:48.619] OpenSSL verify result: 0
2026-08-15 [12:40:48.619] SSL certificate verified via OpenSSL.
2026-08-15 [12:40:48.619] Established connection to demo.wftpserver.com (108.181.19.185 port 21) from 172.21.82.23 port 38558

Wireshark

The same can be seen in the wireshark, the TCP (syn -> syn + ack -> ack) is 6ms (close to what's reported in the log.

The full Wireshark file is here (remove the .txt):

eftps.master.pcapng.txt