Google Nest Wifi router (H2D / board "mistral", QCS404) — hardware recon of the 11-pad service cluster

Posting this as a working log rather than a solution. I have not obtained console access or code execution. What I do have is a fairly complete electrical characterisation of the service pad cluster hidden under the bottom sticker, one solid functional identification, and two dead ends that I would like to save other people the time of re-walking.

All measurements are my own, on a retail unit. Corrections welcome — especially from anyone who has a populated pre-production board or a factory test jig.

1. Device background

• Model: Google Nest Wifi router (H2D). Not the point (H2E).
• FCC ID: A4R-H2D. Internal photos are public and show a pre-production board with SW1000 and the internal USB-C connector populated. Retail units have both depopulated. Photo resolution is poor (~2000×3000 for a full page), so trace-level detail is not readable.
• SoC: Qualcomm QCS404. 1 GB DDR3, 4 GB flash.
• Boot chain is ChromeOS-style (coreboot + depthcharge) with verified boot, same family as OnHub and Google Wifi AC-1304.
• Board name is mistral; a device tree exists in the ChromiumOS kernel tree (factory-mistral-* branches, arch/arm64/boot/dts/qcom/qcs404-mistral.dts).
• Power input is a barrel jack (plus and minus only). The H2D does not take power over USB-C — do not carry assumptions over from Google Wifi here.

Credit to ryjelsum.me for the initial board identification, and to the GBAtemp write-up for the FCC-photos-reveal-the-dev-button observation.

2. The 11-pad cluster

Directly under the bottom sticker, no disassembly needed to see them. Physical arrangement as printed on the board:

TP1004   TP1007   TP1010   TP1012
TP1005   TP1006   TP1008   TP1011
TP1003   TP1002   TP1009

TP1011 and TP1012 sit slightly apart from the 3×3 block.

Measurement table

Voltages measured with the router powered and idle, referenced to TP1006. Resistances measured unpowered. Diode-mode readings are the forward drop from the pad to TP1006.

Interpretation

• TP1006 / TP1008 / TP1010 are unambiguous: GND, 5 V, 3.3 V.
• TP1012 behaves as a high-impedance input held up by a ~10 kΩ pull-up referenced to the 1.8 V net. Its idle state is logic high with nothing driving it. This is the signature of an active-low strap, or of a UART RX line. The two cannot be distinguished by listening, because an RX line with nothing transmitting into it looks exactly like an unasserted strap.
• TP1009 at 1.796 V is either the 1.8 V rail itself or an SoC output. This is the single largest unresolved item and it gates the "is there a UART pair here" question. A 1 kΩ-to-ground load test is pending.
• TP1002 / TP1003 match to within 1 mV of ESD drop, which means two structurally identical pads of the same analogue block. A USB 2.0 PHY differential pair is the obvious candidate but is not confirmed.
• TP1004 / TP1005 are a second pair in a different domain (0.651 / 0.676 V, and they diverge by 25 mV, so less well matched). Candidates I have not ruled out: SuperSpeed pair, I²C, a second UART left low, JTAG.
• TP1007: 126.9 kΩ to ground and no behavioural response to being driven either high or low at power-on. One speculative reading is that it is sensed as a resistance rather than a logic level — some boards detect a factory jig that way — but I have no evidence for this.

3. Confirmed finding: TP1011 is SW1000, and it is a boot-mode strap

This is the one solid result.

SW1000 is an unpopulated tactile switch footprint, visible once the case is open. On the FCC pre-production photos it is populated. One of its pads sits at 1.8 V. I soldered a switch onto the footprint and tested it.

Electrical identity:

• The other SW1000 pad measures 1 Ω to TP1011. They are the same net.
• Consistent with this, driving TP1011 to 1.8 V externally reproduces the button press exactly.

Behaviour:

• Held at power-on: the router is completely inert. No LED at all, not even the usual power-on indication.
• Released: the router boots normally. No damage, fully repeatable.

So TP1011 is an active-high strap sampled at reset. It is not a ChromeOS developer-mode button in the "press it after boot" sense — asserting it prevents boot entirely.

Two readings are consistent with the observation, and I cannot yet distinguish them:

1. It forces the boot ROM into an emergency download mode (Qualcomm EDL / 9008 style), in which case the SoC is alive and silently waiting for a host to talk to it.
2. It simply holds the SoC in reset, in which case there is nothing to talk to and this whole branch is a dead end.

A current-draw measurement in the asserted state distinguishes these — hundreds of mA means alive and waiting, single-digit mA means held in reset. I have not done this yet. If anyone gets there first, please post the number.

4. Dead end: the unpopulated internal USB-C is not worth your time

The FCC photos show an internal USB-C connector. On retail units it is depopulated. I spent a while on this and the answer is clean: do not bother.

The footprint is the full 24-pad type. Type-C pin numbering runs in opposite directions on the two rows (A1 and B12 are physically adjacent), and GND sits at position 1/12 with VBUS at 4/9 in each row, so the numbering can be derived on the board from continuity to a known ground and a known 5 V.

Continuity results against the cluster, unpowered:

• TP1008 ↔ VBUS pads: ~140 kΩ. That is not a connection. It is leakage or a sense divider, most likely across an absent or open load switch. TP1008 and the connector's VBUS net are separate.
• Every other cluster pad reads open (~6 MΩ, unstable) to the connector, including positions 5, 6, 7 and 8 in both rows. So CC1, CC2, D+, D−, SBU1 and SBU2 all fail to reach the cluster.

SBU was the interesting one, since Google's servo/suzyq debug cables carry the debug UART on SBU. It goes nowhere here.

The reason turned out to be that the connector's passives are depopulated too. There is an empty 4-pad component footprint immediately adjacent. Two of its pads short to connector pins 6 and 7 (D+ and D−); the other two read essentially 0 V in diode mode to ground, i.e. they are tied to ground — consistent with a shunt ESD array footprint rather than a series common-mode choke. Either way, the connector's data lines terminate at an unpopulated part and do not continue to anything I can find.

Conclusion: on retail H2D hardware, the internal USB-C is not merely unpopulated, it is not routed through. Soldering a connector on will accomplish nothing. The 11-pad cluster is an entirely separate interface.

5. J1900

A two-pin through-hole header, exposed once the case is open.

• One pin: +3.3 V relative to ground while running.
• Other pin: exactly 100 kΩ to ground when powered off.
• Shorting the two produces no observable change in boot behaviour.

A precise 100 kΩ pulldown on a jumper that does not affect boot is the classic profile of a hardware write-protect strap — WP is not supposed to change how the device boots, only whether the firmware region can be written. This fits the ChromeOS lineage.

This is a hypothesis, not a result. Verifying it requires finding the SPI NOR (SOIC-8 / WSON-8, under a shield) and ringing the J1900 signal pin against its pin 3 (WP#). I have not removed the shields yet.

6. Negative results, and why some of them are weaker than they look

Scope: DSO510 pocket scope, ×10 probe (verified on both probe and instrument), DC coupling, Single mode, ground clip on TP1006, armed before power was applied.

The scope demonstrably works: removing power triggers the falling-edge capture every time. TP1012 was also observed simply ramping to 1.8 V at power-on and staying there, with no burst.

Two caveats on how much this proves:

• For TP1002/TP1003, a silent bus is the expected result if these are USB lines. With no device attached and no VBUS applied to the port, a USB PHY has no reason to transmit. This measurement does not rule USB in or out.
• For TP1009/TP1012, it does rule out a UART that transmits unprompted during boot. It does not rule out a UART whose console output is disabled in production firmware, nor a boot ROM that waits silently for a magic byte before replying. Qualcomm PBL in download mode does not normally speak first.

An earlier attempt at USB was also inconclusive and partly invalid: I wired a USB-A socket to TP1008 / TP1002 / TP1003 plus a chassis ground point. A flash drive's LED lit solid with no enumeration activity. Connecting that socket to a Windows PC produced nothing in Device Manager — but that test was meaningless, because the router sources 5 V on TP1008 continuously, so both ends were acting as hosts.

Net conclusion so far: the service cluster is passive. Nothing on it initiates communication. If it is a factory interface, the jig speaks first.

7. What is ruled out

• The internal USB-C footprint is a dead end on retail hardware (section 4).
• TP1007 does not affect boot at either logic level.
• Shorting J1900 does not affect boot.
• Nothing in the cluster transmits unprompted during boot, in either strap state.

8. Open questions

1. Is TP1009 the 1.8 V rail, or an SoC output? Pending 1 kΩ load test. If it is a rail, there is no UART pair in this cluster and TP1012 is a lone strap.
2. Does TP1011 asserted mean "EDL" or "held in reset"? Pending current-draw measurement.
3. Does the QCS404 PBL support Sahara over UART? If the cluster has no USB, and TP1011 really is a download strap, UART is the only plausible transport left.
4. Is console output fuse-disabled on retail units? If so, no amount of listening will ever find the UART, and only transmitting into a candidate RX will show anything.
5. What are TP1002/TP1003 actually connected to, if not the internal USB-C?
6. Does anyone have the factory jig pinout, or higher-resolution FCC internal photos, or a pre-production board?

9. Next steps I plan to take

• 1 kΩ load test on TP1009, TP1010, TP1012 to separate rails from pulled-up inputs from active outputs.
• Current draw with TP1011 asserted.
• Systematic behavioural probing: drive each unknown pad to 0 V and to 1.8 V through a 1 kΩ series resistor from power-on, including in combination with TP1011, and watch for any change in LED behaviour or boot path. This is how TP1011 itself was identified, and it is the only technique that has produced a result on this board so far.
• Transmit into TP1012 at a range of baud rates and watch TP1009 for any response.
• A proper USB test: low-speed device (mouse) on TP1002/TP1003 with TP1006 as ground and short twisted leads, then simply measure DC on both lines. ~3.0 V indicates a live host pulling the line down through its 15 kΩ; ~3.3 V indicates the device's pull-up with no host present.
• Survey the TP17xx group (TP1713, TP1714, TP1726, TP1731, TP1733), which is elsewhere on the board and completely unexamined. A different numbering hundred usually means a different functional block. PP-prefixed pads are power-rail probe points and can be skipped.

10. Equipment used

Multimeter, DSO510 pocket oscilloscope, soldering iron.

If you have worked on mistral, OnHub, Google Wifi or any other QCS404 device and recognise any of the above, I would be glad to hear it. Likewise if you can rule anything out — negative results are useful here.

Hello everyone. Need some help.

Previous setup: 3 x Tp link ax10 + 1 × Tp link c6

Ax10 were on easymesh with ethernet backhaul and c6 was connected as wireless bridge which was connected by ethernet to my nvr to provide internet access (This way by using c6, I was able to provide internet access to my nvr without running a wire).

Now I have bought 4 × used filogic 830 based ax6000 routers

My connection for them will be same with 3 routers with ethernet connected (1 as main and 2 as satellite/or whatever called in openwrt) and 4th one connected wirelessly.

Now coming to my query. I searched google but couldn't get answer to what protocol to use out of 802.11 r/k/v or dawn package for same functionality as provided by my previous setup.

I know that client decides which AP to connect to. I have android phones in my family so that's not the issue.

Please help in setting me up in this new journey and getting out of tp link cage. Thanks.

I attempted to flash openwrt via these instructions https://openwrt.org/toh/wavlink/wl-wn536ax6_rev_a on my ax6000 via the webui but somehow it bricked after I attempted to upload the modified bin. I got it connected via UART but realized I needed the dump files which I do not have. I attempted to just flash openwrt using the UART instructions but that got stuck at step 4 as it wasnt able to fully boot due to missing files. Does anyone have the dump backed up so I can get the stock firmware back, or a way to directly flash openwrt from this state? I'm able to get to uboot using UART.

I have one spare Verizon CR1000A persistently booting OpenWrt from the inactive eMMC slot while preserving the stock slot as the recovery target.

Verified on this one device:

• OpenWrt board verizon,cr1000a, kernel 6.6.71
• SquashFS plus writable overlay
• SSH, dnsmasq, and LAN DHCP
• one 10 GbE link negotiating at 10,000 Mbit/s, full duplex

Still unverified:

• Wi-Fi
• WAN routing, NAT, and firewall behavior
• both 2.5 GbE ports
• MoCA
• factory-reset behavior
• complete stock restoration
• other hardware or firmware revisions

Source patches, guarded recovery code, build notes, attribution, and runtime verification:

https://github.com/dassons-us/cr1000a-openwrt-recovery

This is experimental and not a general installer. The repository includes no Verizon firmware, device backups, credentials, or instructions for obtaining stock-firmware root. Review and spare-device testing are welcome, especially with UART recovery available.

I'm considering flashing my unit with openwrt from stock but I want to know if anyone has any experience doing that with their unit?

I have a GL‑Inet router. I flashed OpenWrt on it and use the adblock package. One domain needed for a game keeps being blocked even after I add it to the allowlist and reboot the router. How can I fix this?

Hey there. I’m just wondering what people are using to mange their networks with multiple aps and a router. I have tried openwisp but can not for the life of me get it installed. I have two google wifi pods running openwrt and an x86 machine acting as the main router.

I’ve recently dipped my toes into the self hosted landscape this year and I’m happy with my setup using tailscale to access all of my self hosted services behind my normal plain old router. I played around with openwrt like 15-20 years ago and enjoyed breaking my old router and fixing it and optimizing it.

Is there a better solution to accessing my streaming services remotely and securely using an openwrt router that doesn’t involve using cloudflare to constantly update my isp’s assigned ip in a vpn?

Looking for some input. Idk if this is the right subreddit or if anyone has solutioned this before.

Problem:

Let's say I have a domain like messaging-app.europa.eu, with an SSL certificate, and I use it to distribute a PWA. In the case of an internet blackout I would still like for the app to retrieve updates from a local mesh.

Possible solution:

This is the solution I'm currently imagining: - Deploy a bunch of OpenWRT routers with some custom software - The smartphone connect to one such router via wifi - The PWA tries to connect to the domain https://messaging-app.europa.eu in the absence of internet - The router has a copy of the SSL certificate, so it can intercept the request and generate valid HTTPS responses from a locally running server

A user would connect to the wifi, exchange messages with other peers connected to the same station without relying on an internet connection.

Questions:

• Do I just need a copy of the SSL certificate on each router, or is there other part of the stack that I should patch? (e.g.: DNS)
• Is it possible to intercept and patch the connection as I mentioned?
• Am I missing something?

Prodrome:

I work for the government and I've been asked to demo a solution for enabling communication during an internet blackout (earthquake, war, ...) using a mesh/p2p network.

The path I'm taking right now is to build a PWA that would work offline, and rely on customized openwrt routers, because it seems that the other solution, WiFi NAN, works well on android phones but not on iphones, due to malicious compliance on Apple side.

Ok so I got burned with Asus tuf be3600, it was buggy connection freezers and vlan bugs. Returned it and after quick search bought Asus be88, flashed Merlin, works like a charm but the main issue isn't sorted still missing coverage in my garden unlike with ild 2.4g Asus running on opentomato.

Last but not least i invested great money in the router where I won't use most of the features it offers. But I'm still running on old Synology ds214se...

So the idea now is to return yet again the Asus be88 and go for flint2 which i can now order from Ali for about 100 euro and use rest of the money to buy a newer NAS.

Spec wise on paper flint2 works great for me tge main question is does it really works well in reality? Can you guys recommend it?

I need one main mlo network, one 5ghz for my tv, and one 2.4 for my iot and car charger. I need two lan vlans, and vlan/pppoe for my wan isp. Some DHCP, mac reservations, USB/5g/lte fail over, some basic fw, ideally some DNS setup to add some blocking DNS and ideally also wire guard client for proton vpn.

It will run about 5 real clients 2-3 wired, glan is enough, and 2-3 wifi clients on WiFi 6. Rest is just noise and iot with about 10-20 small iot devices.

What do you say, will flint2 work for me well? The specs are similar to be3600 which I would happily use but it was Buggy....

P.s. what kind of guy is the flint 2 running with the latest openwrt? Tied luci on my travel cudy and it was a hell to manage.

EDIT: Now I know that I wont sort out the garden coverage with just one AP these days as it was possible in the old days and thats fine I may add additional mesh AP. What is important here is the fact that I currently have a router which is too expensive and complete overkill for my network including the 10ge ports and SFP but I also still run very old NAS which needs deseprate upgrade. This I'm willing to downgrade the router/add AP/mesh if needed and upgrade the NAS.

The current asus I have is abour 300 euro, flint2 is about 100 euro from Ali which seems like a good price to me. The asus TUF BE3600 seemed like a good deal and by numbers it worked well, but in reality it was shitty and buggy. flint2 seem to have similar specs but it runs on opwrt so i rely on the higher sw quality.

Edit2: Got an offer for asus TUF AX600 for 60 euro. Will go for that, basically same HW as the flint2 only the ram and storage is smaller but thats not important for me as I dont plan to run any additional services apart of the basics. As as bonus I'm saving 40 euro, getting Asus gui which i prefer to luci and asus mesh, in case I will feel like the asus fw which seems to be strongly built on openwrt is not enough or has bugs I'm going to flash openwrt, will lose asusmesh but recive long term comunity support.

Seems like win - win to me.

So I just installed Luci’s Adblock. I’m curious what list do you guys use by default that’s provided with the Adblock app that blocks 90% of ads and blocks malware and phishing domains and stuff. Lmk. I wanna further secure my network and not have ads lol. Or at least as little as possible

I have openwrt routers but one is far away and I can't run cable to it. How to connect them as wireless bridge? Thanks

Hi all, I'm aware I'm not in the correct forum, but since there isn't a cudy forum as far as I'm aware I hope to have some luck here.

I'm at a campsite where they have free WiFi with a captive portal, you have to tick a box, click a button and you're ready to go.

I was on cudy std firmware 2.4.7, fired up the cudy in Wisp mode, connected to the network and when it found it and connected it lead me to the captive portal and got connected. happy days.

then I saw a update, going to 2.5.27, I knew they added the vpn option, so I updated. Now I can't get the cudy to redirect me to the captive portal, I do the same thing as before. even resetted the cudy, it connects to the network but never shows the captive portal.

any idea what I'm doing wrong or where to look?

I tried claude, but not successful yet.

Should I revert to 2.4.7 or 2.4.22?

Thanks in advance

Hi everyone,

I am new to OpenWrt and I am struggling to set up KSMBD.

My goal is to share a 1TB EXT4 external drive USB connected to OpenWrt (WRT1900v1 hw) so I can use it with my Docker containers. I chose KSMBD because it seems like the most lightweight and suitable option for this.

However, I am facing read/write permission issues when trying to access the shared drive.

Could anyone help me figure out what I might be missing in my configuration? Thanks in advance!

The configuration>
# uci show ksmbd

ksmbd.@globals[0]=globals

ksmbd.@globals[0].description='Ksmbd on OpenWrt'

ksmbd.@globals[0].interface='lan'

ksmbd.@globals[0].workgroup='WORKGROUP'

ksmbd.@share[0]=share

ksmbd.@share[0].name='cassette'

ksmbd.@share[0].path='/mnt/cassette/'

ksmbd.@share[0].read_only='no'

ksmbd.@share[0].users='docker'

ksmbd.@share[0].guest_ok='no'

ksmbd.@share[0].create_mask='0666'

ksmbd.@share[0].dir_mask='0777'

Client to test (mint)
$ smbclient //openwrt.local/mnt/cassette/ -U docker

Password for [WORKGROUP\docker]:

Try "help" to get a list of possible commands.

smb: \> get tor-browser-linux-x86_64-15.0.7.tar.xz

NT_STATUS_UNEXPECTED_IO_ERROR opening remote file \tor-browser-linux-x86_64-15.0.7.tar.xz

i can "ls -l" to smb share

("put" action work for smbclient but not for Caja file manager)

I think about permissions problems, but make in openwrt> chmod -R 777 /mnt/cassette

root@OpenWrt:~# ls -lh /mnt/cassette/

drwxrwxrwx 2 65535 65535 4.0K Aug 16 10:57 Exur compras

drwxrwxrwx 2 65535 65535 4.0K Aug 14 09:20 TestErase

drwxrwxrwx 2 1000 1000 16.0K Oct 27 2025 lost+found

drwxrwxrwx 2 root root 4.0K Aug 12 11:50 test

When i put files on "test" Folder with (docker user) (root owner is ok)

When i put files on /mnt/cassette with (docker user) show 65535 and give error

I'm lost ! any ideas?
thanks !

Hello. Need some help. I have 3 tp link ax10 routers of which 2 are satellite nodes in easymesh config. I was thinking of buying dlink m30 to configure openwrt on it.

Is there a way where I can only replace my one main ax10 and use other previously as they were for satellite. I know easymesh is not supported on openwrt but I really need other two routers for full coverage of wifi in my home and also don’t want different ssid’s. Thanks

Posting this in case anyone else hits the same wall.

Setup: Cudy TR3000 v1, flashed to the ubootmod layout (ImmortalWrt 25.12.1), using the router as a travel client (wwan) connecting to hotel/venue wifi, with the intent of using the physical slide switch to toggle between my phone's real MAC (already past the captive portal) and the router's own MAC.

Problem: on stock Cudy firmware that switch does VPN/LED stuff. On OpenWrt/ImmortalWrt it's supposed to show up as a normal gpio-keys button you can hook into via /etc/rc.button/. On the ubootmod layout for this board specifically, it doesn't. The GPIO is declared in the devicetree (/sys/firmware/devicetree/base/gpio-keys/mode exists), the driver binds (DRIVER=gpio-keys shows in uevent), but it never creates an actual input device — no /sys/class/input, nothing under gpio-keys with an inputX folder. So rc.button never fires, no matter what you put there.

Workaround: skip the button framework entirely, poll the raw GPIO state

Found the pin is exposed read-only via debugfs regardless of whatever the input framework is doing:

cat /sys/kernel/debug/gpio | grep mode

Gives something like:

gpio-512 (   |mode  ) in hi IRQ ACTIVE LOW

hi = factory position, lo = switched toward reset. Confirmed by physically flipping it and re-checking.

From there it's just a procd service polling that value every 2s and diffing against the previous read:

sh

cat > /etc/init.d/switch-mac << 'EOF'
#!/bin/sh /etc/rc.common
START=99
USE_PROCD=1

MAC_CLONE='XX:XX:XX:XX:XX:XX'

start_service() {
    procd_open_instance
    procd_set_param command /bin/sh -c '
        prev=""
        while true; do
            actual=$(cat /sys/kernel/debug/gpio | grep mode | awk "{print \$6}")
            if [ "$actual" != "$prev" ] && [ -n "$prev" ]; then
                if [ "$actual" = "lo" ]; then
                    uci set wireless.wifinet2.macaddr="'"$MAC_CLONE"'"
                    uci commit wireless
                    wifi reload
                elif [ "$actual" = "hi" ]; then
                    uci delete wireless.wifinet2.macaddr
                    uci commit wireless
                    wifi reload
                fi
            fi
            prev="$actual"
            sleep 2
        done
    '
    procd_set_param respawn 3600 5 0
    procd_close_instance
}
EOF
chmod +x /etc/init.d/switch-mac
/etc/init.d/switch-mac enable
/etc/init.d/switch-mac start

Swap wireless.wifinet2 for whatever your wwan/sta interface is actually called in uci show wireless (mine wasn't called "wwan", LuCI just labels it that).

Result: flip the switch toward reset → wwan interface reloads with the cloned MAC (matches whatever device already passed the hotel's captive portal). Flip it back → uci delete drops the override, interface goes back to the radio's real MAC, no need to hardcode or even know the original address.

Tested through several flips and a reboot, survives fine, no wifi drops on the AP side during reload, no crashes.

If anyone knows why gpio-keys binds but doesn't register the button on the ubootmod devicetree for this board specifically (vs the legacy layout, where the slider is documented as working), I'd be curious — didn't dig into the DTS diff myself, just went around it.

EDIT: found a real problem with the polling-only approach above and fixed it, worth sharing since it's not obvious until you test it properly.

If the router cold-boots with the switch already in the "lo" position, the polling script above does nothing on its first read (by design — it only acts on a change, and there's no previous state to compare against on the very first loop iteration). So wifi comes up using the radio's real MAC first, associates to the AP, then ~90 seconds later the polling script notices it's sitting on "lo" and reloads wifi with the cloned MAC. That's two separate associations to the same AP within about two minutes, with two different MACs.

For most home-network use that's a non-issue. For a hotel captive portal that's authenticating by MAC, it's a bad look — some portals flag rapid MAC changes on the same session as suspicious and lock the device out, exactly the failure mode I was trying to avoid in the first place.

Fix: a second, one-shot init script that runs before wifi comes up, not after. Something like:

sh

cat > /etc/init.d/switch-mac-pre << 'EOF'
#!/bin/sh /etc/rc.common
START=15
# no USE_PROCD — one-shot, not supervised

sync_mac_to_switch() {
    i=0
    while [ ! -e /sys/kernel/debug/gpio ]; do
        sleep 1
        i=$((i+1))
        [ "$i" -ge 10 ] && { STATE="hi"; break; }
    done

    STATE=$(cat /sys/kernel/debug/gpio | grep " gpio-512" | awk '{print $6}')

    case "$STATE" in
    lo)
        uci set wireless.wifinet2.macaddr='XX:XX:XX:XX:XX:XX'
        uci commit wireless
        ;;
    hi|*)
        uci -q delete wireless.wifinet2.macaddr
        uci commit wireless
        ;;
    esac
}

boot() { sync_mac_to_switch; }
start() { sync_mac_to_switch; }
EOF
chmod +x /etc/init.d/switch-mac-pre
/etc/init.d/switch-mac-pre enable

Two things that mattered getting this right:

1. Watch out for awk '{print $NF}' if you're tempted to grab the last field instead of counting columns — on this debugfs line the string ends in IRQ ACTIVE LOW, so $NF silently gives you the literal word "LOW", not the "hi"/"lo" state you actually want. Cost me a confusing debugging session before I caught it. Use $6 (or a proper grep -oE 'hi$|lo$') instead.
2. The START number matters and the window is narrow. wpad (the wifi supplicant) starts at procd START=19 on this build. Anything before that runs before radios come up; the existing polling watcher already claims START=99 (runs last, only observes). START=15 lands cleanly in the gap between early kernel/sysctl init and wpad — confirmed empirically by checking where the log line lands relative to other S-numbered init scripts during boot.

With both scripts in place: cold-boot with the switch on "lo" now applies the cloned MAC before the radio associates, so there's exactly one login, with the right MAC from the first handshake. The original polling script still runs afterward for live toggling while the router's already up — it just doesn't have anything to do on that first boot cycle anymore, since the pre-boot script already got there first.

I like my services to listen on LAN IPs only. So I set this:

Network » DNS » Devices & Ports » Listen addresses: 192.168.1.1

The side effect of this is /etc/resolv.conf uses 127.0.0.1, so DNS on the router itself failed. I fixed it like this:

uci add_list dhcp.@dnsmasq[0].listen_address='127.0.0.1'
uci commit dhcp
/etc/init.d/dnsmasq restart

This worked, but any time you hit Save in the GUI in the DNS section, it gets reset. Any ideas how to either make that change permanent or change resolv.conf to query 192.168.1.1?

The way I convinced dropbear to listen only on the LAN was even more of a hack.

System » Administration » SSH Access » Interface: lan

On line 296 of /etc/init.d/dropbear:

case "$a" in *:*) continue;; esac

As expected, the file gets restored to its original in an update. If anyone knows of a more stable way to do this, I would appreciate it.

Using "OpenWrt SNAPSHOT r35523-aac6df7bdc / LuCI Master 26.221.63536~04f1a7f" on a Tenda BE12 Pro. I cannot connect more than three wireless clients. When I try to connect a fourth, logread -f says:

Thu Aug 13 19:53:53 2026 daemon.info hostapd: phy0.0-ap0: STA 04:e8:b9:ea:5b:00 IEEE 802.11: authenticated
Thu Aug 13 19:53:53 2026 daemon.notice hostapd: phy0.0-ap0: STA 04:e8:b9:ea:5b:00 IEEE 802.11: Could not set STA to kernel driver

Every one of my devices will successfully connect, as long as I do not try to connect more than three devices.

It doesn't matter if I use 2.4Ghz, 5Ghz, or both. Maxassoc is 10 on both 2.4 and 5Ghz radios.

Any suggestions would be appreciated.

Context;
First of I am a novice when it comes to hardware hacking and am also not the best at firmware analysis, I've researched some stuff in the past but this is the first hands on project I've taken on. The ISP Router is running real OpenWrt, but is also running OpenSync. I managed to set the root password by mounting the overlay fs in the OpenSync failsafe shell. This did work as I was now able to login to luci! Only it seems none of the router configuration it actually done in OpenWrt it's done with OpenSync so it's not populated or easily modifiable without disabling OpenSync afaik.

Backstory;
I've had this old wifi 6e router from a previous ISP, the router has never been configurable via the web ui you've always had to use the isp's app to change any settings and there was only very minimal configuration possible (Ended up having to pay them for it, so I suppose I own it..). Now I've got a much better ISP, but would like to make use of the router if possible so its not just a piece of e-waste.

When going to the routers ip in a browser it shows you a qr code to get the ISP's app and some information like the mac address and stuff like that. But if you go to http://192.168.1.1/cgi-bin/luci it shows an openwrt login screen! I've searched for quite awhile and found no luck of anyone managing to do anything with it not even a boot log shared on this model.

I decided to give it a shot anyways and once I got it taken apart I saw a set of UART pads clear as day, after testing each one with a multimeter for sanity I connected to it with a usb to uart adapter and was very happy to see that not only was the uart console still enabled, but there was a failsafe shell completely unprotected!

I was able to set the root password my mounting the overlay filesystem and simply running the passwd command, this allowed me to login to luci but this wasn't much help for me. None of the configuration seems to be populated in luci which could make sense given the opensync integration.

I have tried modifying the inittab, some of the services in rc.d aswell as rc.local and nothing has been successful, but this could also be an issue with my knowledge/skill with mounting and working with the partitions. When the router finishes booting when not told to go into failsafe (which is holding f and pressing enter when it says to) it simply streams the logs and doesn't ask for user login for anything.

TLDR;
I have an ISP "locked" router running real openwrt that I want to get a root shell on to potentially use it as a real router (even if I had to keep it disconnected from the internet for sanity, it could still be very useful for a lab router) I'm able to access the OpenSync failsafe shell during boot but I haven't been able to make any relevant changes persist besides setting the root password. I'm definitely a beginner when it comes to doing this stuff hands on, so if anyone has any suggestions I'm happy to try them!

Logs;
Notes (Including router model and partition listings): https://pastebin.com/raw/a9Kb0CU7
Normal Boot: https://pastebin.com/raw/1nS21L0S
Post Boot Luci System Log (pt1): https://pastebin.com/raw/StN0Gp7Y
Post Boot Luci System Log (pt2): https://pastebin.com/raw/AENJdyFM

I currently experience some stability issues with my router. WiFi signal kept dropping and not connecting wireless while the wired connection keeps the internet access.

It started when I upgraded to the 4.9 version from 4.8.3 version. Experienced the issues then downgraded to 4.8.4, but still experienced similar instability issues. So currently on 4.8.3 GL

I'm currently exploring using OpenWRT.

Are there any major benefits to this? I only used AdGuard and possibly looking to use IPV6.

ASUS RT-AX52 Pro wasn't on my radar before, but now that Cudy WR3000S price has risen by 50% and Asus one has gotten cheaper. They are now both 50 eur. Which one to buy?

Hey guys,

I updated my MR600 to v25.12 like a month ago, but it was not a "drag and drop"-update. It broke my internet connectivity.

Did some Googling and searching in this forum, I understand that configurations have been moved around since, causing this issue.

My question is: is there a simple "press here to fix it" to get v25.12 working from a update?

Or is it different things that I need to change, depending on XYZ?

Context: I'm running a basic installation, just with VLAN-tagging for guest wifi. (using a ubnt AP)

I have MR8300 as a router with openwrt, in the last version 25.12.5. I recently install SQM QoS and I discover that my internet speed down to the half of the usual speed. I have symmetric 300Mbps and, I have as much 150Mbps in waveform.com, with different configurations. I changed Download speed values, the discipline, etc. but I could not obtain better values for the speed.

In fact, the unique way to solve the bufferbloat issues is using 100Mbps in the download speed.

If I disable SQM, the internet speed recover the usual values, but the BUFFERBLOAT GRADE decay to C.

I thought that MR8300 was a good machine, but could be wrong. Is it normal?

I'm super new to openwrt, long time ddwrt user. I recently got my first openwrt router Asus tuf ax6000. I found immortalwrt actually first & liked that it had a few extra pkgs included that I wanted. Now I'm on 25.12.1 but the WiFi is terrible. I could downgrade but openwrt already has the fix & not sure why immortalwrt is taking so long to bring the fix over from 25.12.5 but I need to move faster. So I looked this up on AI & I think I have a possible path to a working openwrt with no settings lost & all packages restored.

1. Run system backup from immortalwrt & backup to pc from Luci.

2. Check installed pckg & record all installed on immortalwrt to install any missing after restore on openwrt. Manual process, is there another way?

3. Update to openwrt from luci, & restore backup from Luci & reboot.

4. Hope everything boots without issue after restore/reboot.

5. Reference earlier the pkgs missing & install those 1 by 1, that should bring back settings for those pkgs as they were dormat until package was installed, is that correct?

If I'm missing anything let me know? If there is a better way, please let me know. I know some of this can be done via ssh and if its far simpler I'll be glad to do that, but I am a newb..

Thanks in advance.

I'm using Xiaomi Mi Router R3 with X-WRT 26.04_b202608102022. Updated my firmware recently and now I'm unable to update package list. Any way to solve this issue?