One of Bluetooth’s earliest goals was simple: replace cables. Instead of plugging a serial RS-232 cable between two devices, just use Bluetooth. That is what RFCOMM does.

RFCOMM is based on the ETSI TS 07.10 standard — a multiplexer that runs multiple sessions over a single serial link. Bluetooth adopted it with some changes, so it is called an adopted protocol.

Common real-world uses of RFCOMM:

• Communication between two PCs
• Mobile phone connected to a Bluetooth headset
• Mobile phone tethered to a laptop

A real RS-232 port has 9 signal lines. RFCOMM emulates all 9 wirelessly. This makes RFCOMM a true drop-in replacement — terminal software like HyperTerminal or TeraTerm cannot tell the difference between a real cable and RFCOMM.

RFCOMM recognises two kinds of communication devices:

RFCOMM is a multiplexer. One Bluetooth link can carry up to 60 separate virtual connections at the same time. Each is identified by a DLCI (Data Link Connection Identifier). Think of DLCIs as lanes on a motorway — all on the same road but carrying different traffic independently.

Server applications register with RFCOMM and receive a Server Channel Number from 1 to 30. The final DLCI is calculated from this number and a direction bit (the lowest bit of DLCI) that identifies the initiator.

RFCOMM Multiplexing — Multiple apps sharing one Bluetooth link:

Multiple applications on both sides share one Bluetooth connection via RFCOMM DLCI multiplexing

This is one of RFCOMM’s key improvements over the base TS 07.10 standard, added after Bluetooth 1.0b. It solves this problem: what happens if the sender transmits faster than the receiver can process?

The answer: use credits as tokens. The receiver hands tokens to the sender. The sender spends one token per frame sent. When tokens run out, the sender stops and waits for more from the receiver.

Credit-based flow control prevents buffer overflow and emulates the RTS/CTS handshaking of RS-232

# List all RFCOMM bindings on this machine
rfcomm

# Bind rfcomm0 to a remote device on channel 1
rfcomm bind /dev/rfcomm0 AA:BB:CC:DD:EE:FF 1

# Connect to a remote RFCOMM channel interactively
rfcomm connect /dev/rfcomm0 AA:BB:CC:DD:EE:FF 1

# Release a binding
rfcomm release /dev/rfcomm0

# Once bound, use like any serial port
minicom -D /dev/rfcomm0

# Find RFCOMM channels via SDP
sdptool browse AA:BB:CC:DD:EE:FF | grep -A5 "RFCOMM"

OBEX stands for Object Exchange Protocol. Bluetooth adopted it from the IrDA (Infrared Data Association) world, where it was called IrOBEX. Because it was borrowed rather than invented for Bluetooth, it is called an adopted specification.

The key benefit: since OBEX is identical whether it runs over Bluetooth or infrared, applications written for IrDA work on Bluetooth with no changes.

How the OBEX stack changed between versions:

OBEX follows a strict client/server model — just like HTTP. The client always initiates. The server always responds. One request + one response = one operation. Operations are sequential — the client waits for a reply before sending the next request.

OBEX has exactly 6 operations. Each is a client request with a server response:

Here is what a typical OBEX contact-push looks like step by step between two phones:

Note on Abort: If the client wants to cancel step 5 midway through a large file, it sends an Abort operation. This stops the transfer cleanly without leaving corrupt data on the server side.

# Send a file using OBEX Object Push
obexftp --bluetooth AA:BB:CC:DD:EE:FF --channel 9 --put photo.jpg

# Send a vCard contact
obexftp --bluetooth AA:BB:CC:DD:EE:FF --channel 9 --put contact.vcf

# List files on remote device via OBEX FTP
obexftp --bluetooth AA:BB:CC:DD:EE:FF --channel 10 --list

# Pull a file from remote device
obexftp --bluetooth AA:BB:CC:DD:EE:FF --channel 10 --get notes.txt

# Using modern BlueZ obexctl (interactive session)
obexctl
  [obexctl]# connect AA:BB:CC:DD:EE:FF
  [NEW] Client /org/bluez/obex/client/session0
  [obexctl]# send /home/user/contact.vcf
  [obexctl]# disconnect