Repository navigation
Surface chipset-specific driver hint when a USB adapter fails to bind - #101
Merged
Merged
Conversation
When 'iw dev' shows no interface after USB passthrough, look up the passed-through device's VID:PID in ChipsetDb and include the chipset name, driver, and notes in the DRIVER MISSING message instead of a generic hint.
There was a problem hiding this comment.
🟡 Changes recommended
Correct device attachment and Wi-Fi filtering, and avoid duplicate punctuation in generated hints.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
This PR adds chipset-specific driver hints to the USB Wi-Fi DRIVER MISSING log.
Changes:
- Looks up recognized devices in
ChipsetDb. - Appends chipset, driver, and installation notes.
- Preserves the existing message for unknown devices.
File summaries
| File | Summary |
|---|---|
app/src/main/java/com/zalexdev/stryker/engine/RootlessEngine.java |
Adds chipset-aware hints to the missing-driver log. |
Review details
Suppressed comments (1)
app/src/main/java/com/zalexdev/stryker/engine/RootlessEngine.java:829
pickWifiDevices()treats any vendor-specific USB interface as a Wi-Fi candidate, whileChipsetDbalso contains Ethernet entries such as RTL8152/RTL8153. Without checkinginfo.kind, a vendor-specific Ethernet dongle can be described in a Wi-FiDRIVER MISSINGmessage with the wrong remediation; only append entries whose kind isWIFI.
if (info == null) continue;
- Files reviewed: 1/1 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
- Only describe devices actually passed through (usb.isAttached). - Only append entries whose ChipsetInfo kind is WIFI (don't describe Ethernet/broadband dongles in a Wi-Fi error). - Add the trailing period only when the hint doesn't already end with one.
zalexdev
added a commit
that referenced
this pull request
Oct 3, 2026
Two files needed hands; the rest merged as-is. RootlessEngine: #101 added chipsetDriverHint() in the same place the dialogs refactor put the javadoc and @OverRide on usb(). Both kept. WiFIAdapter, handshake attack: took our side, which no longer declares the `clients` list the refactor removed, plus #92's !isInternalDeauthEnabled() guard. WiFIAdapter, type 7: #92 patched the old outputtext version of this block, which our side had already rewritten against AttackMonitor. Reapplied the intent -- the internal radio is refused only while the toggle is off, and the refusal now names the setting instead of claiming the hardware cannot inject.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a USB Wi-Fi adapter is passed through to the guest VM but no driver binds
(
iw devreturns no interface), the app logs a generic message that doesn'ttell the user which chipset failed or what driver/firmware to install:
The chipset database (
ChipsetDb) already holds the exact driver and installnotes for each supported VID:PID — it just isn't surfaced on this failure path.
Fix
On the DRIVER MISSING path, look up the passed-through device's VID:PID in
ChipsetDband append a hint with the chipset name, driver, and the databasenotes. Unknown VID:PIDs are left unchanged.
Example for a Realtek RTL8812AU (
0bda:8812) on a pre-6.14 guest kernel:Test plan
ChipsetDbentry) with its driver absent: theDRIVER MISSING line now names the chipset + driver + notes.
Log-only change; no functional behavior is altered.