CBTC Train Tracker (PoC)

Proof-of-concept pipeline for inferring train presence and approximate movement from open 802.11b CBTC traffic. This is intended for research/education and operates on observed network metadata rather than train control.

Warning

Use only on networks/systems you own or have explicit permission to test, and do not deploy on public transit or production CBTC systems. This PoC does not control trains; it only observes and infers from metadata.

Background

• The CBTC system in scope uses an unencrypted WiFi link between trains and wayside (using TrainGuard MT).
• Static IP assignments and repeatable UDP patterns provide fleet identifiers.
• ARP and beacon activity provide a coarse "active/nearby" signal.
• A simple timetable-based model helps convert sightings into estimated positions.

How It Works (High Level)

1. Capture 802.11 traffic from monitor mode or a .pcap file.
2. Extract signals:
   • IP-to-train mapping (static IPs)
   • UDP payload bytes to infer direction/head when present
   • ARP activity to mark active trains across the network (broadcast)
   • Beacon counts for AP stats
3. Report observations to the API server.
4. Store in MySQL and run heuristics to infer live positions.
5. Web UI renders live, history, and stats views.

Nearby vs Active Signal

• ARP packets are broadcast, so they provide a coarse view of trains that are active anywhere on the network.
• Other data packets are point-to-point, so they tend to show up only when a train is nearby.
• This lets the PoC compare "active system-wide" vs "nearby to the sniffer."

Payload Visibility

I believe the packet payloads are meaningfully encrypted (possibly AES), so this PoC does not attempt to decode train control data beyond metadata-level hints.

Repo Layout

• client/ Python sniffer + reporter (Scapy, multiprocessing, HTTPX).
• main.go Go HTTP API and web host (Fiber).
• db_query.go/db_report.go MySQL storage and inference helpers.
• sql.md Database schema.
• web/ Vue frontend.

Data Flow

packet capture -> client queue -> /report/* -> MySQL -> /query/* -> web UI

Notes & Limitations

• Positions are inferred, not GPS-accurate.
• Accuracy depends on signal visibility and timetable assumptions.
• Heuristics are tuned to a specific line and will need adaptation elsewhere.