Hardware identification gaps

Generated by scripts/gen_hardware_gaps.py. Do not edit by hand — regenerate.

Generated: 2026-10-05
Devices in catalog: 34 — 15 fully characterised, 19 with something still unknown

Of those 34, 24 carry at least one confirmed USB identifier of their own and 7 have been run on hardware here (D-027: two different claims).

A device whose USB identifier is guessed produces a udev rule that silently never matches, which an operator cannot distinguish from a bad cable. So the catalog refuses to guess, and every gap is recorded here instead — with the one fact that decides whether it is anyone's work item: who is in a position to close it.

When these actually have to be closed

Short answer: none of them today. hammunition hardware apply consumes confirmed identifiers only and refuses to write a rule on a guessed one (a rule that never matches is indistinguishable from a bad cable), so an open gap costs the device its own rule and nothing else: apply names the omission and moves on, and the class rules still cover what they cover. What follows is what each gap withholds, and when that starts to matter.

Device	Closure	Blocks	Until then
btech-uv-50pro	maintainer_hardware	?	Not assessed.
catsniffer-v3	maintainer_hardware	M4	Covered by the badgelife class rules in the meantime, which is the point of having a class. Blocks only a pinned per-device symlink.
dell-dw5930e	maintainer_hardware	?	Not assessed.
free-wili-2	maintainer_hardware	M4	Not asserted to be USB-serial at all, so the class is a guess rather than a cover. Worth an early lsusb for that reason alone.
orbic-rc400l	maintainer_hardware	?	Not assessed.
proxmark3	maintainer_hardware	Q-010 / M4	The anchor device for the proposed rfid profile. The profile can be decided without it, but cannot claim supported for its only hardware, and the client needs the source backend regardless.
yaesu-ft-991a	maintainer_hardware	?	Not assessed.
flipper-zero	unverified_by_maintainer	?	Not assessed.
fobos-sdr	unverified_by_maintainer	?	Not assessed.
hydrasdr-rfone	unverified_by_maintainer	?	Not assessed.
krakensdr	unverified_by_maintainer	nothing	Usable now through the confirmed RTL-SDR identifiers. Only a board-level control rule is missing, and nothing needs one.
librevna	unverified_by_maintainer	an owner's lsusb	Not owned. Its three identifiers are read from upstream's source at v1.6.5, so no rule is generated until one is seen on hardware; until then the program reaches the device only with access granted some other way. Nothing else in the catalog waits on it.
limesdr	unverified_by_maintainer	post-1.0	No SDR in the 1.0 profiles depends on it.
meshtastic	unverified_by_maintainer	nothing	Identifiers closed from upstream board metadata covering 107 products (docs/reference/lora-inventory.md). What is left is per-board product STRINGS, which no upstream source records because a flasher does not need them — a contribution ask for anyone owning a node.
plutosdr	unverified_by_maintainer	post-1.0	Its Soapy module is sid-only, so apt cannot install it on a stable base — the packaging gap blocks this device well before the identifier does.
portapack-h4m	unverified_by_maintainer	post-1.0	Planned, not owned, and it may never warrant an identifier of its own — it is an add-on the host sees through the HackRF beneath it. The right record may turn out to be a note on that entry instead.
rnode	unverified_by_maintainer	nothing	Closed from upstream's board lists (Reticulum's manual and RNode_Firmware's Boards.h, read 2026-10-03), which name boards and no USB identifier. A board enumerates as its base module, which the badgelife class already covers. What is left is what a provisioned RNode reports in its strings: a contribution ask for anyone owning one.
sdrplay-rsp	unverified_by_maintainer	M4	The recorded Mirics identifiers work for the open driver. What is unverified is the vendor-API path, which is post-1.0 anyway.
uconsole	not_applicable	nothing	Not a USB peripheral; there is nothing to record.

nothing means the device is usable as catalogued and the gap is a completeness item. M4 means it blocks the device's own udev rule or pinned symlink and nothing sooner. Only one gap blocks a decision rather than an implementation, and even that one is a claim of support, not the decision itself.

Device	Status	What is missing
btech-uv-50pro	untested	The UV-50PRO cannot be identified on USB because it has none.
catsniffer-v3	supported	The host-side identifier is confirmed, and it identifies an RP2040 rather than a CatSniffer.
dell-dw5930e	untested	No USB identifier exists to carry: the card is PCIe/MHI.
free-wili-2	supported	Narrowed to one thing, and it is now a named field rather than a paragraph.
orbic-rc400l	untested	The identifiers below come from upstream's installer source, not from this device on a bench: EFForg/rayhunter installer/src/orbic.rs (commit 15630ed9c7ac, 2026-09-10) waits for 05c6:f601 and opens 05c6:f626, and speaks to both directly over USB (nusb).
proxmark3	supported	Narrowed sharply, and what remains is a real limitation rather than missing work.
yaesu-ft-991a	untested	Not captured from this radio on a bench.
flipper-zero	supported	One identifier from Debian's rule is deliberately NOT carried above: 0483:df11, the device's DFU mode.
fobos-sdr	untested	Not owned, so no descriptor has been read.
hydrasdr-rfone	supported	Not owned, so no descriptor has been read.
krakensdr	untested	Not separately identified.
librevna	untested	The three identifiers this entry carries are the ones upstream's GUI accepts as a LibreVNA (librevnausbdriver.cpp at v1.6.5) and the three its own udev rule names; which one a given unit presents, by hardware revision and firmware, has not been seen on a bench here.
limesdr	supported	Narrowed again, still not closed.
meshtastic	supported	Not closable as a single record, and now for a documented reason rather than an unexplored one.
plutosdr	untested	No USB identifier confirmed, and the maintainer does not own the hardware to confirm one.
portapack-h4m	planned	Nothing confirmed, and the shape of what is unknown is itself unusual.
rnode	untested	RNode is firmware, so it has no USB identifier of its own, and upstream's board list (Boards.h in RNode_Firmware, and Reticulum's manual) names boards but no VID:PID, so no identifier can be taken from it without a capture.
sdrplay-rsp	untested	The identifiers above are Mirics silicon as recorded by Debian's libmirisdr4, which the open libmirisdr driver targets.
uconsole	planned	Not a USB peripheral.

Closable on the maintainer's bench — 7

The hardware is in the kit. One lsusb closes each of these and no contribution is needed — do not solicit one.

scripts/identify-device.sh <name> captures what is needed and prints a block ready to paste into the manifest. It is read-only, needs no root, and reports a device that does not enumerate as a finding rather than as a failure:

scripts/identify-device.sh btech-uv-50pro
scripts/identify-device.sh catsniffer-v3
scripts/identify-device.sh dell-dw5930e
scripts/identify-device.sh free-wili-2
scripts/identify-device.sh orbic-rc400l
scripts/identify-device.sh proxmark3
scripts/identify-device.sh yaesu-ft-991a

btech-uv-50pro

BTECH UV-50PRO — dual-band mobile with no CAT, keyed through an external interface

The UV-50PRO cannot be identified on USB because it has none. What the bench must record, through whichever interface is used on it (D-073 §3d): (1) which control line keys it — RTS or DTR — and that the other line does nothing; (2) that nothing is sent on the serial line itself — strace -f -e trace=write,ioctl on the running rigctld shows only line ioctls on the port and no write to it; (3) whether starting the service keys the radio even briefly, because opening a tty raises RTS and DTR before hamlib sets them; (4) that VOX keys it as the alternative, with the audio level that does it.

catsniffer-v3

Electronic Cats CatSniffer v3 — multiprotocol sub-GHz, BLE and 802.15.4

The host-side identifier is confirmed, and it identifies an RP2040 rather than a CatSniffer. What is NOT established is whether a differently flashed CatSniffer v3 presents something else -- the board's USB identity comes from its firmware, so a unit running the vendor image rather than an Arduino-core build may differ. Captures from other units, or from this one after reflashing, would settle it.

dell-dw5930e

Dell DW5930e — 5G modem on PCIe/MHI, a documented gap for parking with the radio switch as the way to quiet it

No USB identifier exists to carry: the card is PCIe/MHI. The catalog's identifier model is USB-only, so the PCI identifier (105b:e0b1, recorded by the maintainer's bring-up notes when the card was fitted on 2026-09-21) is prose here, not a field, and was not re-read on 2026-10-01 because the card is not in the machine at the moment; the DW5821e is. Closing this needs the card back in the machine and lspci -nn plus a decision on a PCI identifier model, which is the maintainer's.

free-wili-2

Free-WiLi 2 — multi-function hardware-hacking tool presenting six USB devices

Narrowed to one thing, and it is now a named field rather than a paragraph. Every identifier is confirmed against hardware, but 093c:2059 presents four CDC ACM ports and port_roles on it is empty because which port carries which function is not known here. Naming one of them /dev/free-wili would be a coin toss, and /dev/serial/by-id/ gives all four a stable path while labelling none of them — a stable path to a port you cannot identify is not an answer. Upstream documentation or a functional test settles it; the schema will then take four names in order, and it takes four or none, because a partial map reads as a complete one.

orbic-rc400l

Orbic RC400L (also Kajeet RC400L) — the mobile hotspot Rayhunter's IMSI-catcher detector runs on

The identifiers below come from upstream's installer source, not from this device on a bench: EFForg/rayhunter installer/src/orbic.rs (commit 15630ed9c7ac, 2026-09-10) waits for 05c6:f601 and opens 05c6:f626, and speaks to both directly over USB (nusb). Neither has a product string on record here, and 05c6 is Qualcomm's vendor id used by every Qualcomm-based reference design, so a rule on the bare pair over-matches other Qualcomm hotspots and modems. The maintainer owns a Rayhunter unit: one scripts/identify-device.sh run with it attached closes this with the product and serial strings, and the rule then matches on them (D-028). The TP-Link M7350/M7310 route is not USB-identified in the installer at all and gets no entry until one is measured.

proxmark3

Proxmark3 v3 and v5 — RFID and NFC research tool (RDV4 not covered)

Narrowed sharply, and what remains is a real limitation rather than missing work. The operating-mode identifier is confirmed. What is NOT established: Whether the v3 and v5 boards differ at all in their descriptors. Both captures returned identical output, which suggests they do not, but the two runs cannot be attributed to two specific boards with confidence from the record kept. The bootloader identifier. A Proxmark enumerates differently while its bootloader is running, and that was not captured -- it needs the button held during attachment. Whether any firmware variant supplies a serial. The stock build does not, and if some variant does, that changes the story above completely: a serial would restore /dev/serial/by-id/ as the answer.

yaesu-ft-991a

Yaesu FT-991A — HF/VHF/UHF all-mode transceiver with a built-in USB CAT and audio interface

Not captured from this radio on a bench. What one scripts/identify-device.sh run with the FT-991A attached must record, to close this and let the entry become composite with measured strings: the two CP2105 serial ports' product strings (which -ifNN- is the Enhanced/CAT port and which is the Standard/PTT port — Yaesu's documentation says CAT is the Enhanced port, unmeasured here), whether the CP2105 reports a per-unit serial (reports_serial, the value never recorded, only whether), and the USB audio codec's identifier (a TI/Burr-Brown codec per docs/guides/audio-routing.md, identifier not measured).

Unverified by the maintainer — 11

Carried because other operators have the device; the maintainer does not, so the gap cannot be closed here. This is deliberate, not a backlog — the entries stay and stay honest about why. lsusb output from an owner closes any of them.

scripts/identify-device.sh <name> captures what is needed and prints a block ready to paste into the manifest. It is read-only, needs no root, and reports a device that does not enumerate as a finding rather than as a failure:

scripts/identify-device.sh flipper-zero
scripts/identify-device.sh fobos-sdr
scripts/identify-device.sh hydrasdr-rfone
scripts/identify-device.sh krakensdr
scripts/identify-device.sh librevna
scripts/identify-device.sh limesdr
scripts/identify-device.sh meshtastic
scripts/identify-device.sh plutosdr
scripts/identify-device.sh portapack-h4m
scripts/identify-device.sh rnode
scripts/identify-device.sh sdrplay-rsp

flipper-zero

Flipper Zero — multi-protocol handheld for sub-GHz, NFC, RFID, infrared and iButton

One identifier from Debian's rule is deliberately NOT carried above: 0483:df11, the device's DFU mode. It is STMicroelectronics' generic STM32 bootloader identifier, shared by every STM32 board in DFU — including, as the same sweep found, the TYT MD-UV380 radio in dmrconfig's rule. A udev symlink on it would name an unrelated device /dev/flipper. The normal and U2F identifiers are carried, and they are ambiguous too: 0483:5740 is usb.ids' "Virtual COM Port", ST's reference identifier, reused by a wide range of STM32 projects that never changed it. So this entry emits no symlink at all. What would fix that is one ATTRS{product} string, which the device almost certainly supplies and nobody here has read -- run scripts/identify-device.sh flipper-zero and it turns three ambiguous identifiers into one safe rule.

fobos-sdr

RigExpert Fobos SDR -- a USB wideband receive-only SDR

Not owned, so no descriptor has been read. Unknown: the manufacturer and product strings and whether the board reports a per-unit serial; whether the agile firmware's bcdDevice (0x0101) and the original's (0x0000) are the only two a unit shows; and every behaviour past enumeration. The firmware difference is visible only in bcdDevice, which this catalog's udev binding cannot match on, so one rule serves both. Closing it needs a Fobos attached from an owner, once on each firmware if they have both; scripts/identify-device.sh fobos-sdr does it read-only, no root.

hydrasdr-rfone

HydraSDR RFOne -- a USB receive-only SDR, successor to the Airspy host design

Not owned, so no descriptor has been read. Unknown: the manufacturer and product strings and whether the board reports a per-unit serial (the vendor's rule matches VID:PID only, so a rule that tells two RFOnes apart, or an RFOne from an Airspy on the legacy identifier, has nothing to match on); whether a board still on legacy firmware exists in the field; and every behaviour past enumeration. Closing it needs an RFOne attached, in normal mode, from an owner; scripts/identify-device.sh hydrasdr-rfone does it read-only, no root.

krakensdr

KrakenSDR — five coherent RTL-SDR receivers for direction finding

Not separately identified. KrakenSDR is five RTL2832U receivers on one board, so each channel enumerates with the ordinary RTL-SDR identifiers already confirmed in the rtl-sdr entry (0bda:2838). What is NOT confirmed is whether the board exposes any additional control interface with its own identifier. The per-channel rules work regardless; only a board-level rule is unverified. The maintainer does not own one, so this needs lsusb output from an owner — a low-value gap, since the device is usable without it.

librevna

LibreVNA — open-hardware two-port vector network analyser, 100 kHz to 6 GHz, over USB

The three identifiers this entry carries are the ones upstream's GUI accepts as a LibreVNA (librevnausbdriver.cpp at v1.6.5) and the three its own udev rule names; which one a given unit presents, by hardware revision and firmware, has not been seen on a bench here. The maintainer does not own one, so closing this needs lsusb output from an owner. Upstream's LibreCAL calibration kit is a separate device (0483:4122, 1209:4122) and is not carried.

limesdr

LimeSDR USB and Mini — full-duplex transmit-capable SDR

Narrowed again, still not closed. 1d50:6108 is the full-size LimeSDR-USB: an owner's capture said so in the product string (issue #30, 2026-09-05), and it presents no serial device, only the libusb node. What remains is the Mini: 0403:601f comes from Debian's rule alone and no Mini owner has reported yet, so whether current Mini revisions still present it is unknown. The maintainer owns neither board; a Mini owner running scripts/identify-device.sh limesdr would close the rest.

meshtastic

Meshtastic LoRa nodes — T-Deck, T-Echo, RAK and WisMesh boards

Not closable as a single record, and now for a documented reason rather than an unexplored one. The identifiers are confirmed from upstream board metadata covering 107 products; what no upstream source records is the manufacturer and product STRINGS a running board reports, because a flasher matches on VID:PID and never needs them. Those strings are the only thing that could make a per-board udev rule safe. So the remaining work is per-board captures, and it is a contribution ask rather than a task: the maintainer's boards were lost to flooding, and anyone with a T-Deck, a T-Echo, a RAK or a Heltec can close one board's worth in thirty seconds with scripts/identify-device.sh.

plutosdr

ADALM-Pluto — inexpensive full-duplex learning and development SDR

No USB identifier confirmed, and the maintainer does not own the hardware to confirm one. The entry is carried anyway because other operators do. The Pluto presents as a composite device — USB networking, mass storage and serial — and which interfaces appear depends on the firmware revision, so a single VID:PID does not describe it in the first place. No Debian package here shipped a matching udev rule. Closing this needs lsusb output from someone holding the board, tagged with its firmware revision.

portapack-h4m

PortaPack H4M — add-on board giving a HackRF a screen, controls and standalone operation

Nothing confirmed, and the shape of what is unknown is itself unusual. The PortaPack is an add-on board rather than a peripheral: the host generally sees the HackRF it is attached to, so this entry may or may not warrant its own USB identifier at all. Whether the combined device enumerates as the HackRF, as something distinct, or differently again while its own firmware is being updated, is not established here. The maintainer does not own one. Closing this needs lsusb output from an owner in each of those states, and the answer may be that the right record is a note on the HackRF entry rather than an identifier here.

rnode

RNode, Reticulum's LoRa transceiver firmware, on the LilyGO, Heltec and RAK boards it supports

RNode is firmware, so it has no USB identifier of its own, and upstream's board list (Boards.h in RNode_Firmware, and Reticulum's manual) names boards but no VID:PID, so no identifier can be taken from it without a capture. A board presents the identifiers of its base module, which the badgelife class and the meshtastic entry already carry as ambiguous. What no source records is what a provisioned RNode reports in its manufacturer and product strings, which is the only thing that could make a per-board rule safe.

sdrplay-rsp

SDRplay RSP series — receive-only SDR needing a closed-source vendor API

The identifiers above are Mirics silicon as recorded by Debian's libmirisdr4, which the open libmirisdr driver targets. Current RSP models under SDRplay's own API may enumerate differently and that has NOT been verified. The maintainer does not own an RSP, so confirming it needs lsusb output from an owner, per model — RSP1A, RSPdx and RSPduo should each be recorded rather than assumed to share a pair.

Not closable, and should not stay on a list — 1

No single identifier exists to record. lsusb against one unit would not close these, so leaving them as open tasks would keep them permanently open.

uconsole

ClockworkPi uConsole — portable handheld Linux terminal used as a field radio host

Not a USB peripheral. The uConsole is a host computer, so it has no VID:PID to record and does not fit the device model the rest of this catalog uses. It is here because its display, audio routing and power management need configuration that no ham or SDR project ships, and because the Hacker Gadgets AIO expansion board attached to it may present USB devices that do need entries. None of that has been characterised here. It is also the one device Hammunition may build an image for (D-084, epic #372): first a documented route from a stock CM4 uConsole to Debian 13 and hammunition install uconsole, and an image only if that route cannot be written.

Recorded but unconfirmed identifiers — 5

These are different from the gaps above: an identifier is recorded and rules are generated from it, but it rests on documentation rather than on an lsusb capture. Each carries its provenance, and confirming one is a smaller job than filling a gap — the pair either matches attached hardware or it does not.

Where	VID:PID	What it is	Provenance
device librevna	0483:4121	LibreVNA, on STMicroelectronics' vendor identifier	Upstream source at tag v1.6.5, librevnausbdriver.cpp, and upstream's own udev rule. Vendor 0483 is STMicroelectronics; usb.ids names no product 4121 under it, and no archive rule names the pair, so there is no evidence here of another product presenting it. Unconfirmed here: not captured from hardware.
device librevna	0483:564e	LibreVNA, the original identifier	Upstream source at tag v1.6.5, first in librevnausbdriver.cpp's list of valid identifiers, and upstream's own udev rule. Vendor 0483 is STMicroelectronics; usb.ids names no product 564e under it, and no archive rule names the pair. Unconfirmed here: not captured from hardware.
device orbic-rc400l	05c6:f601	Orbic RC400L in its normal composition, as the installer waits for it	EFForg/rayhunter installer/src/orbic.rs L45-46 at 15630ed9c7ac: const VENDOR_ID: u16 = 0x05c6; const PRODUCT_ID: u16 = 0xf601;, used by wait_for_usb_device(). Not in usb.ids on Parrot 7.3 (05c6 lists no f601). Unconfirmed here: not captured from hardware, not yet seen on a bench here.
device orbic-rc400l	05c6:f626	The composition the installer opens on the device (open_usb_device(VENDOR_ID, 0xf626))	EFForg/rayhunter installer/src/orbic.rs L496 at 15630ed9c7ac. Same caveats as f601. Unconfirmed here: not captured from hardware, not yet seen on a bench here.
device librevna	1209:4121	LibreVNA	Upstream source at tag v1.6.5: Software/PC_Application/LibreVNA-GUI/Device/LibreVNA/librevnausbdriver.cpp lists it as a valid LibreVNA identifier, and upstream's own udev rule beside the GUI source grants it. pid.codes allocates 1209:4121 to LibreVNA (its registry entry names the project and the repository). Unconfirmed here: not captured from hardware.

Considered and rejected — 7

Identifiers this catalog looked at and does not carry. They live in rejected_ids, which cannot generate a udev rule and cannot be inherited by a device, because the alternative is deleting the finding and having somebody re-add it from the same source next year.

Where	VID:PID	Assumed to be	Why not carried
class gps-receiver	0403:6001	The identifier of a GPS receiver behind an FTDI cable, which some are.	Disabled by Debian in the shipped rule with the comment "rule disabled in Debian as it matches too many other devices". This is the identifier on most rig-control cables, and gpsd's rule does not merely name a device -- it sets ENV{SYSTEMD_WANTS}="gpsdctl@%k.service", so a match starts gpsd on the port. Carried, it would hand an operator's CAT cable to the GPS daemon. The same pair is disabled again in argyll's rules.
class dmr-radio	0483:df11	A TYT MD-UV380 being programmed — which it genuinely is, since that radio is programmed in the STM32 bootloader and both qdmr and dmrconfig match this pair to reach it.	It is STMicroelectronics' generic DFU identifier, presented by every STM32 in the bootloader. This project already found it in qflipper's rules as a Flipper Zero and in dmrconfig's as a TYT radio, which is the finding D-028 was written from. It belongs under firmware on the entry for a radio the operator has chosen to flash, never in usb_ids where the kernel matches whatever is attached. The distinction is D-028's, and this is the third package to make it necessary.
class gps-receiver	067b:2303	A PL2303-based receiver. gpsd's file lists this pair TWICE, once for the generic PL2303 and once for a u-blox 8 GNSS mouse, and disables both.	Disabled by Debian for matching too many other devices — twice in the same file, which is as clear as a maintainer can be. The most widely cloned serial bridge there is.
class gps-receiver	10c4:ea60	A CP210x-based receiver — gpsd's comment names the Holux m241 and the Wintec grays2 wbt-201, both of which really do use one.	Disabled by Debian for matching too many other devices. Independently the same identifier this project's badgelife class had to stop claiming, for the same reason pointed the other way: it is the most common USB-serial bridge in existence and names a chip.
class gps-receiver	10c4:ea71	A CP210x-based receiver, as above.	Disabled by Debian for matching too many other devices. A four-port bridge chip; matching it would claim all four ports of any board using one.
class badgelife	1a86:55d4	The identifier a CH343-family board would present, on the strength of it being widely reported for the CH9102F across forum posts and vendor pages.	Not present in Debian 13 usb.ids and never confirmed against hardware here. When a CH343-family board was finally captured on 2026-08-26 -- a C5 Wardriver v1.1 -- it presented 1a86:55d3. One digit out. This is the last identifier this class will carry on report alone: a widely-reported pair is not evidence, and the rule it generates silently never matches, which an operator cannot tell from a bad cable. Kept as the worked example.
device hydrasdr-rfone	1d50:60a1	an RFOne in its legacy identifier (OpenMoko vendor, Airspy product)	Upstream's own tables list it for the RFOne ("Legacy VID/PID", the rules file's "uses historic OpenMoko VID 1d50"), and it is also the identifier of the Airspy R2 and Mini, which the airspy entry carries from Debian's libairspy0 rule. Nothing this entry can read separates the two boards on it, and a rule on it would name an Airspy an RFOne. Left to the airspy entry's rule, which gives the same group; recorded here so the next reader does not add it. Source: libhydrasdr/src/hydrasdr.c line 64 at the commit cited above.

---

Support and verification are two different claims

status says the identifiers and setup recipe are correct. maintainer_verified says somebody here plugged the hardware in. They answer different questions, and a device can honestly be the first without the second: usrp claims supported on the strength of Debian's own uhd-host udev rule, a primary source, while nobody on this project owns one.

Discarding that evidence for lack of hardware would throw away a real claim. Merging the two columns is how a project comes to claim support it has never tested. So they are separate fields and both are shown.

Device	Status	Run here	Evidence
airspy	supported	no	identifiers from a distribution rule; never run here
bladerf	supported	no	identifiers from a distribution rule; never run here
btech-uv-50pro	untested	no	-
c5-wardriver	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Flashed, attached and enumerated; identifier, product string and serial captured with scripts/identify-device.sh. Firmware output was confirmed over UART, so the board is running. Its screen did not display correctly, which is recorded as a known problem rather than a USB finding.
catsniffer-v3	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated; identifier, product string and serial captured with scripts/identify-device.sh. The radio side was not exercised and no firmware was flashed.
clip-boy	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated; identifier, product string and serial captured with scripts/identify-device.sh. Nothing was run and no firmware was flashed.
dell-dw5821e	untested	no	-
dell-dw5930e	untested	no	-
flipper-zero	supported	no	identifiers from a distribution rule; never run here
fobos-sdr	untested	no	-
free-wili-2	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated. All six USB devices captured with scripts/identify-device.sh, including vendor and product strings and serials. Nothing was run against the hardware and no firmware was flashed.
funcube-dongle	supported	no	identifiers from a distribution rule; never run here
hackrf-one	supported	no	identifiers from a distribution rule; never run here
hackrf-pro	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated in both normal and DFU modes; identifiers, product strings and serials captured with scripts/identify-device.sh. No /dev node is created in either mode, which is expected for a libusb device. Nothing was received or transmitted, and no firmware was read or written.
hydrasdr-rfone	supported	no	identifiers from a distribution rule; never run here
intel-ax210-bluetooth	untested	no	-
krakensdr	untested	no	-
librevna	untested	no	-
limesdr	supported	no	identifiers from a distribution rule; never run here
meshtastic	supported	no	identifiers from a distribution rule; never run here
minino	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated; identifier, product string and serial captured with scripts/identify-device.sh. The radio side was not exercised and no firmware was flashed.
orbic-rc400l	untested	no	-
plutosdr	untested	no	-
portapack-h4m	planned	no	-
proxmark3	supported	yes, 2026-08-26	ChiefGyk3D on Pop!_OS 22.04 - Attached and enumerated, twice, with scripts/identify-device.sh. Both captures returned the same identifier, no product string and no serial. The client was not built and no card was read.
rnode	untested	no	-
rtl-sdr	supported	no	identifiers from a distribution rule; never run here
sdrplay-rsp	untested	no	-
sunplus-integrated-webcam-fhd	untested	no	-
ubertooth-one	supported	no	identifiers from a distribution rule; never run here
uconsole	planned	no	-
usrp	supported	no	identifiers from a distribution rule; never run here
wi-spy	supported	no	identifiers from a distribution rule; never run here
yaesu-ft-991a	untested	no	-

19 of 34 devices claim supported; 7 have been run here. That gap is not a defect to be closed by relaxing either column. It is the honest state, and printing it is the point.

---

If you own one of these

Every gap above marked unverified_by_maintainer is closable by anyone holding the hardware, in about thirty seconds, and by nobody without it. scripts/identify-device.sh <name> is read-only, needs no root, and prints a block ready to paste — see contributing/hardware.md.

The catalog stores vendor and product identifiers only. Serial numbers are per-unit and are never recorded here.