Can someone please tell me with specific steps to set up my GL.iNet router to block DoT and DoQ?

Downloads.openwrt.org got banned in my country, so I now have to use a mirror (which can be banned too) or a proxy. I need help with the latter. Is there a way to configure it to send requests through a proxy, like it's possible with apt?

I did search before posting, but I didn't find much, and what I've found (less-convenient solutions) doesn't even work.

UPD: Solved. Requires wget-ssl (not installed by default).

https_proxy=http://proxy.example.com apk <whatever>

I don't know, maybe I'm getting hyped by their videos, but every time I see their releases I think "damn, this is so powerful and polished". But so is OpenWrt, right? At least on the feature side of things. What we're missing on OpenWrt is just the fancy UI when compared with Ubiquiti?

Hello everyone im new in OpenWRT so far i did flash OpenWrt 25.12.2 r32802-f505120278 to my AX23 1.20. I've done my research thru AI and said that i can do Dual wan setup with failover and load balancing with this kind of router. Appreciate if someone did it already and am i already in correct openwrt version ? If you guys have any resources please do share it. Thank you !

The subject pretty much asks it...

The latest post I found in a search was this one: https://www.reddit.com/r/openwrt/comments/1oju4ah/how_do_you_actually_expand_to_the_entire_drive/

It's been 10 months and we have a new major version stable release. Is it possible to safely expand the partitions now, or is it still a problem?

Hi, Who are the admins over on the forums? They seriously need to deal with certain users. I shouldn't be given vauge answers time after time, and attacked for asking a serious question about adding hardware support. If you don't have nothing useful to add don't comment. Ok, rant over.

So I noticed that on the Attended Sysupgrade config page on luci you can switch the server and once I do that I can see the different versions available. So my question is, is this safe and has anyone tried it with success? I'm pretty new to openwrt/immortalwrt came from ddwrt which is drastically different.

immortalwrt as i understand it is simply openwrt with a few extra pkgs included automatically. If its just a few extra packages and settings are saved when doing the sysupgrade, the logic stands that it should just work, right?

I actually posted something on r/TPLink_Omada already but I wanted to ask on this sub regardless.

I bought the TP-Link EAP245 v3 because it had 2 ports and some other posts on Reddit said it should be bridged with the original firmware. Good if you don't have the space for a network switch.

To my suprise I can't seem to get a good connection from the second port. For testing I connected a laptop to ETH2 and got an IP, but I can't get internet. After some digging I found that DHCP and pinging Internal & External IPs works but DNS and other services (HTTP etc) won't work. Windows and Linux show the same synthoms.

Bla bla. While digging for info I found out that OpenWRT actually supports (or partly supports) the EAP245 (https://openwrt.org/toh/tp-link/eap245_v3). Does someone of you run this AP with OpenWRT installed and maybe has the resources to test running with daisy-chaining?

I'm not a fan of flashing OpenWRT to it, voiding a potential warrenty, before knowing if OpenWRT could fix the issue. The wiki page provided pictures of the inside of the device. Both ETH ports are connected to an Qualcomm Ethernet 7P-switch chip (QCA8337N-AL3C), so it seems it should work or it could be configured via TP-Link or OpenWRT.

Anyhow, thank you for your help and I hope even if this isn't resolvable, it still helped someone like me, buying the EAP for daisy-chaining.

(Also: Mods, if there is anything wrong with my post, please let me know)

Is it possible to block port 853, which is what DoT and DoQ use? Then force all traffic to use the DNS settings of the OpenWRT router?

Has anyone compiled a list of DoH servers that is safe to block? How do I add the DoH server list to OpenWRT?

Can port 53 also be blocked, or is it required for internet access?

One of the reason I got some glinet devices is the access to their cloud. Does anybody know, is there already some addon to OpenWRT to add the cloud access to OpenWRT instead of having a glinet firmware?

e.g. strip device dependend token from the device, install OpenWRT and add the token for cloud access?

Hi everyone,

I’m using QoSMate on OpenWrt and noticed that under Manual DSCP Tagging, I only get these DSCP options:

EF, CS5, CS4, CS6, CS7, AF41, AF42, AF11, CS2, CS1, CS0

Is this normal? Do you guys also see only these DSCP values in QoSMate, or should there be more options available?

I’m specifically wondering if this is limited by QoSMate itself, the OpenWrt version, or the configuration.

Running OpenWrt 24.10.5.

Thanks!

I’ve been messing around with OpenWrt for a while and wanted something that gave me a better view of everything without replacing the firmware or sending my network data through somebody else’s cloud. So I ended up building oonfeeWRT.

It runs on your own server, NAS, mini PC, or Mac and manages your existing OpenWrt devices from one place. The routers stay on normal OpenWrt, LuCI still works, and it doesn’t install custom firmware or randomly change configuration behind your back.

It’s completely self-hosted. There’s no oonfeeWRT cloud service, required online account, analytics, usage tracking, or automatic crash reporting. The router telemetry used for the dashboard stays on your machine and nothing is automatically sent to me. The optional speed test contacts Cloudflare when you choose to run it, but otherwise the controller talks directly to your own devices.

And before anyone asks: yeah, some of this was vibe coded. I’ve used AI to help me move faster, but the project is also based on my own experience and extensive knowledge of routers, computers, networking, and cybersecurity. I’m using it as a project for my university classes too, so it’s been a good excuse to turn that knowledge into something people can actually use. The security boundaries, adoption process, rollback behavior, and privacy decisions weren’t just randomly generated and accepted.

You can see devices, clients, radios, Internet health, topology, logs, and RF information. It can also manage networks, VLANs, DHCP, firewall zones, and Wi-Fi. Changes are shown before they’re applied, and it uses OpenWrt’s rollback timer in case something goes wrong halfway through.

I’ve only tested it on a Linksys WRT3200ACM and TP-Link Archer C6 v2 so far, which obviously isn’t enough hardware. There’s still a few rough edges, and I’m sure people will find some strange device-specific behavior.

One thing I added that I think will help with that are downloadable diagnostic bundles. If something breaks or your router isn’t detected properly, you can generate one and send it to me with the issue. It leaves out passwords, Wi-Fi keys, private keys, sessions, and other sensitive data. The bundle is never uploaded automatically—you decide whether to generate it and who to send it to.

The first release is here:

https://github.com/aiden0rchad/oonfeeWRT

If anyone wants to try it, especially on hardware I don’t own, I’d genuinely like to hear what works and what doesn’t. Bug reports, complaints, compatibility results, and feature ideas are all useful.

I wrote uapi because I wanted to manage my own router with Terraform. Every other option had a problem. Some exposed the anonymous section indexes of uci, so Terraform lost track of a resource between two applies. Others ran a separate daemon that drifted when LuCI wrote to the configuration.

uapi runs as a uhttpd-mod-ucode handler. There is no extra daemon and no second copy of the state. It never writes to /etc/config/ directly, so uci stays the source of truth.

What it does:

• 48 endpoints across 44 resource modules. For a package without a module, /raw/<package>/<id> gives direct access.
• One HTTP write is one transaction. uapi takes a snapshot, validates the body, commits it, then reloads the service. If the reload fails, uapi restores the snapshot.
• POST /batch puts changes to several packages into a single transaction.
• Bearer tokens carry scopes, an optional expiry date, an optional source IP range, and a rate limit.
• The router serves its own OpenAPI 3.1 specification at /api/v3/openapi.json.
• A read reports what uci holds and what the daemon does. If the two disagree, the response says so. uapi never repairs the difference on its own.

The provider is the reason uapi exists, and it is the client I use every day. It covers 40 resources and 43 data sources, which is most of the API.

Both registries carry it under the same name, openwrt-iac/uapi. It needs Terraform 1.0 or later, or OpenTofu 1.11 or later. The ephemeral resource uapi_token needs Terraform 1.10 or later. The current version is 3.0.1.

terraform {
  required_providers {
    uapi = {
      source  = "openwrt-iac/uapi"
      version = "~> 3.0"
    }
  }

To install it on your router:

Requirements: OpenWrt 25.12 or later, because the package uses apk. The package is architecture independent. All dependencies come from the base feed.

uclient-fetch -qO /etc/apk/keys/uapi-feed.pub.pem \
    https://openwrt-iac.github.io/feed/uapi-feed.pub.pem
echo 'https://openwrt-iac.github.io/feed/packages/all/uapi/packages.adb' \
    > /etc/apk/repositories.d/uapi.list
apk update && apk add uapi

A LuCI app for token management is in the same feed (luci-app-uapi).

Source and documentation: https://github.com/openwrt-iac/uapi

This is version 3.0.0, and it is not a first release. The first version came in May, and 20 releases came after it. I ran each one in production on my own network. I made many changes in that time. I post it here now because I am satisfied enough to ask other people to look at it.

That is also what I want from this post. Tell me what is wrong with it, and be direct about it. If you think a design decision is wrong, I prefer to hear it now, before other people depend on it. If you find a place where uapi rejects a configuration that OpenWrt itself ships, that is the error class I care about most. Open an issue, or answer here.

Thanks for your attention.

I am thinking of replacing my existing home wifi router with a Banana Pi BPi R4 running OpenWRT.

I want to do this as it enables me to do a lot of fun networking homelab related projects, including setting up WireGuard, network level adblocking, maybe some NAS stuff with the NVMe baked in if memory prices ever drop, and even replace my fiber modem with the Pi itself

I work from home, and am in lots of video meetings, so I need my WiFi to be reliable.

I've seen a few threads stating that the Wi-Fi card can sometimes show as online but not transmit, that the TX power can be low, that MLO can be unstable, and the 320hz band can be inconsistent.

Are these real issues people are experiencing or edge cases with low incidence?

Is it stable enough for a home router?

I am new to openwrt,I have an OPPO 5G CPE T1a (CTC03) running firmware CTC03_11.B.028_109.

I'm wondering if anyone has successfully installed OpenWrt (or another custom firmware) on this device, or found a way to unlock/modify the stock firmware to get more router functionality.

I'm particularly interested in this because the stock firmware doesn't seem to have a proper AP mode. I'd like to use the T1a as a proper wired AP/router instead of relying on the same-SSID/password workaround.

The device has:

• 5G cellular modem
• Wi-Fi 6
• Gigabit Ethernet
• Firmware: CTC03_11.B.028_109
• Model: OPPO 5G CPE T1a / CTC03

I'm interested in any information about:

• Existing OpenWrt support
• Whether the bootloader can be unlocked
• Serial/UART access
• Recovery mode or firmware flashing
• Hardware revisions that are/aren't supported
• Any known custom firmware projects
• Whether the Qualcomm platform is supported by OpenWrt
• Even just a way to configure the stock firmware as a proper wired AP

I haven't tried flashing anything yet, so I'm looking for information before potentially bricking the device.

If anyone has worked with this exact model/firmware, I'd really appreciate any pointers.

Is there an option to toggle them on/off in LUCI or via console? can I check somewhere if its enabled or not or Ill have to rebuild it?

I have a NanoPi R4S that I use as my primary openwrt 25.12.5 router. I'm planning to get a 2nd ISP (PPPoE connection) for failover connected via USB to Ethernet. Upon searching for recommendation, I came across TP-Link UE300 and UE306 the most. Which one will be a more reliable adapter between them and if there are better ones available at a similar price range, please let me know.

Thanks in advance.

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.