Port 3240: USB/IP — Where USB Devices Escape Their Cables

What Port 3240 Is

IANA lists port 3240 as unassigned (with a minor historical footnote to something called "triomotion" that never took hold). In practice, one protocol has quietly claimed this port as its own: USB/IP.

USB/IP does something that sounds impossible. You plug a USB device — a hardware key, a smartcard reader, a security token — into one machine. USB/IP makes that device available to another machine across the network, as if the cable ran through the wall. The remote machine sees it, mounts it, and talks to it directly.

The daemon that makes this work, usbipd, listens on TCP port 3240 by default.

How USB/IP Works

There are two phases to every USB/IP connection.

First, discovery. The client connects to port 3240 and asks the server: what USB devices are you exporting? The server responds with a list. This is a simple request-response exchange, and it stays in userspace.

Second, attachment. Once the client selects a device, both sides hand the socket down into the Linux kernel. From that point, the USB/IP kernel driver handles everything — translating USB requests into network packets and back. The userspace daemon is done; the kernel takes over.

This is how a Yubikey plugged into a server in a data center can authenticate a login on a virtual machine running somewhere else entirely.

Where You'll See It

USB/IP has become especially visible in two contexts:

Windows Subsystem for Linux (WSL). WSL runs a Linux kernel inside Windows, but WSL doesn't have direct access to USB devices — it's isolated from the host hardware. The usbipd-win project solves this by running a usbipd server on the Windows host, allowing WSL to attach to USB devices over the loopback interface via port 3240.¹

Remote development environments. Engineers working in cloud VMs or containers often need local USB devices — hardware keys, custom microcontrollers, security tokens. USB/IP tunneled over SSH or a VPN lets those devices follow them into their remote environment.

The Protocol Without an RFC

USB/IP has no formal IETF RFC. When the protocol was being considered for inclusion in the Linux kernel, someone asked whether it should go through the RFC process. The response from a kernel maintainer was direct: "Windows has had this for years, no need for an RFC there, and if we just document this well, no need for one here either."²

So port 3240 carries a protocol documented in the Linux kernel source tree³ but never formally standardized. It works. It's in the kernel. There's just no RFC to cite.

What's Listening on This Port

If port 3240 is open on a machine, it's almost certainly usbipd. To check:

Linux:

ss -tlnp | grep 3240
# or
lsof -i :3240

macOS:

lsof -i :3240

Windows:

netstat -ano | findstr :3240

If nothing is listening, the port is closed. Port 3240 shouldn't be open on machines that aren't intentionally running a USB/IP server. If you find it open unexpectedly, investigate.

Security Note

A usbipd server with no authentication exposes USB devices to anyone who can reach port 3240. The protocol itself has minimal built-in security. If you're running usbipd, firewall the port to trusted hosts or restrict it to the loopback interface. Exposing USB devices to the open Internet is a bad idea.

What "Registered" Means for This Port

Port 3240 sits in the registered port range (1024-49151). IANA maintains this registry so that developers can request official assignments and avoid collisions. Unlike well-known ports (0-1023), registered ports don't require elevated privileges to open on most systems.

The irony of port 3240 is that IANA formally registered it to a service that went nowhere, while the actual widespread use — USB/IP — just picked the port and ran with it, never registering. This is not unusual. The registered port list reflects intent, not reality. Reality is messier.