Distributed receivers • Internet clients • central services

From one scanner to a worldwide network.

ACARSd combined several network layers: live receiver servers, remote clients, public server discovery, a browser interface, centralized historical reporting and even network transport of raw audio for development.

The core model

ACARS did not provide the same continuous position stream as ADS-B. Nevertheless, the Internet topology anticipated a pattern that later became central to crowd-sourced flight tracking.

Aircraft ACARS VHF
        ↓
Airband scanner → sound card → ACARSd decoder
                                │
                  ┌─────────────┼──────────────┐
                  ↓             ↓              ↓
              TCP server     Web server     Local DB
              port 2202         │              │
                  ↓             ↓              ↓
           remote clients   web browser   public reports
                  │                            │
                  └──── public server list ────┘
                               ↓
                         acarsd.org services

Port 2202

The default port was personal.

The ACARSd server used TCP port 2202. The reason was not technical: 22 February was the author’s birthday. Contemporary code and documentation repeatedly identify 2202 as the normal service port.

Older client code also knows port 2203 and can retry it as an alternate. A CVS entry dated 5 February 2004 states: “acarsd listens now only to one port (2202)”. The exact original role of 2203 has not yet been proven from the surviving pre-change source.

TCP 2202

Public station discovery

Server metadata included name, alias, location, information and port. Later protocol code contains explicit operations for requesting and publishing public server entries, allowing clients and servers to distribute knowledge of available stations.

AS_PUBGET

Request the public list

A connected client could ask a server for the public stations it knew about.

AS_PUBPOST

Publish an entry

Server information could be propagated through the network rather than remaining a local configuration item.

CLIENTNG

Remote observation

A user did not need a local receiver to watch data from public ACARSd servers in other locations.

Central history

Live sharing and historical collection were separate layers.

The public database code builds collections from locally received ACARS data, rejects records without verified CRC and uploads the resulting dataset to central services. The original website later exposed worldwide ACARS reports and fleet/flight lookup tools.

That separation is important: live clients could watch a station in real time, while the central service accumulated data useful for historical searches.

Historic ACARS flight grid — Historic flight-grid image from the ACARSd source tree.

Port 1999

Even the audio could travel over the network.

ACARSd could operate as a sound server or sound client. Raw receiver audio could be served over TCP so another machine could run and test a decoder build without disturbing the production receiver computer.

This was mainly a development and operational tool, but it shows how deeply networking was embedded in the project: even the layer below message decoding could be remote.

DEVELOPMENT WORKFLOW

Receiver here, decoder there

Keep the main station running; feed its sound over the LAN to a second system; test new decoder code against live radio without taking the station offline.

Recognised by Nmap

ACARSd became a network service with its own fingerprint.

Nmap's service-detection database contains an ACARSd signature that identifies the daemon from its actual response rather than merely guessing from a port number. A dedicated NSE script, acarsd-info.nse, was added to Nmap in 2012 and targets the characteristic ACARSd server service on TCP 2202.

The script can report the ACARSd version, API version, whether authorisation is required, the number of connected clients and the receiver frequency. For a project that began with a scanner and a sound card, becoming independently recognisable to one of the best-known network discovery tools was a remarkable external footprint.

Source note: the dedicated Nmap NSE script is documented by the Nmap project and its 2012 development history. The service probe is protocol-aware; the script's default port is 2202. Earlier ACARSd versions used a paired 2202/2203 arrangement before later releases consolidated on 2202.

$ nmap -p 2202 --script acarsd-info host

2202/tcp open  acarsd
| acarsd-info:
|   Version: ...
|   API Version: ...
|   Authorization Required: ...
|   Clients Connected: ...
|_  Frequency: ...

ACARSd and later crowd-sourced flight tracking

The comparison should be precise. ACARS is not ADS-B, and ACARSd was not a modern continuous global radar map. Yet several architectural ideas are clearly related.

Concept	ACARSd	Modern ADS-B networks
Distributed private receivers	Yes	Yes
Internet contribution / sharing	Yes	Yes
Remote clients without a local radio	Yes	Yes
Central historical dataset	Yes	Yes
Continuous broadcast position source	Not inherently — ACARS messages vary	Core ADS-B feature
Global map as the primary product	No	Typically yes

The historically interesting point is that ACARSd implemented the distributed-receiver / Internet-sharing model years before crowd-sourced ADS-B tracking became mainstream.

Next: the evidence-based timeline →