Port 152: BFTP — The Internet Learned to Transfer Files While You Sleep

What Port 152 Does

Port 152 is assigned to BFTP, the Background File Transfer Program. Both TCP and UDP are registered for this port.¹

BFTP does exactly what its name says: it transfers files in the background. You tell it what to move, where to move it, and walk away. A daemon handles the rest, retrying on failure and sending you an email when it finishes or gives up.²

Today this sounds like the most obvious thing in the world. In 1988, it was a genuine insight.

The Problem BFTP Solved

Before BFTP, file transfer on the Internet was an interactive affair. You opened an FTP session, typed your commands, and watched the bytes move. If the connection dropped, you started over. If the remote host was down, you tried again later. If you were transferring something large across an unreliable link, you sat there nursing the connection like a campfire in the wind.

By 1988, the Internet was growing fast enough that congestion and outages were becoming routine. Planned maintenance windows, flaky gateways, overloaded hosts. The foreground model of FTP assumed a cooperative, available network. The real network was increasingly neither.²

Annette DeSchon and Bob Braden at USC's Information Sciences Institute saw the mismatch and built BFTP to fix it.

How BFTP Works

BFTP has two components: a user interface that collects the parameters for a transfer, and a File Transfer Control (FTC) daemon that executes it.²

The clever part is the transfer model. BFTP uses FTP's "third party" or "server-to-server" mode. The FTC daemon opens control connections to both the source and destination FTP servers, then instructs them to transfer files directly between themselves. The daemon orchestrates but doesn't touch the data.

If a transfer fails temporarily (a broken TCP connection, a host that's briefly unreachable), the daemon logs the failure and retries after a timeout. It keeps retrying with increasing intervals until the transfer succeeds or hits a maximum retry count. Either way, you get an email notification.²

BFTP also supports wildcard transfers (move all .dat files from host A to host B), deferred delivery (schedule a transfer for off-peak hours), and parameter verification at submission time, so you don't find out six hours later that you typo'd the hostname.

The Human Engineering Problem

DeSchon and Braden identified something in RFC 1068 that remains deeply relevant: the "serious human-engineering problem" of asynchronous operations. When you run something interactively, mistakes show up immediately. When you submit a request and walk away, a typo in a filename or a wrong password might not surface for hours.²

Their solution was aggressive upfront verification. The BFTP user interface checks as many parameters as possible at submission time, connecting to the source and destination to verify that hosts, directories, and files actually exist before accepting the request.

This is the same pattern every modern async system uses: validate early, fail fast, notify on completion. In 1988, they had to reason their way to it from first principles.

The Telnet Gateway

BFTP includes a built-in Telnet server. You could connect to port 152 on any host running the BFTP service and submit transfer requests without having BFTP installed locally.² Open a Telnet connection, describe your transfer, disconnect. The daemon on the remote host handles the rest.

This made port 152 a gateway. Any machine on the Internet with a Telnet client could access background file transfer services, as long as there was a BFTP host somewhere on the network.

Where BFTP Lives Now

BFTP is a historical protocol. RFC 1068 is classified as "Legacy" by the IETF, meaning it was published before formal standardization processes were in place and carries no official standing.² You won't find BFTP daemons running on modern servers.

But its ideas are everywhere. Every download manager that resumes interrupted transfers. Every cloud sync service that runs in the background. Every CI/CD pipeline that moves artifacts between servers. Every rsync cron job. The pattern of "submit, retry, notify" that DeSchon and Braden formalized in 1988 is now so ubiquitous that we don't even notice it.

Security Considerations

BFTP uses a simple keyword-based authentication scheme rather than system-level credentials.² By modern standards, this is inadequate. The protocol was designed for a smaller, more trusting Internet.

Port 152 has been observed in malware traffic historically, as many legacy ports have been. If you see unexpected traffic on port 152, investigate. No modern service should be using it.

How to Check What Is Listening on Port 152

On Linux:

sudo ss -tlnp | grep :152
sudo lsof -i :152

On macOS:

sudo lsof -i :152

On Windows:

netstat -ano | findstr :152

If anything is listening on port 152 on your system, it is almost certainly not BFTP. Identify the process and determine whether it belongs.