Skip to content
FreeDOSDeep Dive Published Updated 4 min readViews unavailable

FreeDOS mTCP FTP: Passive Data Channels and Byte-Exact Transfers

Use mTCP's FTP client deliberately: choose a reachable data mode, set binary transfer explicitly, respect DOS filenames, and verify received bytes.

mTCP makes TCP/IP practical from a DOS prompt, but an FTP login is only the start of a transfer. The client keeps a control connection for commands and opens a separate data connection for a listing or file. A firewall can allow the first connection and still block the second. Even after both work, choosing ASCII for an archive or executable can transform its bytes. A reliable workflow therefore chooses a data mode, chooses a transfer type, respects DOS’s local filename rules, and checks the result independently.

The examples here use the mTCP FTP client documented in the 2025-01-10 mTCP user manual. Set up the packet driver, MTCPCFG, and network configuration first; the existing mTCP networking guide covers that groundwork.

The control connection is not the transfer path

Start the client with the server name or address:

C:\> ftp ftp.example.invalid

After opening its control socket, the client prompts for a user ID and password. The command prompt can list the remote directory, change directories, and start a transfer. In mTCP, get downloads and put uploads. The listing and file bytes move over a separate FTP data connection, so a successful login or pwd does not prove that the data path is reachable.

mTCP supports PORT and PASSIVE transfer modes and defaults to passive. In passive mode the client initiates the data connection to the server, which is usually easier when the DOS client is behind a NAT router or inbound-blocking firewall. PORT asks the server to connect to a client-side port; use it only when that server and the network path allow the server-initiated connection. The IETF’s firewall-friendly FTP memo describes why client-initiated passive data connections are easier through packet-filtering firewalls. If login works but dir or get stalls, try passive explicitly and check the server’s passive-port range and the firewall on that path before changing packet-driver settings. The mTCP manual describes the direction of each mode and recommends passive for modern servers and network edges.

ftp> xfermode passive
ftp> pwd
ftp> dir

Both dir and get open a data connection separate from the control connection. A successful listing proves that listing’s data connection worked, but a later get opens a new one and can still fail because its data path or the server’s transfer policy differs. An interruption is not a completed download; mTCP documents that Ctrl-C or Ctrl-Break stops the active operation prematurely. Reconnect and restart or verify the file instead of treating the partial destination as complete.

Select the transfer representation explicitly

For non-text files, switch to binary before the transfer:

ftp> binary
ftp> get RELEASE.ZIP RLS1013.ZIP

The mTCP manual says its client sends BIN after login by default, unless FTP_BIN_CMD_STUFF is disabled in the configuration. Do not make correctness depend on that default: servers can start in different transfer types, and a config change or server-side policy can alter the behavior. ascii requests text mode, in which line endings can be converted; binary/bin requests an unchanged byte stream and is the appropriate choice for archives, disk images, executables, and other binary payloads. For a text file, choose ASCII only when you intentionally want the FTP server’s text conversion.

DOS imposes a second boundary on filenames. A remote server may have long filenames, but the local FreeDOS destination must be legal for the local DOS filesystem and tools; use an explicit short local name rather than trusting a long remote name to be preserved. For example, download RELEASE.ZIP as RLS1013.ZIP and record the remote name alongside it.

Verify the local result

When the source file is available in a trusted local directory, compare it to the downloaded file byte-for-byte:

C:\LAB> fc /b SOURCE.ZIP RLS1013.ZIP

FreeDOS FC /B performs a binary comparison and reports whether the files differ; its exit status is zero when they match and one when a pair differs. This verifies the two local copies agree, not that the server originally supplied the intended release. For a distribution download, compare the resulting file with a checksum or signature obtained through an independently trusted channel, and keep the expected value associated with the downloaded filename.

If no local reference copy is available, compare a trusted digest using a DOS checksum utility whose algorithm and implementation you have verified. A transfer protocol’s successful completion message is useful, but it is not a substitute for authenticating the expected content. The protocol extension document RFC 2228 explains that classic FTP sends USER/PASS credentials in cleartext and provides no built-in encryption or authenticity check for commands and data. The mTCP manual documents an interactive credential prompt and warns against putting login data in redirected command scripts. Treat this documented classic FTP workflow as unprotected: do not use reusable secrets or sensitive files across an untrusted network.

The practical sequence is small: make sure the data-channel direction is reachable, set binary when bytes must not change, give the local copy a DOS-safe name, and verify it against a trusted reference. That catches the failure modes that a green login prompt cannot.

Related:

Sources:

Comments