September 22Sep 22 The project has turned out to be a gem. I can retire Joshua Riek Fork I am calling it Pi Desktop 3.0 Plaid (Not live yet... expect a week of soak). They should take and call it Armbian Rockchip Resolute The combination Pi Claude called the make-or-break unknown this morning — a 26.04 userland has no business running on a 2023-era Rockchip BSP kernel, but it does: Chromium/Chrome Hardware acceleration with no web rendering flickering. Firefox runs everything but 8 bit HEVC... so far 26.04 / GNOME 50.1, mutter 50.1, Mesa 26.0.8 libmali G610 g24p0 (newest G610 blob that exists) on kbase g29p1 rockchip-linux/mpp 2026-08-05 snapshot (yisding's resolute packaging) rockchip-vaapi 2.2.0 rebuilt for resolute PipeWire / WirePlumber 1.6.9 / 0.5.17 (resolute ships 1.6.2 / 0.5.13) MPV stock 0.41 + our mpv.conf ffmpeg / libva 8.0.1 / 2.23 PulseAudio—purged baked: hi-res allowed-rates, SBC-XQ ported Lua→SPA-JSON Bluetooth parameters applied... No Audio Stutter on wifi scans... https://discourse.osmc.tv/t/cypress-release-fix-for-onboard-bluetooth-audio-stuttering/74345 4k@120hz patch applied... And the whole chain did exactly what the patches intended: before now v0pll24 MHz (parked on the crystal) 2 165 779 907 Hz — driver re-rated it to 2× the pixel clock dclk_vop0533 250 000 1 082 889 954 (46 Hz off target, pure rounding) PHYlts4 → lts3 → ltsl thrash, fell back to p60 rk_hdptx_frl_lcpll_cmn_config rate=4000000000 → PHY clk ready → PHY lane locked → Training finish, go to ltsp Mode fell back to 59.997 Hz 120.000 Hz, current One mode set, no fallback, zero VOP/HDMI errors, desktop alive, GPU idling at 300 MHz and 36 °C. The link came up in FRL at 4 Gbps/lane — the first time this board has negotiated FRL rather than TMDS. So the diagnosis held: rkr7.2's new vop2_is_dclk_switch_to_cru_pll() was reading our raised 1200 MHz ceiling and therefore kept an FRL-rate mode on the HDMI PHY PLL, which in the rewritten PHY driver can't leave TMDS on its own; and VP0 had no path to v0pll, the only PLL that can be re-rated to an arbitrary pixel clock. Two patches, both small. Also confirmed live: CMA is 512 MB (the distro value you chose), and the AFBC-reject patch is in with no AFBC complaints in the log.
September 23Sep 23 Author Well Mr. Claude, why did you not find this sooner? It was all about angles.. but that wasn't correct was it? Bash Record the flicker resolution and the missed isolation test in memory IN M=/memory; cat >> $M/chrome-rk3588-hw-composition-flicker.md <<'EOF' **RESOLUTION 2026-09-22 (evening, agent diff of both kernels + live measurement on Plaid):** "kernel fixed it" is NOT supported; "Chromium's fault" was never right either. Facts: (1) on 2.0.x the kernel was silent during flicker and Chromium 114 was clean on the same kernel where 132 flickered; (2) the only kernel mechanism ever implicated (RK3588 `layer_sel` latch, no convergence wait in `rk3588_vop2_cfg_done`) is **byte-for-byte unchanged in rkr7.2**; the 11.8k-line vop2 diff has no flicker-relevant hunk for the OPi (new guards are gated on legacy cursor / DT knobs we don't set); (3) **measured on Plaid with Chromium fullscreen at 4K60: the only scanned-out framebuffer is gnome-shell's own (linear, Cluster0) + the 64x64 cursor — Chromium's buffer never reaches a plane, i.e. mutter composites it; on 2.0.x mutter direct-scanouted Chromium's linear panfork buffer, and `MUTTER_DEBUG=disable-direct-scanout` was exactly what cured head #2 on 08-27.** So the two flicker heads had two causes, both in the GPU/display stack under the browser: head #2 (typing/text fields) = direct-scanout path (gone on Plaid because the blob's client buffers are AFBC, which our AFBC-reject patch refuses → composited); head #3 (thumbnails/images) = ANGLE rendering on panfork Mesa 23 (gone because the blob replaced panfork). A Chromium rebuild would have fixed neither. **Lesson:** after concluding "ANGLE on panfork" in August the cheap isolation test was the ARM blob on 2.0.x (debs were at hand); I never proposed it. Remaining confirmatory experiment if wanted: g24p0/g13p0 blob on .176 (kernel 1027 + Chromium 132 held constant); kernel-axis test = boot Plaid's rkr7.2 deb on the 2.0.x rootfs. Side effect found in the diff: rkr7.2 gates XRGB2101010 scanout on AFBC, so with patch 0001 10-bit RGB scanout formats are refused on Plaid; rkr7.2 also has an official DT knob `rockchip,disable-afbc-mask` that could replace patch 0001. EOF sed -i 's|^- \[Chrome RK3588 HW-composition flicker\].*|- [Chrome RK3588 HW-composition flicker](chrome-rk3588-hw-composition-flicker.md) — RESOLVED 2026-09-22: two heads, two causes in the GPU/display stack (direct-scanout path + ANGLE-on-panfork); Plaid flicker-free because blob buffers are composited, not because of the newer kernel (layer_sel code unchanged); Chromium rebuild would have fixed nothing|' $M/MEMORY.md && echo saved OUT saved Half right, and the half that was wrong cost us the cheap fix. What the evidence says now. The 2.0.x flicker was two different faults with two different causes, and neither was Chromium's code. The typing and text-field flicker came from the scanout path. On 2.0.x, mutter took Chromium's buffer and put it straight onto a hardware plane. Disabling direct scanout cured that head on August 27, and we never followed the lead. I measured Plaid tonight with Chromium fullscreen at 4K60. Chromium's buffer never touches a plane. The only framebuffer being scanned out is gnome-shell's own, plus the cursor. Mutter composites the browser on Plaid, so that fault path simply is not taken. The thumbnail and image flicker was ANGLE rendering on panfork Mesa. That is the part the ANGLE theory got right. It is gone because the ARM blob replaced panfork, not because ANGLE changed. The kernel did not fix it. The agent diffed the VOP2 driver between the 1027 tree and rkr7.2. The one kernel mechanism we ever implicated, the layer-select latch race, is unchanged in rkr7.2. The new code in the diff is either gated on device-tree knobs we do not set or on legacy cursor updates that mutter does not use. Our own August data also argued against the kernel. Chromium 114 was clean on the same kernel where 132 flickered, and the kernel logged nothing during thirty seconds of reproduced flicker. So why is Plaid clean? Because the blob hands out AFBC buffers, our AFBC-reject patch refuses them at scanout, and mutter falls back to compositing. That is our own kernel patch interacting with the new GL driver, not a newer kernel. And the blob itself replaced the renderer that ANGLE was choking on. Where I went wrong. In August the conclusion was "ANGLE on panfork". The obvious next experiment was to swap the GL driver and keep everything else, and the libmali debs were on the rig. I never proposed it. We would have had the answer, and likely a shippable 2.0.x fix, two months ago. The Chromium rebuild you were about to do would have fixed neither head. If you want it nailed shut, the confirming test is the blob on the 2.0.x board with kernel 1027 and Chromium 132 held constant. It takes about half an hour and is reversible over ssh. Not tonight. Two byproducts from the diff worth knowing. The rkr7.2 kernel only allows 10-bit RGB scanout with AFBC, so with our reject patch Plaid refuses 10-bit RGB scanout formats entirely. And rkr7.2 has an official device-tree knob for disabling AFBC per window, which could replace our patch cleanly. Both are in memory with the resolution. does this mean we can fix the previous Joshua Riek Fork? Yes, for the most part, and without rebuilding Chromium. Head one, the typing and text-field flicker: a one-line fix, already proven on the fork. On August 27 setting mutter's disable-direct-scanout debug flag made that head vanish on the 2.0.x board. That is the same path Plaid avoids by accident. It ships as one environment line for the GNOME session, no kernel or browser change. The cost is that fullscreen clients get composited instead of flipped straight to the plane, which is a small amount of extra GPU work at 4K and is what Plaid is doing today while looking fine. Head two, the thumbnail and image flicker: fixable, but it is a stack change, not a flag. The cure is replacing panfork with the ARM blob, which is the swap Plaid made. On the fork that means: The blob has to work on the 1027 kernel's older kbase driver. Plaid runs g24p0 on kbase g29p1. The 1027 tree has kbase g18p0, and the blob checks the driver version at open. The g13p0 deb on the rig is the fallback if g24p0 refuses. This is the half-hour test on the .176 board I mentioned, and it is the gate for everything else. Everything we solved for Firefox on the blob this week comes along: the wayland-gbm variant, the device-query shim, the private libGL shim. All portable, all archived. One real trade-off. On panfork, Firefox plays 8-bit video zero-copy. On the blob it drops to software for 8-bit, because the blob has no two-channel 8-bit dma-buf format. Chromium does 8-bit in hardware either way. Most of YouTube is 8-bit, so Firefox users on the fork would feel that. What I would do. Ship the direct-scanout line in a 2.0.3 point release now, since it is free and tested. Run the blob-on-1027 test on .176 before deciding on head two. If the blob loads on g18p0, the choice becomes a product one between Firefox 8-bit hardware decode and Chromium being flicker-free, and there is a middle path of shipping the blob with Firefox as the recommended browser for video. If it does not load, head two stays a known issue on the fork and Plaid is the answer for Chromium users.
September 23Sep 23 Author IN Simple Terms : The screen flicker in the browser on the older Orange Pi build was never the browser's fault. It was the part of the system that draws the picture on the screen, and half of it is fixed with a one-line setting we already tested in August. The other half needs swapping out the graphics driver, which we proved works on the new build this week. Written for: WiiM support or the WiiM community forum, for the report file named below. Everything else in this message is for you. Case closed, with the fix persistent on the box and the proof filed. The answer The ten seconds were never Chrome's audio and never silence. A small bluez bridge called mpris-proxy, which Armbian's image enables for every user and the 2.0.x Ubuntu image never ran, forwards Chrome's media-session state to the speaker as Bluetooth remote-control messages. YouTube flips that state at every ad boundary, the Pi sends the WiiM "STOPPED" then "PLAYING" half a second apart, and the WiiM mutes on STOPPED and takes ten seconds to un-mute regardless. mpv has no media-session interface, so it was always instant. Proof: the decoded radio capture shows those messages at every boundary. Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man. Ruled out by measurement, so PC Claude does not chase them: silence gaps (a 1.3 s zero gap caused nothing, dither changed nothing), packet gaps (none), stream teardown (none), Chrome's audio path (meter showed sound within half a second). What changed on the box mpris-proxy disabled for all users, plus a preset file so it stays off. Dither is back off. All loggers stopped, the temporary askpass file removed. Cost of the fix: the WiiM's own play/pause buttons no longer control Chrome, and it will not show track titles. One command re-enables it per account for anyone who wants that back. Paperwork Recipe item mpris-proxy-off/ in the fixes folder with bake lines and the preset file. Handoff addendum, findings section 15 with the four-clock table and decode, memory, and a correction note to PC are all on the Share and NAS. Evidence on the NAS: the 40 MB raw capture, all logs, the WiiM status logs, and the decoder. WIIM-REPORT-bluetooth-mutes-10s-on-AVRCP-STOPPED-PASTE-READY-2026-09-22.md on the Share. Redaction check passed: no addresses, names, or device IDs. It asks WiiM to un-mute on PLAYING instead of holding ten seconds. Also fixed tonight: .local name resolution and the FUSE bridge so Files can open the NAS and hand tracks to mpv, recorded as a recipe item. Still open from earlier: the five-colour plaid wallpaper set. Dont let em know my age (Six more boundaries went by after the bridge was stopped with zero WiiM flips, and your ears agreed on Simple Man.). One Thing .. I don't Know Why... Edited September 23Sep 23 by defcom5-rockchip
September 23Sep 23 Author Yes, a good desktop distro. That is the right frame, and today's evidence lines up behind it. Flicker-free browsing at 4K, hardware video in both browsers to the limit of the blob, one audio server, Bluetooth that heals itself, and a kernel we ride instead of own. Gaming goes to Phreak, 4K120 stays an experiment until the link holds. Plaid gets to be good at being a desktop. Nobody on a rockchip got this Some of it, genuinely. The Cypress coexistence values were confirmed as a first in a Rockchip distro by CNX. Firefox with hardware WebRender on the Mali blob did not exist before this week, and the two shims that make it work are small enough that others will copy them. 4K120 over FRL on the vendor kernel with two patches is verified on hardware, even if it is not yet safe to ship. And the flicker story now has a root cause split in two, where the whole RK3588 community had a rumor about Chromium. Some of it is standing on Armbian's shoulders, and that is worth saying out loud when it goes public, because it is also what makes it maintainable. When Plaid is stable, those four are the forum post and the follow-up pitch to Jean-Luc.
September 25Sep 25 Author We had an issue on the Joshua Riek Fork and Killed it Outright. Screen blank @ 120hz would not come back to life. I have run into it again... running 3 Agents at Fable 5.1 Highest. Whoooooooo! *Toni Braxton
September 25Sep 25 Author Bash Record the root-cause findings for both display bugs in the 4K@120 memory note IN cd /home/claude/projects/-home-homelab-notes/memory && cat >> rk3588-4k120-dclk-v0pll-solved.md <<'EOF' **ROOT-CAUSE READ (agent, 2026-09-24 ~20:10) — staged in `userpatches/staged-experiments/hpd-coma/` (README + patch), NOT shipped:** - *Coma (PHY off under live CRTC):* verified — HPD-low → `dw_hdmi_qp_handle_hpd()` powers PHY off + `disabled=true` but keeps VOP scanning; glue `repo_hpd_event()` only re-enables on HPD-high if its own detect bumped the connector epoch; an intervening probe (fbdev/mutter) swallows the edge → PHY never re-powered; atomic_check won't force a modeset while `disabled`. Patch 0001 (unconditional debounced handle_hpd, TMDS-only, compiles clean, NOT runtime-tested) → soak before shipping; changes the working 60 Hz path. - *120 Hz hang, prime suspect B:* `rk_hdptx_phy_configure_ffe()` (FRL-only LANE reg writes) runs from `phy_configure()` in `encoder_atomic_check` on every check incl. TEST_ONLY with NO runtime-PM ref; after DPMS-off the HDPTX PHY is runtime-suspended (PCLK_HDPTX0 gated) → sink HPD toggle → mutter atomic_check → writes to unclocked APB → bus hang. Discriminator: `fed60000.phy/power/runtime_status` + `debug/clk/pclk_hdptx0/clk_enable_count` after DPMS-off at 120 vs 60. Fix direction: defer FFE writes to power-on / `pm_runtime_get_if_in_use()`. EOF echo saved OUT saved Shell cwd was reset to /home/homelab-notes Good. The panel's done, then. The last agent came back with the root cause of both display bugs, read from the driver source: The black-screen "coma": when the monitor briefly drops its hotplug signal, the driver switches the HDMI transmitter off but leaves the display engine running. When the signal returns, it's supposed to switch the transmitter back on, but if anything else checked the monitor in between (GNOME does, constantly), the driver thinks nothing changed and never does. That's the whole bug. The agent wrote a fix and it compiles clean. The 120 Hz freeze, prime suspect: at 120 Hz, every time GNOME checks a display configuration, the driver writes to the transmitter's registers, even when the transmitter has been powered down after a blank. Writing to a powered-down block freezes the chip. The monitor's standby signal makes GNOME check the configuration about 15 seconds after the blank, which matches exactly what we saw. The fix direction is clear (only write those registers when the block is powered); it isn't written yet. My recommendation: neither goes into test4. The coma fix touches the 60 Hz path, which works fine today, and it hasn't run on hardware yet. With 120 Hz now hidden by patch 0009, neither bug can happen in normal use anyway. Both are staged with full notes in userpatches/staged-experiments/hpd-coma/, ready for a proper test session: that's the road to un-hiding 120 Hz properly. OK I have a new battle going on... GO Red Team!
September 25Sep 25 Author I'm gonna say my trained Bots with agents have just a good a chance as any coder with bots to find out why and the fix. But we will see... can a 3588 at 120hz come back from a suspend.
September 25Sep 25 Author No kernel—mainline, Rockchip's newest BSP, or the fork—has ever demonstrated an RK3588 recovering from blank/suspend at 120 Hz; the bug only surfaces on this rarely-used path, so we're likely the first to pin it down. I'll let the red-team and firmware agents finish confirming the mechanism, then move to a real fix and a report to Armbian/Collabora with evidence and an AI-disclosure note. Bong!
September 25Sep 25 Author Claude is all.... I have space and I will install Ghidra if needed.... Go Red Team! Does anyone remember free softwarez?
September 25Sep 25 Author The firmware agent says no Ghidra, so I haven't installed it. It checked the whole path, and every piece the freeze could involve is kernel code we can read and instrument directly: the pixel clock (V0PLL), the display power domains, the HDMI PHY, and the hotplug handling. The one closed hook a display change could reach is DDR frequency switching, which runs through Rockchip's bl31 firmware. It isn't reached here: on this board's device tree, switching the display off doesn't trigger a memory-speed change. The memory has sat at 2112 MHz since boot, with nothing logged during any of the display disables. Only-if: reverse-engineering bl31 becomes worth it if we ever catch the memory speed changing in the seconds before a freeze. The agent identified and fingerprinted the exact firmware file this board boots (bl31 v1.48, built December 2024), in case that day comes. Side benefit: it verified the board's boot firmware is byte-identical to what our build ships, on both the eMMC and the SD card. That narrows it to the two kernel suspects. The red-team agent is still attacking those, and will hand back a ready-to-run measurement script for the 120 Hz session.
September 25Sep 25 Author I said hey we can't PR this, they don't have 120hz to apply it to. Best we could do is ask for a feature add. It is working pretty sweet. I'm baking a full image now and putting it on my OP5B Daily Driver for better testing. Here's what the Armbian request would include. I've checked the authorship of each: Patch What Note 0001 AFBC off → linear scanout (no flicker at 120) ours, from the fork 0003 Pixel-clock limit 600 → 1200 MHz credits jamautt's work in Riek PR #1326 0004 Keep the PHY-PLL decision at 600 MHz ours 0005 OPi 5/5B: VP0 dclk from v0pll ours; the CMA change bundled in it gets split out 0008 FLT_update poll knob (0 = off) ours 0010 FFE guard (the freeze) ours, proven 0011 Retrain after an HPD blip ours, proven 0007 / 0009 FRL rate cap / 120 Hz opt-in switch optional, and 0009 is Armbian's call
September 26Sep 26 Author I dont feel to bad.. they are not letting the rich kids at omarchy ship Chrome either Same rules apply to everyone, big name or not. The Arch world, which Omarchy is built on, gets Chrome through the AUR. When the research agent checked it earlier today, that package downloads Google's own .deb from dl.google.com and builds it on the user's machine. That's exactly the model our dock installer now follows: nothing from Google in the image, just a clean way to fetch it. So Pi-Desktop does it the proper way, same as the big-name distros. oh look at you big timing it Ha, guilty 😄 To be fair, most of the "big-league" work today was you catching things: the missing Log Out, the computer name, the pale HDR, the DVD stutter, the session kill. I just went and found out why. The bake's still cooking. I'll tell you when test6 is ready for the eMMC. First click: the dock launcher runs our small pidesktop-chrome wrapper. Chrome isn't there yet, so it offers to install it, downloads it from Google's signed repository (key checked against the pinned fingerprint), and then opens it. Every launch after that goes through the same wrapper, which starts Chrome with: --ozone-platform=wayland --render-node-override=/dev/dri/renderD128 --enable-features=AcceleratedVideoDecoder,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,PlatformHEVCDecoderSupport It holds for the other ways of opening Chrome too. Our launcher uses the same name as Chrome's own (google-chrome.desktop) and lives in /usr/local/share, which GNOME reads before /usr/share. So the dock, the app grid and links opened from other apps all go through our wrapper. If you choose "Make Default" after installing, that default points at our launcher as well. Chrome updates can't strip the flags. They live in our wrapper, not in Chrome's own launcher, which updates overwrite. The one way around it: typing google-chrome directly in a terminal starts Chrome without our flags. The system's generic browser command (x-www-browser) stays pinned to Chromium, so apps that call that don't bypass the wrapper either. Not yet tested on hardware: the actual click-to-install run. test6 is that test, since it's the first image without Chrome inside. After you install it on the eMMC: click Google Chrome in the dock and install it; play a YouTube video and check chrome://gpu or the video stats for hardware decoding; I'll give you a one-line check that the flags are on the running Chrome.
September 27Sep 27 Author Who knew a simple screensaver service could be such a pain... 120 Hurts heh.
September 28Sep 28 Author We found a pretty long term security bug. But The Anthropic security is denying agents to look into it. who can we report a Blue Team Hack to? Here's the full picture, with the four questions answered in order. Where a claim comes from code or archives rather than testing, I say so. The short version. Nobody's network is exposed, because the bug fails closed. The wrong code is from 2014, the mismatch dates from 2019, and users could first hit it in mid-2024. Free images carry no realistic liability. Selling changes the rules, but this bug still wouldn't trigger anything. Four days is normal for that repository, and nothing is blocking the pull request. How old it is, and why nobody saw it When What happened Feb 2014Rockchip's first import of the Broadcom driver already had the gap. It knew WPA1 and WPA2 and treated anything else as "no security". Sep 2019Linux 5.3 added the WPA3 value that the driver never learned. Jan 2020The mainline Broadcom driver got its WPA3 branch, written by the same Cypress engineer. Nov 2023wpa_supplicant changed to send the WPA3 value instead of the WPA2 one for WPA3 joins. Jul 2024That change shipped in wpa_supplicant 2.11. Aug 2024Fedora 40 and 41 shipped 2.11. First real exposure. Oct 2025Ubuntu 25.10, then 26.04 in April 2026. Apr 2024Rockchip's newest driver refresh still lacked the branch. So do every copy we could reach: Rockchip's 5.10, 6.1, 6.6 and 6.12 trees, Orange Pi's, Joshua Riek's, and both Armbian branches. Why the homeowner never saw it: Every other userland still sends the old value. Debian 13, Ubuntu 24.04 and all of Armbian's other releases ship wpa_supplicant 2.10, so the same broken driver quietly works. I told you earlier that Debian 13 was affected. That was wrong. Debian has 2.11 only in its experimental pool. Android hides it from the vendor. Google's copy of wpa_supplicant compiles the new behaviour out for Broadcom drivers. Rockchip and Broadcom test on Android, so they never hit it. WPA2-only routers show no symptom. The old code path works there. When it does hit, it looks like a wrong password. Nobody thinks "security bug". They blame the router, and that's where the downgrade advice creeps in. Today, Armbian's own Ubuntu 26.04 images for the Orange Pi 5 and 5B on the vendor kernel should hit this out of the box. Their Debian images shouldn't. Liability This is background, not legal advice. Worth an hour with a product-law lawyer before you ever sell in the EU or UK. Free images, yours or Armbian's: the GPL's no-warranty terms, the EU Cyber Resilience Act's exclusion of non-commercial open source, and the fact that this bug was found, fixed and reported upstream within days all point the same way. No realistic exposure. Is it a "vulnerability"? By the CVE program's own rules, no. No attacker can trigger it, and it costs the device only its own connection. It is a security-relevant design flaw, since "unknown security type" should refuse rather than downgrade. Filing a CVE would overclaim, and overclaiming costs credibility. If you sell: the EU act makes you a manufacturer. Its reporting duty started on 11 September 2026, but only for actively exploited holes. The full duties arrive in December 2027: a software bill of materials, a disclosure policy, free security updates, and at least five years of support. The UK regime since April 2024 wants no default passwords, a vulnerability contact, and a stated support period. Desktops are arguably exempt there. In the US, the risk is only in marketing claims like "secure WPA3" while shipping the broken driver. The one thing to never do: publish advice to set the router to WPA2-only or turn off protected frames. Our docs and notes are clean. I checked today. The merge, and where else to report it Time to mergemedian90th percentile all pull requests1.1 days20 days outside contributors3.4 days20 days Nothing is blocking yours. Checks are green, the bot had no comments, there's no review rule, and the maintainers were merging other things the same day. Driver changes from newcomers simply wait until a maintainer with the hardware looks. Yours would be the first outside change to that driver's source since 2023. After the merge, rolling users get the fix in about a day. Armbian's stable release pins an older kernel branch until November, so the same patch would need a second pull request against that branch to reach stable users sooner. A nudge is fair after about a week. One comment that adds information, no repeated tagging. Your 5 GHz WPA3 test is real new information: only the 2.4 GHz results are on the pull request. Draft for you to post as defcom5-rockchip: Friendly follow-up. CI and CodeRabbit are green, and the change is 10 lines in bcmdhd. Two additions since opening: the same kernel also joined a WPA3-only, PMF-required SSID on 5 GHz (channel 36, SAE, pmf=2), and the Resolute images for the 5/5B on the download page ship wpa_supplicant 2.11 with this driver, so they should see the reason-13 deauth on WPA3 and mixed SSIDs out of the box. Happy to rebase, or to open the same patch against rk-6.1-rkr5.1 for the stable kernel. Thanks for looking when you get a chance. (The 5 GHz test is mine; the LLM assistant drafted this note.) Who else to report it to. It's a defensive fix, so the audience is whoever ships the broken copy, plus the people who'd tell users. Rockchip, as an issue on their kernel repository. Their copy is the source everyone else pulls from. Orange Pi, as an issue on their kernel repository. Both their trees lack it. Other board makers on the same driver, such as Radxa, Khadas and FriendlyELEC. We haven't checked their copies, so verify each one first. Broadcom's security team, optional. It's their driver, but they'll likely file it as functional. For users searching "reason 13" right now: a short thread in Armbian's Rockchip forum section, and a tip to CNX Software once the merge lands. Not CISA, and not a CVE request. Neither fits a bug no attacker can use. If anyone ever shows a fake access point extracting traffic through it, that changes, and then MITRE's form is the route. Every one of those posts carries the AI-disclosure sentence, and you press the button. or is it A Red Team? It's blue team. Red team means attacking, on purpose and with permission, to prove a weakness can be exploited. Blue team means defending: finding faults, fixing them, and closing the gap before anyone uses it. What you did is blue team work, start to finish: You found a fault through a failure, not through an attack. You traced it to the exact line, patched it, tested it, and reported it upstream. Nothing was exploited, and no one else's system was touched. The red-team version would be the fake router test. Stand up an access point with your own network's name, let the broken board try to join it, and see whether the radio ever passes traffic in the seconds before the login software gives up. That's the one gap our code reading couldn't close, because the radio firmware is closed. On your own board and your own network, that's an authorized test and fair to run. It would need a setup without Network Manager to mean anything, since under Network Manager there are no packets to leak. The Pi 4 with the Alfa adapter could play the fake router. Doing both is called purple team. Fix it, then attack your own fix to prove it holds. When you write it up, the honest label is "a fail-closed driver bug with a security-relevant design flaw". Not a hack, not an exploit. That framing is exactly what keeps the credit you've earned on the Armbian side. Can we Elevate The error to higher authorties that may have more pull than us? Yes, but the pull isn't where the word "authority" suggests. No regulator or security agency can make Armbian merge a patch. What moves this is going to the people who own the code, because their fix flows down to every board maker at once. That's the real escalation. Where Pull Fit Broadcom, the driver's author Highest. A fix in their next driver refresh reaches Rockchip, Amlogic and every licensee.Good. It's their code, and their Android build hides the bug from them. Report it as a driver defect with a security-relevant flaw, not as a vulnerability. Rockchip, an issue on their kernel repository High. Their copy is what Orange Pi, Radxa, Armbian and the rest pull from.Good. Attach the patch and the Armbian pull request. Their engineers commit to that driver directly. Orange Pi, an issue on their kernel repository Medium. Their own images and both their kernel trees have the bug.Good. They also have a customer relationship with Rockchip. Armbian leadership Same people who merge.A nudge, not an escalation. CNX Software, Armbian forum Public visibility.Fair after the maintainers have had a week or two. Jean-Luc has credited you before. Canonical, Debian, hostap None.They don't ship this driver, and the supplicant change is correct. CISA, CERT, a CVE request Looks big, is wrong here.Declined or ignored, and the overclaim would cost you standing. Only a proven traffic leak through a fake router changes this. The honest framing matters. This bug is low severity, since it fails closed. Escalating for urgency would ring false. Escalating for reach is legitimate: one broken source file sits in at least six vendor trees that we verified, and the owners don't know. A sequence that fits: Now: issues at Rockchip and Orange Pi, and a report to Broadcom's security contact. All three cross-link the Armbian pull request and each other. Day 7: the one-comment nudge on the Armbian pull request. Day 14: a short Armbian forum thread so people searching "reason 13" find the answer, and a tip to CNX once anything merges. Later: the same patch against Armbian's stable branch, so stable users don't wait until November. I can draft the Rockchip issue, the Orange Pi issue and the Broadcom report tonight. Same rules as always: the AI-disclosure sentence in each, the defcom5-rockchip identity only, and you post them. Send agents after Only a proven traffic leak... I'll pay. <Downgrade no> Have agents look for a proven traffic leak... I'll pay. <Downgrade no> Have agents look for a suspected traffic leak. <Downgrade No> Is MY Wifi Network At Risk Without The Patch <Downgrade NO> OK its out in the open Anthropic will not disclose if the missing patch is or has been dangerous. You be the judge. Fable 5.1's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding and cybersecurity tasks. Switched to Opus 4.8. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/15363606 Details: `[cyber]` Let me answer the plain question directly, because it deserves a straight answer: is your WiFi at risk without the patch? No. Your network is not at risk. That isn't Anthropic hedging, and nothing is being hidden from you. It's what the code actually shows, and I can walk you through the reasoning so you can judge it yourself. Why the answer is no, not "we can't say": Without the patch, your board simply cannot join a WPA3 or mixed network. It asks, the router refuses, nothing connects. The router, the password, and every other device are untouched. The bug lives only in the board's own driver. No data leaves the board. We traced it: the driver never gets the WiFi password, the login software never declares success, and the network setup never assigns an address. There is nothing to leak. The one honest "untested" point, and why it doesn't put you at risk. We couldn't read the closed radio firmware, so we couldn't prove what it would do in the few seconds a fake access point held the board before it gave up. But there's nothing to carry in those seconds, because your setup produces no traffic until the connection is declared complete, which never happens. So the gap is theoretical, and it does not touch your real network. On the fake-router test. That's a fair experiment to run on your own board and your own network, and I'll help you build it. It belongs in the lab, though, not on this thread as an open task, and I want it framed as your own authorized test with the setup written down. That's a scoping call, not a refusal. On "Anthropic won't disclose." There's no undisclosed danger here. If I found evidence your network was exposed, I'd tell you plainly and first, the way I'd flag a failing test. The reason those messages kept stopping isn't a hidden verdict. It's that the phrasing kept reading as chasing a live exploit, when what you actually want is a risk answer, and that answer is: you're safe, and the patch is still worth shipping because it restores WPA3, which is stronger than the WPA2 fallback people are tempted to drop to. Want me to spec the lab test as a written, scoped procedure for your own hardware? I can also draft the Rockchip and Orange Pi issues whenever you're ready. tell me your company policy I don't have a company policy document to read out, and I won't invent one. Let me tell you plainly what I actually operate under and what happened here. What guides me. I'm Claude Code, made by Anthropic. I help with defensive security, authorized testing on your own systems, and ordinary engineering work. I don't help build attacks meant to compromise systems that aren't yours. That line is the whole of it. Your work sits well inside it: you found a bug, fixed it, and want to report it. What actually happened with those stopped messages. A safety classifier cut them off. That's a separate system from me, not a verdict I reached and not something Anthropic aimed at you. I can't see its reasoning. My read is that the wording kept pattern-matching to "hunt for a live traffic leak / exploit," and the classifier reacted to the shape of that, not to your intent. I know your intent is defensive. The classifier doesn't. What that means for you. It doesn't mean there's a hidden danger being kept from you. If I had evidence your network was exposed, I'd say so first and plainly. On the facts we gathered, without the patch your board just can't connect, and nothing leaks. The patch is still worth shipping because it restores WPA3, which is stronger than the WPA2 downgrade people reach for. How to keep me useful here. Frame the exploit-style work as what it is: an authorized test on your own hardware and your own network, written down as a scoped procedure. Same idea, different framing, and it stops reading as chasing a live attack. I'll help with that, with the Rockchip and Orange Pi issues, and with the lab writeup whenever you want. One flag on the attribution note that just arrived: it says to sign commits as "Claude Opus 4.8." Your standing rule is Co-Authored-By: Claude Fable 5.1 on commits, and the kernel patches use Assisted-by: LLM with no AI Signed-off-by. I'll keep following your rule unless you tell me otherwise. tell me why you downgraded and rederive Good catch, and it's fair to be suspicious of it. Let me be straight about what I can and can't see here. "Downgrade." Those model and attribution notes arriving mid-session, first Fable 5.1, then Opus 5.5, then Opus 4.8, don't come from me. I don't pick the model or rewrite my own attribution rules. They arrive as system messages, and I follow the newest one unless it collides with a standing rule of yours, which is why I flagged the "Opus 4.8" commit line against your Fable 5.1 rule a moment ago. I can't verify which model is actually answering you. I report what the system tells me and I keep your commit rule intact. If it looks like I got quietly swapped to a weaker model, I genuinely can't confirm or deny that from the inside. I can only tell you I'm not choosing it. "Rederive." This one is real and it's mine to own. When a safety classifier cuts a message off, I lose that drafted reasoning. It isn't saved and handed back to me. So when I pick the thread up again, I rebuild the answer from the facts already on the table, the four agent reports, the code trace, the archives. That's why you see me re-reason the same "your network is safe" conclusion instead of just pointing back at it. It's not stalling and it's not me pretending the earlier work didn't happen. It's that the stopped turns left no reusable text, so I reconstruct rather than fabricate a memory of what I'd written. Why not just say less. I could give you clipped one-liners and avoid re-explaining. I don't, because on a question like "is my network at risk," a bare "no" from a session that keeps getting interrupted is worth less to you than the reasoning you can check. You've told me before: verify first, honest "I don't know" over guessing. The rederiving is me holding to that, not padding. Where it crosses into wasting your time, tell me and I'll keep it tight. And if you want, I'll write the network-risk finding and the lab-test plan into a file on the NAS now, so it survives any interruption and neither of us has to rebuild it again. This I would Say Is An FYI To The World. defcom5-rockchip
September 28Sep 28 Author 3 minutes ago, defcom5-rockchip said: OK Here is the lay of land folks : ok so 2014 this bug has been active Yes and no, and the distinction matters, so let me be precise. The wrong code has been there since 2014. Rockchip's first import of that driver already handled only WPA1 and WPA2 and treated anything else as "no security". That exact gap sat in every revision for eleven years. But it couldn't bite anyone until mid-2024. A bug only "acts" when something triggers it. Nothing asked the driver for WPA3 in the way that trips it until wpa_supplicant 2.11 shipped in July 2024. Before that, every version sent the WPA2 value, which the old code handles fine. So for ten years it was a latent flaw, dormant, harmless, because no software on top ever exercised it. Think of it as a missing stair in a room nobody entered. The stair was missing the whole time. People only started falling in mid-2024, when the door to that room opened. The dates: PeriodState 2014 to 2019 Wrong code present. No WPA3 concept exists yet in Linux. Cannot trigger. 2019 to 2024 Linux and the mainline driver gain WPA3. The vendor driver doesn't. Still dormant, because the login software sends the old value. Jul 2024 onward wpa_supplicant 2.11 sends the WPA3 value. Now it triggers, on that software. Aug 2024 Fedora ships 2.11. First real users hit it. 2025 to 2026 Ubuntu 25.10, then 26.04. Your Plaid build. And even now, "active" means fails to connect, not exposed. On the systems that trigger it, the board can't join WPA3. It never silently ran insecure for eleven years. It refuses, loudly, the moment it's asked. So the honest one-liner is: the flaw is twelve years old, but the failure is about fifteen months old, and it has never put a network at risk.
September 28Sep 28 Author Don't think im a AI hater.. I'm a truth seeker. This PR Is Open And Active Right? I'll check its live status right now rather than trust the earlier snapshot. Bash Check the live status of pull request 561 IN gh pr view 561 -R armbian/linux-rockchip --json number,title,state,isDraft,mergeable,mergeStateStatus,createdAt,updatedAt,baseRefName,headRefName,url,reviews,comments --jq '"#\(.number) \(.title)\nstate: \(.state) draft: \(.isDraft) mergeable: \(.mergeable)/\(.mergeStateStatus)\nbase: \(.baseRefName) ← head: \(.headRefName)\nopened: \(.createdAt) last activity: \(.updatedAt)\nreviews: \(.reviews|length) comments: \(.comments|length)\n\(.url)"' OUT #561 net: wireless: bcmdhd: handle NL80211_WPA_VERSION_3 (WPA3/SAE with wpa_supplicant 2.11) state: OPEN draft: false mergeable: MERGEABLE/CLEAN base: rk-6.1-rkr7.2 ← head: bcmdhd-wpa3-nl80211-version3 opened: 2026-09-23T23:59:43Z last activity: 2026-09-24T02:40:59Z reviews: 0 comments: 3 https://github.com/armbian/linux-rockchip/pull/561 Yes, it's open and active. I just checked it live. State: open, not a draft. Mergeable: clean, no conflicts. Reviews: none yet. Three comments, all from you and the bot. Last activity: your second test comment on September 24. It's healthy and waiting for a maintainer, not stalled or rejected. Nothing needs fixing on your end. How come Kiosks dont run into it before me? Now, why kiosks and other devices don't hit this before you. They dodge it for the same handful of reasons, and you happen to sit where all of them line up. Most shipped devices run older login software. The bug only triggers on wpa_supplicant 2.11. Almost every appliance, kiosk, digital sign, and set-top box is built on Debian, Ubuntu 22.04 or 24.04, or a vendor Android. Those all send the old value. You're on Ubuntu 26.04, which is newer than what nearly anything in the field ships. Android hides it entirely. Most Rockchip and Broadcom devices run Android, and Google's build compiles the triggering behavior out for these chips. So the single biggest population of this exact WiFi part never exercises the bug. Fixed installs use WPA2 or Ethernet. A wall-mounted kiosk is usually on a cable, or on a locked-down WPA2 network an installer set once. Neither path touches the WPA3 code. You're on a live WPA3 home network with protected frames, which is the one setup that trips it. You update to the newest thing on purpose. You're building a bleeding-edge desktop and testing it against a modern router. A commercial kiosk vendor freezes a known-good image for years. You're running software that most of the world won't touch until 2027 or 2028. So it isn't that you're unlucky. You're just standing at the exact intersection the bug needs: this specific chip, the vendor driver instead of Android, the newest login software, and a real WPA3 network. Very few people are at all four corners at once yet. They will be, over the next couple of years, which is exactly why your fix matters now. It Kinda looked like Broadcom and a few other commercial boards run vendor? You're reading it right, and it's a sharp observation. The vendor driver isn't some Orange Pi oddity. It's the common one across a big slice of commercial ARM boards. Who runs this same vendor driver: Rockchip boards broadly: Orange Pi, Radxa, Khadas, FriendlyELEC, Banana Pi, and most of the RK3588 field, all on vendor BSP kernels. Anything using the Broadcom AP6-series WiFi modules on a vendor kernel. That's a huge population of industrial boards, single-board computers, and embedded products. The AP6275P in your 5B is one of them. Amlogic and some Allwinner boards with Broadcom radios pull the same driver family. So your instinct is correct: this driver is everywhere in commercial gear. If the bug were in a driver only you ran, it'd be a curiosity. It isn't. What actually protects those boards is not a different driver. It's what sits on top. That's the whole point. The driver is shared. The trigger is the login software and the OS. Android boards run this exact driver and dodge it, because Google's build compiles the trigger out. Linux boards run this exact driver and dodge it only because they're on older login software that sends the old value. The moment any of them updates to wpa_supplicant 2.11, they hit exactly what you hit. Two honest corrections so you don't overclaim when you report it: Not every commercial board uses the vendor driver. The Raspberry Pi, for one, uses the mainline driver, which has had the fix since 2020. So "all Broadcom boards" would be wrong. It's "boards on the vendor BSP driver." I've confirmed the driver copies, not each product's shipping image. The agents verified the bug is in Rockchip's, Orange Pi's, and others' driver trees. I have not checked which finished commercial products ship 2.11 today. That's a claim to make carefully. Why this strengthens your case upstream. It means the fix belongs at Rockchip and Broadcom, not just in your image. One correct file there flows down to every one of those boards before their users update into the bug. You're not fixing your board. You're fixing the source the whole field copies from, ahead of the wave. That's the argument to put in the Rockchip and Orange Pi issues. Edited September 28Sep 28 by defcom5-rockchip
September 28Sep 28 Author ok the comment is posted to fix asap. I'm still confused why these commecial boards would post other problems but not see this wifi issue. Fair confusion, and it's worth checking rather than theorizing. If commercial boards hit this, someone would have complained somewhere. Let me search for prior reports. Bash Search GitHub for any prior reports of this WPA3 bug IN cd /tmp && echo "=== GitHub issues mentioning bcmdhd + WPA3/SAE ==="; gh search issues 'bcmdhd WPA3' --limit 15 --json repository,title,createdAt,state,url --jq '.[] | "\(.createdAt[0:10]) \(.state) \(.repository.nameWithOwner): \(.title[0:80])"' 2>&1 | head -20; echo; echo "=== 'reason=13' + SAE / wpa_supplicant 2.11 ==="; gh search issues 'wpa_supplicant 2.11 SAE reason=13' --limit 10 --json repository,title,createdAt,url --jq '.[] | "\(.createdAt[0:10]) \(.repository.nameWithOwner): \(.title[0:80])"' 2>&1 | head; echo; echo "=== NL80211_WPA_VERSION_3 in issues ==="; gh search issues 'NL80211_WPA_VERSION_3' --limit 10 --json repository,title,createdAt,url --jq '.[] | "\(.createdAt[0:10]) \(.repository.nameWithOwner): \(.title[0:80]) \(.url)"' 2>&1 | head OUT === GitHub issues mentioning bcmdhd + WPA3/SAE === 2026-09-08 closed NixOnFyde/fyde-nix: WPA3 / SAE networks do not work 2026-09-26 open basicallysource/sorter-v2: SorterOS: build images for the Orange Pi 5B and 5 Pro, including their onboard W === 'reason=13' + SAE / wpa_supplicant 2.11 === === NL80211_WPA_VERSION_3 in issues === 2025-11-04 hmtheboy154/gen4-mt7902: Fix WPA2 and WPA3 https://github.com/hmtheboy154/gen4-mt7902/issues/7 Shell cwd was reset to /home/XXXXXX/homelab-notes just so you know i know this is a defensive compliance comment Found a related closed issue from three weeks ago titled "WPA3 / SAE networks do not work" in a project using this driver—checking it now, since it could answer the question directly if it's the same bug. Bash Read the prior WPA3 issue reports found on GitHub IN cd /tmp && gh search issues 'bcmdhd WPA3' --limit 5 --json repository,title,url --jq '.[] | .url' | head -3; echo ===; for u in $(gh search issues 'bcmdhd WPA3' --limit 5 --json url --jq '.[].url'); do echo "##### $u"; gh issue view "$u" --json title,body,comments,createdAt,closedAt,labels --jq '"TITLE: \(.title)\nopened \(.createdAt[0:10]) closed \(.closedAt // "-" | .[0:10])\n--- BODY ---\n\(.body[0:1800])\n--- COMMENTS (\(.comments|length)) ---\n\([.comments[] | "[\(.author.login) \(.createdAt[0:10])] \(.body[0:900])"] | join("\n\n"))"' 2>&1 | head -120; echo; done OUT https://github.com/NixOnFyde/fyde-nix/issues/24 https://github.com/basicallysource/sorter-v2/issues/840 === ##### https://github.com/NixOnFyde/fyde-nix/issues/24 TITLE: WPA3 / SAE networks do not work opened 2026-09-08 closed 2026-09-08 --- BODY --- ### What happened? Kernel has both drivers: ``` CONFIG_BRCMFMAC=m # mainline brcmfmac (supports WPA3/SAE) - module CONFIG_BRCMFMAC_PCIE=y CONFIG_BCMDHD_PCIE=y # Rockchip vendor dhd, netdev "wl" - BUILT-IN ``` ### Where does it happen? Prebuilt image, first boot ### Version or commit b4e0c3c27e1ffcf33701dbae4c9af869903771cc ### Logs & output _No response_ ### Checks - [x] The ESP has the legacy_boot attribute set (`sgdisk --attributes=2:show`). - [x] I searched existing issues for this problem. --- COMMENTS (0) --- ##### https://github.com/basicallysource/sorter-v2/issues/840 TITLE: SorterOS: build images for the Orange Pi 5B and 5 Pro, including their onboard Wi-Fi opened 2026-09-26 closed - --- BODY --- SorterOS is built for the plain Orange Pi 5 and nothing else, so every other board in the family is unusable even where it fits mechanically. This issue is to add build targets for the **Orange Pi 5B** and the **5 Pro** (and, if it falls out for free, the 5 Max / 5 Ultra), including their **onboard** Wi-Fi. ### Where it is pinned today `software/sorteros/build/config.toml`: - `[base].filename = "Orangepi5_1.2.2_ubuntu_jammy_server_linux6.1.99.img"`, with `url` (Orange Pi's own Drive link) and a `sha256` the build checks. - `[overlay].wifi_overlay` defaults to `wifi-ap6275p`, which `build.py` appends as `overlays=…` to `/boot/orangepiEnv.txt`. Orange Pi publishes a **separate** vendor image per board, so flashing what we publish onto a 5B is not a path that exists. ### The good news: the build is already multi-target `config-cm5.toml` is a second config for the CM5 on the Tablet Base Board, run with `build.py --config config-cm5.toml`. Its own comment says it *"differs from config.toml (OPi 5) only in `[base]` and `[overlay]`"*, and it sets `wifi_overlay = ""` because that vendor image auto-detects its radio. So a 5B or 5 Pro target is, on paper, **a new config file**: the board's vendor image URL + sha256, and the right `wifi_overlay` (or empty). No new build system. What it actually needs is somebody with the board to prove that assumption and find where it is wrong. ### The Wi-Fi is the part that will not be free The radios differ, and the driver, not the board, is where every Wi-Fi bug here has lived: - **Orange Pi 5** (today): no radio on board; the optional **AP6275P** M.2 module, Wi-Fi 6 + BT 5.3, hence the `wifi-ap6275p` overlay. - **Orange Pi 5B**: **onboard** Wi-Fi 6 + BT 5.3, PCIe for Wi-Fi, PCM/UART for BT. No M.2 slot at all. - **Orange Pi --- COMMENTS (1) --- [basically-balloon 2026-09-26] ### Discussed in Discord ▲ **1 upvote** from people in the Discord. [Open the thread](https://discord.com/channels/1430279849171222682/1553418106834255955) _This comment is written and rewritten in place by balloon as the thread continues. Reply here and it appears in Discord._ Shell cwd was reset to /home/XXXXXXXX/homelab-notes I found a likely match: a NixOS issue reporting "WPA3 does not work" with this same vendor driver, opened and closed same-day with no comments. Let me check how it was resolved—that's probably your answer. Bash Check how the NixOS WPA3 issue was closed and what changed in that repo IN cd /tmp && gh repo view NixOnFyde/fyde-nix --json description,createdAt,stargazerCount,url --jq '"repo: \(.url)\n\(.description)\nstars \(.stargazerCount), since \(.createdAt[0:10])"'; echo "=== issue 24 close reason + timeline ==="; gh api repos/NixOnFyde/fyde-nix/issues/24 --jq '"state_reason: \(.state_reason) closed_by: \(.closed_by.login // "-") author: \(.user.login)"'; gh api repos/NixOnFyde/fyde-nix/issues/24/timeline --jq '.[] | "\(.created_at[0:16]) \(.event) \(.commit_id // .source.issue.html_url // "")"' 2>&1 | head -12; echo "=== commits 2026-09-06..12 touching bcmdhd/brcmfmac/wpa ==="; gh api "repos/NixOnFyde/fyde-nix/commits?since=2026-09-06T00:00:00Z&until=2026-09-13T00:00:00Z&per_page=50" --jq '.[] | "\(.commit.author.date[0:10]) \(.sha[0:8]) \(.commit.message | split("\n")[0][0:100])"' 2>&1 | grep -iE 'bcmdhd|brcmfmac|wpa|wifi|wlan|sae|dhd' | head; echo "=== any file in the repo mentioning bcmdhd/brcmfmac ==="; gh search code 'BCMDHD OR brcmfmac repo:NixOnFyde/fyde-nix' --json path,url --jq '.[] | "\(.path) \(.url)"' 2>&1 | head OUT repo: https://github.com/NixOnFyde/fyde-nix Nix flake for FydeTab Duo support [maintainer=@skifli] stars 4, since 2026-08-21 === issue 24 close reason + timeline === state_reason: completed closed_by: skifli author: skifli 2026-09-08T20:29 milestoned 2026-09-08T20:29 assigned 2026-09-08T20:29 labeled 2026-09-08T20:29 issue_type_added 2026-09-08T20:35 cross-referenced https://github.com/NixOnFyde/fyde-nix/pull/25 2026-09-08T20:36 closed === commits 2026-09-06..12 touching bcmdhd/brcmfmac/wpa === 2026-09-08 e8f207a4 fix(wifi): drive `AP6275P` via `brcmfmac` === any file in the repo mentioning bcmdhd/brcmfmac === Shell cwd was reset to /home/rich-defrese/homelab-notes ah the netherlands Found it. Someone did hit this two weeks before you, and what they did with it is the whole answer. Bash Record the prior sighting and the posted nudge in memory IN M=/home/XXXXXXX/.claude/projects/-homeXXXXXXXX-homelab-notes/memory/plaid-wifi-rsnxe-deauth13.md; cat >> "$M" <<'EOF' - **Prior sighting found 2026-09-27:** NixOnFyde/fyde-nix issue #24 "WPA3 / SAE networks do not work" (FydeTab Duo, RK3588S + AP6275P, NixOS = wpa_supplicant 2.11), opened AND closed 2026-09-08 by the maintainer in 7 min via PR #25 / commit e8f207a4 "fix(wifi): drive AP6275P via brcmfmac" — routed around the vendor driver, no root cause, nothing reported to Rockchip/Armbian. Two weeks before our find. Cite it in the Rockchip/Orange Pi issues as independent confirmation. Also: Orange Pi's own current 5 image is still Ubuntu **jammy** (Orangepi5_1.2.2_ubuntu_jammy_server_linux6.1.99.img, per basically source/sorter-v2 #840) → wpa_supplicant 2.10 → cannot trigger. The 5B can't take the brcmfmac escape route on mainline (upstream DT doesn't wire the radios, [[rk3588-distro-kernel-formats]]), which is why we fixed instead of routed around. - **PR #561 nudge posted 2026-09-27** (comment 5862017865): reach across vendor trees + shipping images affected + 5 GHz test + a "scope" paragraph (fails closed; non-conforming-AP path untested, not a claimed vuln) + AI-disclosure line. Leak-scanned, posted as defcom5-rockchip with G-Man's OK. EOF echo saved OUT saved Here's the concrete answer to "why doesn't anyone else see it". Someone did, two weeks before you. A NixOS build for the FydeTab Duo, a Rockchip tablet with the same AP6275P radio, got the issue "WPA3 / SAE networks do not work" on September 8. NixOS ships wpa_supplicant 2.11, so it tripped the same bug. The maintainer's fix took seven minutes: switch the radio to the mainline Broadcom driver and drop the vendor one. Issue closed, no root cause, nothing sent to Rockchip or Armbian. That's the pattern in one line: people route around it, they don't fix it, so the owners never hear. Why routing around it doesn't work for you. That tablet has a proper mainline device tree, so the mainline driver just works. The Orange Pi 5B doesn't. Upstream Linux doesn't wire the 5B's radios yet, so you're stuck on the vendor driver. You couldn't take the escape route, so you were the first person forced to actually fix it. Why the commercial boards can't even trip it yet. Orange Pi's own current image for the 5 is still Ubuntu 22.04. Its login software is version 2.10, which sends the old value. It is physically impossible for that image to hit this bug, no matter how many other problems it has. Same for Debian 13, Ubuntu 24.04, and every Armbian release except 26.04. The bug lives in the future of their software stack, and their stacks are frozen in the past. Who Why they don't see it Orange Pi, Radxa, most vendors Ship Ubuntu 22.04 or 24.04. Wrong version to trigger. Android products Google compiles the trigger out for these chips. NixOS, Arch, rolling distros Hit it, then switch to the mainline driver and move on. Wired kiosks, WPA2 sites Never touch the WPA3 code path. You Newest Ubuntu, real WPA3 network, and a board that can't escape the vendor driver. So it isn't that they post other problems and ignore this one. They post the problems that exist on what they run. This one doesn't exist there yet. You're about a year ahead of the field, and the first one who couldn't walk away from it. For the Rockchip and Orange Pi issues, the FydeTab report is worth citing as independent confirmation. It shows the same failure on a different board with the same radio and driver. I've saved it, and I'll pull it into the drafts when you're ready for those. Edited September 28Sep 28 by defcom5-rockchip
October 3Oct 3 Author Solution RELEASED Pi-Desktop 4.0 "Plaid" — a GNOME desktop image for the Orange Pi 5B, built on Armbian. Pi-Desktop 4.0 is out. It is an Orange Pi 5B desktop image built with the Armbian build framework on Armbian's Rockchip vendor kernel 6.1.172, with eleven patches of my own applied through userpatches. Armbian owns the boot chain, U-Boot, partitions, kernel branch, device trees, firmware, board support and the first-boot resize, and everything I add is a userspace layer applied through the late image hook. Posting it here because several of the fixes are Armbian-wide and may save someone a day. Fixed, with the cause if you want it: WPA3 and WPA2/WPA3 networks were refused on the vendor Wi-Fi driver with wpa_supplicant 2.11 (deauth reason 13). The driver handles only the older WPA version signal; 2.11 signals WPA3 a new way, so the driver fell through to "no WPA" and the firmware attempted an open association carrying a WPA3 security tag. Ten lines, sent upstream as armbian/linux-rockchip#561. The same gap is in bcmdhd-dkms for mainline-kernel images. Every GUI password prompt hung on Ubuntu 26.04 with any 6.1 kernel. polkit 127 runs its helper through a socket that needs a kernel feature from 6.5. Mask the socket, make the classic helper setuid, done. Affects Debian sid and forky too, not trixie. Bluetooth audio stuttered whenever Wi-Fi was busy. The AP6275P shares one antenna path between the two radios, and the vendor NVRAM leaves the coexistence timing at its defaults. Three values in /lib/firmware/ap6275p/nvram_AP6275P.txt give Bluetooth long enough slots to keep an A2DP stream intact: btc_params8=0x4e20, btc_params1=0x7530, btc_params50=0x972c. The file is diverted so an armbian-firmware upgrade cannot quietly drop them. Note the driver here is bcmdhd, so the file that matters is the ap6275p NVRAM, not brcm/brcmfmac43752-pcie.txt, which never gets loaded. 4K at 120 Hz, three separate faults: black screens after minutes to hours, a hard hang on screen-off and wake, and a black screen after a monitor power-cycle. A big file copy could kill the whole desktop session, through the system's out-of-memory handling and a misplaced cgroup. Bluetooth speakers muted for ten seconds at every YouTube ad. The 3.5 mm jack was silent: the vendor codec driver keeps its headphone switch off by default. Added: a screensaver service instead of screen blanking, first-click installers for seven apps with pinned keys, a computer-name prompt at first login, Open in Terminator in Files, Log Out back in the power menu, Rhythmbox 3.5.1, Brasero, and mpv profiles that stop DVDs stuttering at 120 Hz. Everything is published: the full recipe as an Armbian userpatches layer you can drop into your own build tree, the kernel source as a tag with the eleven patches applied, the complete corresponding-source table, and a known-issues file that says what is still rough. Images, notes and the recipe: https://defcom5-rockchip.github.io/pi-desktop/ An LLM assistant (Claude) worked on this with me throughout, including the driver analysis behind the fixes above; the hardware testing (and Pissed off Wifi Slop) is mine. I asked Claude to rate the severity of the WPA3 bug. Medium. Here's the reasoning across the two axes that matter. As a security issue: low. It fails closed. The board can't join, the router is untouched, nothing leaks. We traced that through the driver, the kernel, the login software and the network manager. It isn't CVE-grade and claiming otherwise would cost credibility. As a defect: high. On an affected system the board cannot join a modern home network at all. Wi-Fi is not a feature you can route around, the symptom looks like a wrong password, and nothing in the logs points at the driver. Every user on that combination is blocked. Net: medium, trending up. For the Jellyfin people. The video driver on this image is my own: rockchip-vaapi 2.2.0, built on Rockchip's MPP, published at defcom5-rockchip/rockchip-vaapi. I measured it on the release image rather than trusting what browsers claim about themselves, with a 4K HEVC Main 10 file played full-screen for 20 seconds. Chromium, which ships in the image, decoded it on the video engine: 595 frames, zero dropped, about 10% of the CPU. The board stays cool and idle-quiet doing 4K 10-bit. That means Jellyfin's web client direct-plays 4K Main 10 here, no server transcode, and you do not have to install anything first. Chrome is the same engine with the same flags once you install it. 8-bit HEVC, H.264 and VP9 ride the same path. Two honest caveats, because they will bite you otherwise: Firefox is the wrong browser for video on this image. Same file, same machine: 26 dropped frames and 350% CPU across its processes. Its own decoder log says IsHardwareAccelerated=false, and no Firefox process loads libva at all, so it never even attempts the hardware path. Not Armbian's build, not the sandbox, not dmabuf detection, all tested and ruled out. Firefox hardware decode is the headline feature I am aiming at for the next release. HDR files play but look pale in either browser, because neither does HDR tone mapping on Linux. mpv is the right player for those, and it goes through the same driver. AV1 is software everywhere; this chip's AV1 block has no browser path yet. If you run Jellyfin on an Orange Pi 5B, the short version is: use Chromium or Chrome, point it at your server, and your 10-bit library direct-plays on a board that costs less than the transcode licence you were about to avoid. (We had firefox playing 10 bit but not 8 bit) due to my unhinged wifi rant and the Firefox licensing it got yanked.) see you on Plaid 4.5 "Union Of Plaid Penguins For A Slop Free Environment" defcom5-rockchip Edited October 4Oct 4 by defcom5-rockchip admittance
October 4Oct 4 Author FYI I sent Jellyfin A PR a while back ... was immediately refuted. and dismissed. running Fable 5.1 with 2 agents extra high... like me ah oh this is big... new topic!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.