FTP passive mode

How it works

RFC 959's passive reply gives an address and port. Firewalls that allow port 21 and block the passive range hang after login. The file does not move. Passive is what you want when the client is behind NAT.

A vendor job logs in on port 21 and hangs at RETR. Passive range 50000-51000 is closed. Opening that range lets the 800 MB feed finish. Active mode from the same NAT client never connects.

How it differs

Passive is not FTPS. You can do passive with or without TLS.

Some servers return a private address in the PASV reply. The client then connects to itself.

Fix the advertised address.

On the ticket

• The practical close is a log line: time, actor, byte count, result.
• Without that line the transfer is a story.
• With it, the next person can see whether this door did what the ticket claimed.
• If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
• On a real ticket, write down the door, the byte count, and the clock.
• For ftp passive mode, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
• A progress bar is not that record.
• A 200 response that arrives before the complete call is not that record.
• If a retry is allowed, say how many and whether it resumes.
• If a person must approve the send, name the person.
• Partners who receive ftp passive mode files should match on hash or size before they import.
• A same-length corrupt file passes a size check and fails a hash.
• Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
• When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.