Overview
File Transfer Protocol (FTP, RFC 959) moves files over a text control channel on TCP port 21, while the file bytes themselves travel on a separate data connection—TCP 20 in active mode, or a server-chosen high port in passive mode. From a PCAP/PCAPNG you can follow an entire session: the USER/PASS login handshake, navigation (CWD/PWD), transfers (RETR/STOR/APPE), and every numeric reply code. Because plain FTP is cleartext, captures also reveal exposed credentials and whether a session upgraded to FTPS with AUTH TLS. My Network Consultant parses every control command and reply and lays them out per session.
- What you’ll see: USER/PASS logins, RETR/STOR/APPE transfers, directory changes, PORT/PASV/EPSV mode setup, reply codes (230/331/530/550, 4xx data-connection issues), cleartext credential exposure, and AUTH TLS upgrades
- Best for: File-transfer troubleshooting, NOC troubleshooting, SOC triage, incident response
- Works with: control channel on TCP 21, active data on TCP 20, passive high ports, and AUTH TLS (FTPS) sessions
What to look for
- Login flow: USER → 331 (need password) → PASS → 230 (logged in), or 530 (not logged in) on failure,
- Cleartext credentials: a PASS command on a session that never negotiated AUTH TLS—the password crossed the network in the clear,
- Transfer commands: RETR (download), STOR/APPE (upload), DELE, RNFR/RNTO, MKD/RMD, LIST/NLST for directory listings,
- Permission & quota failures: 550 (file unavailable / no permission), 552 (storage allocation exceeded), 553 (file name not allowed),
- Data-connection problems: 425 (cannot open data connection) and 426 (transfer aborted), often firewall/NAT interfering with active/passive mode,
- Mode negotiation: PORT (active) vs PASV/EPSV/EPRT (passive) and the 227/229 entering-passive-mode replies,
- FTPS upgrade: AUTH TLS/SSL requesting an encrypted control channel—everything after it is TLS.
Capture tips
- Capture the control channel on TCP 21 to see the full command/reply dialog.
- Include the data connection (TCP 20 for active, or the passive high port from 227/229) to correlate transfer start and completion.
- Capture at a point that sees both directions so PORT/PASV setup and the data connection are visible together—key for diagnosing NAT/firewall issues.
- For FTPS, expect the dialog to go silent after AUTH TLS; the clear-text part up to the upgrade is still parsed.
- Use a focused time window that reproduces the issue and stays within the 10 MB demo limit.
Example walkthrough
- Browse to FTP.
- Follow the login handshake: USER, the 331 password prompt, PASS, and the 230 success (or 530 failure).
- Check whether the session used AUTH TLS; if not, note the cleartext credentials flag (the PASS argument is masked).
- Trace the transfer: RETR/STOR with the file name argument, and confirm the data connection opened.
- Inspect failure replies (425/426 data-connection, 550 permission, 552 quota) and isolate the responsible command.
- Open the parsed-message view to read each command and reply in order, and export evidence for the ticket.
FTP FAQ
Plain FTP sends the password in the clear: the PASS command carries the account password with no encryption. When a session sends PASS without first negotiating AUTH TLS, the analyzer flags cleartext credentials. The PASS argument itself is masked in the UI so the password is not displayed.
FTP replies are three-digit codes: 1xx preliminary, 2xx completion (230 logged in), 3xx intermediate (331 need password), 4xx transient failure (421/425/426 data-connection or service issues), and 5xx permanent failure (530 not logged in, 550 file unavailable or no permission). The analyzer lists each reply and highlights 4xx/5xx failures.
In active mode the client sends PORT and the server opens the data connection back from TCP 20; in passive mode the client sends PASV/EPSV and connects out to a server-chosen high port (227/229 give the address). Passive mode is friendlier to NAT and client firewalls, which is why 425 “cannot open data connection” errors often trace back to mode and firewall/NAT mismatches.
Yes. The AUTH command that requests a TLS upgrade of the control channel (RFC 4217) is shown and flagged. The clear-text control dialog up to the upgrade is parsed; everything after it is encrypted and handled as TLS.