Base Module • Proof of Concept

Ghost Fleet Signal

Beacon-only Wi-Fi decoys designed to be visible, fictional, and unreachable. Ghost Fleet Signal is a Linux demonstrator for experimenting with rotating SSID apparitions and hostapd-backed access-point behavior without providing a usable network behind the signal.

Release ClassProof of Concept

PlatformLinux / PySide6

Backendhostapd + nl80211

Network ServiceNone by Design

Demonstrator Only

This release is a base module and proof-of-concept application. It is not wired into an operational network stack, authentication service, captive portal, DHCP server, routing layer, monitoring backend, or external control system. It exists to demonstrate controlled beaconing, SSID rotation, hardware capability checks, and the user interface model.

Ghost Fleet Signal 0.1.7 Source

Complete source package. All project files included.

Download 0.1.7 SRC

Concept

A fleet made of signals, not destinations.

Ghost Fleet Signal creates fictional Wi-Fi identities that can appear on nearby client devices while deliberately refusing to become a functioning network. Apparition Mode can retire one identity and replace it with another over time.

Generate

Create fictional SSIDs from several naming personalities including mixed, industrial, boring, cryptic, and fully randomized patterns.

Broadcast

Use Linux hostapd and nl80211 to place a compatible dedicated Wi-Fi radio into AP mode and advertise the staged ghost identity.

Vanish

Apparition Mode rotates the active identity on a configurable interval, preserving a local history of which SSIDs appeared and how long they remained active.

What the base module does

Detects Linux wireless interfaces
Checks advertised AP capability
Generates fictional SSID identities
Starts a beacon-only hostapd configuration
Rejects client association attempts
Supports timed SSID rotation
Shows live state, age, next rotation, and history
Runs from the tray when the main window is closed

What it intentionally does not do

No deauthentication frames
No cloning of nearby legitimate SSIDs
No credential collection
No DHCP or Internet routing
No captive portal
No transparent interception
No payload traffic collection
No promise of operational or production suitability

Hardware Compatibility

One radio is not automatically one fleet.

Multiple SSIDs at the same time require more than basic AP mode. The chipset, Linux driver, firmware, and reported valid interface combinations all have to permit multiple AP virtual interfaces.

Important: none of the hardware below has been tested with Ghost Fleet Signal by this project. This is a research shortlist based on Linux driver documentation and manufacturer chipset information. Treat every item as a candidate until iw list proves the actual adapter/driver/firmware combination supports the required number of AP interfaces.

Hardware / Class	Chipset / Driver	Form	Why it is interesting	Ghost Fleet Status
Compex WLE900VX	Qualcomm QCA9880 / ath10k	Mini PCIe, 3×3, 3 × U.FL	Strongest research target. Linux Wireless explicitly documents ath10k multiple-BSSID operation with several virtual APs, and Compex documents the WLE900VX as QCA9880 with Linux/OpenWrt ath10k use.	Priority Candidate
Compex WLE600VX	Qualcomm QCA9882 / ath10k	Mini PCIe, 2×2, 2 × U.FL	Same ath10k family with a 2×2 radio. Manufacturer documentation specifically identifies QCA9882 and ath10k/OpenWrt support.	Priority Candidate
QCA9880 / QCA9882 ath10k modules	Qualcomm Atheros / ath10k	Typically Mini PCIe	The driver family itself has documented mBSSID support. Exact card, firmware, regulatory domain, and platform still matter.	Driver-Level Candidate
AR9380 / AR9382 / AR9580 class cards	Qualcomm Atheros / ath9k	PCIe / Mini PCIe	ath9k has mature in-kernel AP support across these chip families and is historically friendly to mac80211 virtual-interface workflows. Exact simultaneous-AP limits must still be read from the installed radio.	Strong Candidate
AIRETOS AEX-AR9580-NX / AR959x family	AR9580 / AR9590 / AR9592, ath9k	Full Mini PCIe	Linux Wireless lists these as external ath9k products. They are useful examples of discrete Atheros radios where the kernel driver, rather than a vendor USB stack, controls AP behavior.	Legacy Candidate
ALFA AWUS036ACM	MediaTek MT7612U / mt76	USB, dual-band	Very good modern Linux compatibility and mainline kernel support. However, the sources reviewed here do not establish a guaranteed multi-BSS count for this exact USB adapter.	Investigate First
ALFA AWUS036NHA	Atheros AR9271 / ath9k_htc	USB, 2.4 GHz	Excellent Linux support, but Linux Wireless specifically describes AP/P2P as experimental for ath9k_htc and says using one AP VIF is a good idea because multiple-interface support has not been extensively tested.	Not a Multi-AP Pick

Antennas for discrete cards

Antennas do not create multi-AP capability. That comes from the radio, firmware, and driver. For a discrete Mini PCIe module, match the antenna system to the number of RF chains:

WLE600VX: two U.FL pigtails and two matched antennas
WLE900VX: three U.FL pigtails and three matched antennas
For the current 2.4 GHz Ghost Fleet build, use antennas rated for 2.4 GHz
Dual-band 2.4/5 GHz omnidirectional antennas are useful if future builds add 5 GHz
Low to moderate gain omnidirectional antennas are the sensible general-purpose starting point

What to avoid assuming

“Supports AP mode” does not mean “supports several AP interfaces”
A chipset name alone does not guarantee the same firmware limits on every product
USB adapters are not inherently better or worse, but vendor drivers can complicate virtual-interface behavior
A high-gain antenna does not increase the number of BSSIDs a radio can expose
Marketing claims such as monitor mode or injection support say nothing about multi-BSS capability

The Test That Matters

Ask the kernel what the radio can actually do.

iw list

Look under:
valid interface combinations:

A useful multi-AP radio may report something conceptually similar to:
#{ AP } <= 4

A one-ghost radio may instead report:
#{ AP } <= 1

Ghost Fleet Signal performs its own capability check before launch. If the installed adapter reports only one simultaneous AP interface, the application can still operate as a single rotating apparition, but it cannot create several concurrent SSIDs on that radio.

Operation

Small surface. Clear state.

The proof-of-concept is intentionally narrow. The application stages identities, hands a dedicated radio to hostapd, verifies AP state, and rotates the identity when Apparition Mode is enabled.

Dedicated radio

Ghost Fleet refuses to take over a Wi-Fi interface that is already being used as a client connection. A dedicated radio is the intended configuration.

Single authorization

Privileged radio setup is handled through a controlled helper session so normal operation does not become a cascade of repeated authorization prompts.

Tray persistence

Closing the main window hides it while the application continues running. The tray menu is the deliberate path for returning to the interface or exiting the process.

Current software requirements

Linux with nl80211/mac80211-compatible wireless support
Python 3
PySide6
hostapd
iw
PolicyKit / pkexec for controlled privileged radio setup

Current radio model

The present proof-of-concept is centered on 2.4 GHz hostapd operation using channels 1–11. Hardware capable only of 5 GHz operation is not a suitable target for this build without additional application changes.

The application can stage up to several ghost identities, but the effective simultaneous fleet size is ultimately capped by what the selected Linux radio reports as a valid AP interface combination.

Design Boundary

Visible does not mean accessible.

Ghost Fleet Signal is built around a simple line: advertise a fictional access point identity, then stop. The proof-of-concept intentionally avoids the mechanisms that would turn a decoy beacon into credential collection or active interference.

Use only where you are authorized to operate radio equipment.

Wireless spectrum, transmit power, channels, antenna systems, and access-point operation are subject to local regulations and site policy. The software does not grant authority to transmit, interfere with other networks, impersonate third parties, or bypass applicable rules.

Hardware Research Notes

Why these radios made the shortlist.

The hardware table above is not a compatibility certification. It is a starting point assembled from Linux Wireless driver documentation and manufacturer chipset documentation. Ghost Fleet testing still has the final word.

Linux Wireless: ath10k configuration and documented mBSSID / virtual AP operation Linux Wireless: ath9k supported chipsets and AP mode support Linux Wireless: external products using ath9k chipsets Linux Wireless: ath9k_htc AP/P2P notes and multiple-interface caution Compex: WLE900VX QCA9880 module specifications Compex: WLE600VX QCA9882 module specifications ALFA: MT7612U / AWUS036ACM Linux support information ALFA: AR9271 / AWUS036NHA Linux support information