PORT, PASV, EPRT, and EPSV: FTP's Four Data-Connection Commands

Every FTP transfer — every upload, every download, even every directory listing — begins with one of four commands: PORT, PASV, EPRT, or EPSV. Each one is a different way of answering the same question: where should the data connection go? Until it is settled, no file moves — and when a transfer misbehaves, the evidence is almost always one of these four lines in the session log.

By the end of this article you will decode a line like 227 Entering Passive Mode (203,0,113,10,195,87) by eye, know why two of the four commands were added later, recognize the fallback dance clients use to pick a command the server understands, and know at a glance which commands get along with firewalls. This article is part of our Active vs Passive FTP series; if the two modes themselves are still fuzzy, start with active vs passive FTP explained and come back — this piece builds directly on it.

The Sixty-Second Recap: Two Connections, Two Modes

An FTP session is two network connections, not one. The control connection is the long-lived conversation between client and server, normally on port 21 — it carries your login, your commands, and the server's numbered replies, and it stays open for the whole session. The data connection is a separate, temporary connection that carries the actual payload: file contents and directory listings. A fresh one is created for each transfer, used once, and closed. All four commands in this article travel over the control connection, and all four exist to arrange the next data connection.

The two modes differ only in who opens the data connection. In active mode, the client says "call me back at this address" — that is PORT, or its modern cousin EPRT — and the server dials the client. In passive mode, the client asks "where do I call you?" — that is PASV, or its modern cousin EPSV — and the client dials the server. So the four commands are two jobs in two generations: an original pair built around IPv4 addresses, and a newer extended pair that handles any address type. Everything that follows is fine print.

PORT: Anatomy of the Six-Number Address

In active mode, the client picks an unused high port on its own machine, listens on it, and must tell the server where to call back. PORT is how it says so, and the format looks stranger than it is:

PORT h1,h2,h3,h4,p1,p2

Six decimal numbers, each between 0 and 255. The first four are the easy part: the client's IPv4 address, read straight across with dots instead of commas. The last two are the port number — and here comes the famous arithmetic.

A port number can be anything from 0 to 65535 — too large for a single 0-to-255 slot — so the protocol splits it into two bytes: p1 is the "how many 256s" part, p2 is the remainder. To decode, multiply the fifth number by 256 and add the sixth. A full worked example:

Command:  PORT 198,51,100,23,197,143

Address:  198.51.100.23        (first four numbers, dots for commas)
Port:     197 x 256 = 50432
          50432 + 143 = 50575
Meaning:  "Server, open the data connection to 198.51.100.23, port 50575."

And a second one — read the six numbers first and try to beat the decode:

Command:  PORT 192,168,1,50,201,74

Address:  192.168.1.50
Port:     201 x 256 = 51456
          51456 + 74 = 51530
Meaning:  "Server, open the data connection to 192.168.1.50, port 51530."

That second example smuggles in a warning. Any address starting with 192.168. is a private address — one of the reserved ranges that only have meaning inside a local network, never on the public internet. A server across the internet cannot possibly reach 192.168.1.50; the callback will fail before it starts. Clients behind NAT (network address translation — the technique that lets a whole office share one public IP address) put exactly this kind of unreachable address into their PORT commands — one of the two big reasons active mode fails on modern networks. The other reason, and the full story, is in why firewalls block active FTP.

Encoding runs the same math backwards: divide the port by 256; the whole-number result and the remainder are your two values. A client listening on port 51530 sends 201,74 because 51530 ÷ 256 = 201 remainder 74. If the server accepts, it answers 200 PORT command successful, then dials out the moment the client requests a listing or a file.

PASV and the 227 Reply

PASV is the mirror image. The client sends the command with no arguments — a question, not an announcement. The server picks an unused port from its configured passive port range (the block of ports it is allowed to hand out), listens on it, and answers with a 227 reply in the very same six-number format — except now the address and port belong to the server:

Command:  PASV
Response: 227 Entering Passive Mode (203,0,113,10,195,87)

Address:  203.0.113.10
Port:     195 x 256 = 49920
          49920 + 87 = 50007
Meaning:  "Client, open the data connection to 203.0.113.10, port 50007."

Same arithmetic, opposite direction. One more, decoded at reading speed:

Response: 227 Entering Passive Mode (203,0,113,10,196,212)

Port:     196 x 256 + 212 = 50388
Meaning:  same server, different transfer — connect to port 50388 this time.

Notice the port changed between the two replies. That is normal: the server picks a fresh port from its passive range for each data connection, which is why the whole range — not just one port — must be open on the server's firewall.

Now for the red flag every administrator should learn to spot. If you are connecting to a server across the internet and the reply says 227 Entering Passive Mode (192,168,1,5,195,88), the server has just asked you to connect to 192.168.1.5 — a private address that exists only inside the server's own network. The server sits behind NAT and is announcing its internal address instead of its public one. Your client will obediently try, hang, and fail with a timeout or a 425 error. The private ranges to memorize: 10. anything, 172.16. through 172.31., and 192.168. anything. A private address in a 227 reply from an internet server is the most common passive-mode failure, and spotting it by eye is half the diagnosis — the other half is in diagnosing FTP mode failures.

Why Two More Commands Exist

The six-number comma format has a limit baked into its bones: exactly four numbers for the address — an IPv4 address and nothing else. IPv6 is the internet's newer addressing system, created because the older IPv4 scheme was running out of addresses — its addresses are longer and written in hexadecimal groups separated by colons, like 2001:db8::1a2b. There is no way to pour that into h1,h2,h3,h4. The format is not awkward for IPv6; it is impossible.

So the FTP specification gained a pair of extended commands: EPRT as the extended PORT, and EPSV as the extended PASV. They do the same two jobs — "call me back here" and "where do I call you?" — in packaging that works for any address family. As a bonus, EPSV quietly fixes an old NAT headache while it is at it.

EPRT: The Extended Active Command

EPRT makes the same request as PORT, but drops the six-number puzzle in favor of clearly separated fields. The structure uses a delimiter — a chosen punctuation character that marks where one field ends and the next begins:

EPRT |protocol|address|port|

The standard permits other delimiter characters, but in practice it is always the vertical bar. The protocol field names the address family: 1 means IPv4, 2 means IPv6. The address is written the way humans write it, and the port is plain decimal — no multiplying, no remainders. Two worked examples:

Command:  EPRT |1|198.51.100.23|50575|
Meaning:  IPv4 — connect back to 198.51.100.23, port 50575
          (the same request as PORT 198,51,100,23,197,143, minus the arithmetic)

Command:  EPRT |2|2001:db8::1a2b|50575|
Meaning:  IPv6 — connect back to 2001:db8::1a2b, port 50575
          (a request the classic PORT command has no way to express)

A server that accepts answers 200, and the transfer proceeds like classic active mode: the server dials the announced address.

Be clear-eyed about what EPRT fixes, though: the message format, not the network reality. The data connection still travels from server to client — still an unsolicited inbound connection in the eyes of the client's firewall, still doomed if the announced address is private. If PORT cannot get through a firewall, EPRT will not either. It solves the IPv6 problem, not the NAT problem.

EPSV: The Extended Passive Command

EPSV is where the extension gets genuinely clever. The client sends the command bare (an optional protocol argument exists but is rarely used), and the server answers with a 229 reply:

Command:  EPSV
Response: 229 Entering Extended Passive Mode (|||50007|)

Look closely at the bars: the fields where a protocol and an address would go are deliberately blank. The reply carries only a port number. So where does the client connect? That is the same-address rule: the data connection goes to the same host as the control connection — the address the client is already talking to. The client takes that address, attaches port 50007, and dials.

This design has a pleasant side effect that matters more than IPv6 support on many networks. Remember the passive-mode red flag — a NAT'd server announcing its private address in the 227 reply? EPSV makes that entire failure class impossible, because a reply that contains no address cannot contain a wrong address. Behind NAT, that makes extended passive the friendliest arrangement FTP has: the client already found its way to the server's public address for the control connection, and the data connection simply follows it there. The server still needs its passive port range reachable through the firewall — configuring passive port ranges walks through that — but the address half of the problem is gone by design.

One relative is worth recognizing: EPSV ALL — a client's promise to use only EPSV for the rest of the session, after which the server refuses PORT, PASV, and EPRT. The promise exists for the benefit of FTP-aware firewalls and NAT devices that read the control connection to decide which ports to open: after EPSV ALL, they know no address will ever appear in the conversation, so there is nothing to inspect or rewrite. Careful modern clients send it; the server answers 200 and the session carries on.

How Clients Actually Negotiate

Four commands, one decision — and the client makes it. Modern clients prefer EPSV first, even over plain IPv4, precisely because of the no-address benefit above. But the internet is full of older servers that have never heard of it, so FTP needs a graceful way to discover what a server speaks. The method is charmingly simple: try the command and watch the reply. A server answers a command it does not recognize with 500 ("command not understood") or 502 ("command not implemented") — the wording varies by server; the number is what matters. The client hears the refusal and falls back to the classic command. In a session log, the fallback looks like this:

Command:  EPSV
Response: 500 Command not understood
Command:  PASV
Response: 227 Entering Passive Mode (203,0,113,10,196,212)
Command:  RETR report.csv
Response: 150 Opening data connection
Response: 226 Transfer complete

Read it as a small conversation: the client offered the newer command, the server declined politely, the client used the older one, and the file transferred anyway — total cost, one extra round trip. This matters when you troubleshoot, because a 500 looks alarming until you notice the next line. A 500 followed immediately by a successful fallback is normal negotiation, not an error to fix. Some clients skip the guesswork by asking for the server's feature list with the FEAT command; others simply try and adapt. Both roads end in the same place.

One situation offers no fallback: a control connection made over IPv6. There, the six-number format of PORT and PASV literally cannot describe either end of the connection, so the extended commands are the only option. Unattended transfers negotiate exactly the same way, which is worth knowing when you automate: a scheduled job built in Sysax FTP Automation records these commands and replies in its transfer logs, so when an overnight job fails you can read which data command was sent and how the server answered.

Firewall Implications, Command by Command

Strip away the formats and a firewall cares about one thing: which direction the data connection travels. That, plus whether an address rides inside the command, determines how each of the four behaves on a NAT'd network:

The pattern to internalize: the passive commands point the data connection at the server, the direction firewalls tolerate; the active commands point it at the client, which modern networks refuse. Within each pair, the extended command is the more robust citizen — dramatically so on the passive side.

Practice: Decode These Three Lines

Reading about the arithmetic is one thing; doing it once makes it permanent. Here are three lines of the kind you will meet in real session logs. For each, work out which mode is being arranged, what address and port the data connection will use, and whether anything looks suspicious — then open the answers to check yourself.

1)  PORT 192,0,2,61,213,44

2)  227 Entering Passive Mode (10,1,2,3,78,60)

3)  229 Entering Extended Passive Mode (|||50127|)

If all three felt easy, you now read FTP data negotiation fluently.

Where These Commands Come From, and Where to Go Next

PORT and PASV are as old as FTP itself — both are defined in the original FTP specification, which is why every client and server ever written understands them. EPRT and EPSV come from a later extension to that specification, built for IPv6 and, in EPSV's happy case, kinder to NAT as well. The specification and its later extensions were written so that old and new implementations negotiate gracefully, with the 500-and-fall-back dance doing the diplomacy. Server-side, this is a box worth checking before you deploy: a standards-compliant server such as Sysax Multi Server implements all four commands, so a legacy device that only speaks PORT and a modern client that opens with EPSV can both move files off the same Windows machine, each in the dialect it knows.

The pocket summary, one line per command:

• PORT — active, classic: "call me back," address and port packed into six comma-separated numbers.
• PASV — passive, classic: "where do I call you?", answered by a 227 reply in the same six-number format.
• EPRT — active, extended: "call me back," any address family, delimiter format, plain decimal port.
• EPSV — passive, extended: "where do I call you?", answered by a 229 reply carrying only a port; the data connection follows the control connection's address.

From here, the natural next step in this series is diagnosing FTP mode failures, which uses these decoding skills on every page. For the wider protocol around these commands, see our FTP protocol series; for the plain-English basics of the port numbers themselves, the blog post What port is FTP? is a quick companion read.

Frequently Asked Questions