Revert PR #5: 11.19.602.2025 is the current NetAdapterCx driver, not stale#6
Conversation
…le-driver pick" This reverts the changes merged in PR #5 (merge commit 0f18b5f). Its premise was disproven: 11.19.602.2025 is NOT a stale 2016 generic NDIS driver — it is the CURRENT Realtek USB NetAdapterCx family driver. Verified by extracting the live catalog package: - binaries rtucx22x64.sys (PE32+ x86-64) and rtucx22arm64.sys (PE32+ ARM64); "rtucx" = Realtek USB NetAdapterCx - CAB packaged 2025/08 on the catalog CDN; the DriverVer 03/30/2016 is cosmetic - INF explicitly binds USB\VID_0BDA&PID_8157 AND PID_815A across all REV codes, in both [Realtek.NTamd64] and [Realtek.ntarm64] - the catalog serves it in x64 AND ARM64 (ARM64 updateid 7da54d16-6faf-4214-b869-93f53467a9e1) The MinVersion='1157'/'1159' floor skipped exactly that driver, shipping nothing for 8157/8159 and dropping the only ARM64 driver available for them. The pre-PR behavior (selecting 11.19.602.2025) was correct; RTL8126/8127 were never a bug. Tests: 81 passed / 0 failed (post-#4 baseline restored). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes the MinVersion floor filtering logic from the driver catalog scraping engine, along with its associated configuration, tests, and manifest reporting. The driver selection mechanism now relies on selecting by the highest version (using the date as a tiebreaker) rather than filtering out legacy drivers via a minimum version floor. I have no feedback to provide as there are no review comments.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
1 participant
Reverts #5 — it was based on a disproven premise
PR #5 added a
MinVersionfloor that skipped11.19.602.2025for RTL8157/8159, on the belief it was an ancient 2016 generic NDIS driver. That belief was wrong. I downloaded and extracted the actual catalog package:rtucx22x64.sys(PE32+ x86-64) andrtucx22arm64.sys(PE32+ ARM64) —rtucx= Realtek USB NetAdapterCx.../drvs/2025/08/...); theDriverVer 03/30/2016is cosmeticUSB\VID_0BDA&PID_8157andUSB\VID_0BDA&PID_815Aacross all REV codes (3000–30FF), in[Realtek.NTamd64]and[Realtek.ntarm64]7da54d16-6faf-4214-b869-93f53467a9e1)So
11.19.602.2025is the current, signed, NetAdapterCx family driver for these chips — and the only one with ARM64. TheMinVersion='1157'/'1159'floor skipped exactly that, shipping nothing for 8157/8159 and dropping their only ARM64 driver. The pre-PR behavior (selecting11.19.602.2025) was correct.RTL8126/8127 were never a bug either: the engine already selects their newest catalog driver; they trail 8125/8168 only because Realtek hasn't pushed those niche parts past rel-27 yet (the catalog will likely backfill, since 8125/8168 already carry the rel-29 build from the same Feb-2026 release).
What this restores
MinVersionfeature, therealtek.psd1floors, and the related tests/comment — a clean inverse of Realtek: per-device MinVersion floor; fix RTL8157/8159 stale-driver pick #5.11.19.602.2025(x64; ARM64 with-Architecture arm64/all).Tests: 81 passed / 0 failed (post-#4 baseline).
🤖 Generated with Claude Code