I've happily been running OpenWRT on a $30 Wi-Fi access point (Netgear EX3700) for 3 years now, after I ultimately got tired of the unideal situation with OpenBSD's Wi-Fi support/performance. I run the access point in bridged mode as a wireless VLAN extension for the unmanaged Ethernet switch it's plugged into. Never gone quirky on me despite months of uptime, and has no problems saturating 100 Mbit/s.
I personally run an OpenWRT Wi-Fi access point and OpenBSD router. The max download speed I get from my ISP is 350Mbps and the router is able to handle that. But yes, WiFi on OpenBSD is something which is not really a good option right now.
Consumer network devices do routing in software (with a few exceptions), so the OEM's intentions for whether a device should be a router, access point, or range extender are meaningless when the software has been replaced with OpenWRT. At worst, you end up with a router that has an inconvenient number of interfaces.
A range extender may not have an Ethernet port labeled "WAN", but that doesn't prevent you from using one of its "LAN" ports for that purpose. Likewise, if you want to take a device sold as a router and use it only as an extra access point within your network, you can repurpose its WAN port as an extra LAN port, or go for more complex network configurations where you use the router's built-in switch as a VLAN-capable managed switch.
It's only a range extender by Netgear's firmware design. The actual device is a bog standard SoC with Wi-Fi + Ethernet, so OpenWRT can turn it into anything, incl. a wireless router directly connected to WAN if need be. In my case I don't run it as a router, but as a wireless-to-Ethernet bridge into the rest of my LAN.
Ultimately, I'd way rather run a regular PC with good wifi hardware and Debian. But our wifi options are extremely extremely extremely slim. I tried to purchase some 802.11ax m.2 cards from a variety of alibaba et cetra sites & I got the run around & offered 4 year old shitty alternative products again and again and again.
So OpenWRT is pretty amazing. Incredibly hard work, incredibly good system, targeting so many different devices. The "uci" configuration system and "ubus" rpc layer are nearly unparalleled in software, have brought so many different systems under a consistent yoke & collar. OpenWRT is incredible.
But again it comes back to hardware. And wow what a tragedy we have been undergoing. It's a barren bereft world. There's really only one router, with a pretty mediocre MediaTek cpu/wireless chipset, that has 802.11ax support at all. Hopefully things swing around some & we figure out how to get operating systems installing atop more contemporary routers, but there have been so so so few advances, hardware has gotten so much more inaccessible. It makes me all the sadder that decent wifi addon cards are blanketly unavailable. Read it and weep, the forum thread on 802.11ax routers: https://forum.openwrt.org/t/802-11ax-routers/10484/354
I got a second openwrt router recently. It's been very interesting & surprising seeing how little cross-access point and cross-band steering clients do. I'm literally compiling openwrt fresh today, as I work on this problem, with some fresh new software systems that have only just cropped up in OpenWRT land. For a while OpenWRT had nothing, but we're finally developing some acumen for using multiple access points and that's so necessary & so great. I've grown more respect for the mesh based products that have taken over: not only do the routers have to mesh (and route across the mesh), but it's really up to them to steer clients ("stations") to the best access point: the problem is bedevilling crazy hard.
> There's really only one router, with a pretty mediocre MediaTek cpu/wireless chipset, that has 802.11ax support at all
There are many MediaTek devices including UniFi 6 APs, but also in robimarko's dev branch, Qualcomm IPQ807x support is working very well. Modulo some kind of slow memory leak that seems to happen when an AP doesn't have clients :D but the "hard parts" are working. Speed is high on all radios, sysupgrade is working, thermal/clock management is working, there's even hardware offloads for NAT and other stuff I don't care about (I only use these devices as APs).
> There's really only one router, with a pretty mediocre MediaTek cpu/wireless chipset, that has 802.11ax support at all.
Why not go for a separate router and access point? I know its not for everyone, but it makes debugging stuff and tinkering so much easier. As a bonus, you can run a different router OS (like OPNSense).
I personally run a Mini-ITX PC ( ~200€ from used parts, but with 2.5G link) and an Ubiquiti AP WiFi 6 lite flashed with OpenWRT - it's around 100€ new, has great hardware and is supported.
this is pretty orthogonal to the discussion to me. i have a bunch of random linux computers already and my desire is that i could spread them over the house & have good access cards in each. that seems like it should be a pretty basic ask byt is pretty impossible & has been for a bit. i feel like we're
near to debating about the use of the word router, which doesnt seem fruitful, and doesnt impact my ask.
that's a pretty decent access point! it uses the one 802.11ax chipset which does have linux support, on mediatek chips. performance of mediatek cpus & mediatek wifi do not impress me but it is great that linksys, belkin, ubiquity all have some near $130 moderm wifi gear out that does, all in a, pretty well. hoping the rest of the world can compete! strong value. especially if we do decouple the router & ap (something i did until very recently), then some pretty good wifi counts for a lot!
> I'd way rather run a regular PC with good wifi hardware and Debian
I used to do something like this, but I found it to be (moderately) annoying to manage and keep updated. And I find it hard to justify running a PC 24/7 that draws many tens (or even more than 100?) of watts vs. purpose-built networking gear that draws much much less. Sure, I could build something with an eye toward low power consumption, but I still doubt I'd be able to do as well as most off-the-shelf networking gear.
> But again it comes back to hardware. And wow what a tragedy we have been undergoing.
Agree that the 11ax situation is terrible, but consider pretty much all WiFi support is terrible on Linux for a while after new hardware supporting new standards comes out. I'm hoping that this situation will just get better with time, though I do worry that manufacturers are locking these things down more and more and are becoming even more unfriendly toward open source than they have been previously... which has always been not great.
a modern business class mini pc generally runs low load around 10-15 watts. these could also serve double duty as home proxmox or other home systems, as they would have so many times more power under the hood. i manage & maintain plenty of home/personal linux systems so me to the only hard task is not being able to do so eith the same ease, simplicity, & control i have everywhere else.
i do think perhaps im being a little glum about the wifi situation, even though we havent seen new/better hardware supported on openwrt for near half a decade. not just a "new standards" lag. on the hopeful side, codesourcery & others are doing a much much better job helping to make official open source image building a stable replicable manageable process. yes, almost always on linux 4.14 and or gcc-4 or ehstever and this infuriates me a bit, feels like a waste. but there is also more mainlinelining going on, both with cpus and with wifi cards. in fact it's almost just too well supported, that the problem is, now, that there's still not available hardware that has the new chips. for whatever reason the draft spec hardware all seemed to have bad errata, low/no drivers. and we just havent seen modern platforms with both the newer cpus and the newer wifi. still just not much hardware in general, even though draft spec equipment has been around for i believe years. progress isnt totally like i want but definitely some good signs too, and some just regular old "it takes a long long time before most chips start making their way jnto products". kudos to the hardwork of many who have been mainlining your drivers. you are doong the right thing. the future is exciting.
Good point, there are quite a few "mini" models out there that are low-ish power and would work well for this sort of application, and would likely have the horsepower left over to do other things that someone might find useful.
I haven't been watching the Linux+wifi space all that much lately, but what you outline still does sound much better than the situation even a decade ago. I get that it's slow, and I totally sympathize with and share your frustration there. I'm running 11ac gear at home, but I'll be due for a new laptop before too long, and would like to start the 11ax upgrade process. Seeing that I might have to forego OpenWRT (or just wait an uncertain amount of extra time) isn't really fun.
I use a wifi router in bridge mode to provide the wifi capabilities using the stock firmware, and a NUC like device running Ubuntu with two ethernet interfaces to do everything else - NAT, DHCP, LAN DNS, firewall, etc...
I've thought about trying to do everything in the NUC, but at some point, just configuring it all is sorta a pain.
(1) It's wonderful how many things can OpenWRT do now, beyond basic routing; it can even run containers in the default build.
(2) It's interesting how much resources this requires now, though; 128MB RAM is recommended, and 64MB is barely sufficient. To fit into 32MB and run basic routing functionality, one needs to remove IPv6 from the custom configuration, for instance. Mere 15 years ago 16MB was almost plenty to run OpenWRT :)
I also wonder how much more compact a RAM footprint of a router can be if it only does routing, though competently: with IPv6, QoS, etc. Maybe it won't be much more compact even with a super-compact purpose-built kernel and network stack (not Linux).
> It's interesting how much resources this requires now, though; 128MB RAM is recommended, and 64MB is barely sufficient.
This is a performance point where general purpose Linux distributions ought to be competitive. The Debian project is really dropping the ball by not focusing a lot more on these use cases. Their debian-embedded working group used to lead worthwhile subprojects (known as EmDebian Grip/Crush/Baked) aimed at slimming down minimum requirements on all sorts of special-purpose hardware and even competing with the likes of Alpine and Void, but these have all gone nowhere. Hopefully they'll be picked up again since the mobile-phones use case is raising these same issues, albeit for other reasons.
A lot of consumer routers these days store the OS on NAND flash instead of NOR flash, and 1Gbit to 4Gbit capacities are common. One of Google Fiber's Network Box models has 2GByte (16Gbit) of NAND.
I'm running OpenWRT for a few years now and it's absolutely great for simple setups (and even quite complex ones for homes). It is also possible to flash recent Ubiquiti hardware with OpenWRT; an AP WiFi 6 Lite flashed with it makes for a cheap (~100€) WiFi 6 access point with great range.
I have a similar setup (older Ubiquiti AP-AC Pros), and for me it was just a dislike for Ubiquiti's cloud-connected/distributed management architecture. I don't want my network hardware phoning home or depending on the cloud or even other components on the local network for any functionality. (It's sorta similar to how I feel about Apple; I really like their hardware, but am not a big fan of their software.)
I also just in general trust an open source project (sure, I know, I haven't personally audited the source or the build process) over close-source manufacturer firmware.
Basically I sat down one day and wanted to add another WiFi network to my access point.
Since the previous time that I had to manage the AP, I had switched my laptop from Archlinux to Voidlinux.
I tried starting ubiquiti's stupidly over the top java based management daemon on my laptop in order to manage the access point (which I used because I don't own a smartphone and even if I did, I wouldn't want to run any proprietary applications on it). To my surprise the software relied on mongodb which basically no distro packages anymore because of their crazy license change. I tried to spend some time getting mongodb locally packaged for my laptop (I refuse to install software without the package manager backing it up) but compiling mongodb is apparently nontrivial and I couldn't get it to work.
So I gave up on getting that working and just put OpenWRT on it because it provided me with a nice simple command line interface as well as an optional web interface. I was also able to quickly cut down the firmware to the bare minimum as I just wanted to bridge WiFi interfaces to VLANs.
I had a minimal, reliable and easy to manage access point which has been running 24/7 since that day for the last 218 days without a single hiccup. I no longer stress about having to run some insane daemon when I want to modify the configuration of my access point.
The sister comment is pretty much right; I don't have much trust in Ubiquitis software at the moment. Additionally, I know and like the interface of OpenWRT and I don't want to run a separate management server.
This an exciting release for me. A few years ago, I bought a vastly overpowered (at least, for router purposes) x86 box with a bunch of ethernet interfaces, with the idea that I'd run OpenWRT on it and then deploy a few containers to it for extra services. Until this release, though, many of the kernel options needed to support containers weren't enabled on OpenWRT's default kernel. It was possible to pull off my original plan by doing a custom build, and the OpenWRT build system makes this very easy, but it's even easier to be able to just grab a pre-built release.
I've run OpenWRT in a VM before as a gateway to a set of other VMs on the host, but I'm skeptical about the performance implications of running it in a VM for my primary internet connection.
In general, I find VMs a huge pain to manage compared to containers. I don't run any VMs at home anymore, aside from firing a temporary one up from time to time to try out some random ISO.
vm performance is excellent, especially if you passthrough the nic. Use libvirt + kvm. It's pretty simple to use vms on standard distros. virt-manager is a good gui.
It’s still a whole other kernel and disk image to worry about, passthrough to get set up, etc. For the stuff I run at home, I want things to be as simple and and automated and reproducible and hands-off as possible. VMs feel too much like work. If I never have to edit libvirt XML again, I might die happy.
With Broadcom it always seems such a struggle (no mesh support, no RSN-IBSS, MAX MTU only 1500, driver issues), for all their wired and wireless gear I've encountered, that I gtfo quickly when I have the choice to not use that HW. Same with NVidia. Result: Hardly ever driver problems on Linux and Openwrt.
And everybody know it, but somehow these devices always are at the top of some consumer recommendation list, and people keep plugging rpi4s etc everywhere.
Wifi will always be hit or miss with Openwrt. The general advice is to use openwrt for routing and a separate access point that runs vendor firmware for wifi. Should you want everything in one device, R7800 is a well supported openwrt all-in-one device.
I have two Ubiquiti AP-AC Pro APs, and I've been running OpenWRT just fine on them for the past year and a half. Completely rock solid. I didn't do performance testing with the stock firmware, so I don't know if I get the same WiFi speeds, but what I do get is more than sufficient for my purposes.
Maybe other hardware doesn't work as well, but I think if you choose carefully, it's fine.
Wifi is only hit or miss because it's often difficult or impossible to tell when a vendor has silently swapped out the guts of a model and replaced them with Broadcom parts.
(As far as I know:) By sticking to the Vendor-supplied SDK kernel version, with ancient blobbed up 3.X Linux kernels, for architectures, where modern kernel/module/userspace (source) is not available.
Openwrt aims for "near-mainline" blob-free kernel, currently on 5.4, with 5.10 in current master for many architectures.
I can’t recommend the CM4 over anything with an actual switch built into it with network fabric providing CPU-free packet switching and forwarding. You also honestly don’t want something as important as your actual internet gateway to be some hacky thing that might or might not be supported in a few months or years, unless it's just for experimentation in which case knock yourself out.
That really depends on the used SOC, or how well its hardware features are supported under Linux, by non-BLOBs, preferrably.
Anything MARVELL should mostly do, usually. But that's not the cheapest segment anymore, so the people are hurting themselves by buying the common plastic trash. Or use DD-WRT instead of OpenWRT, because they give a shit about binary-blobs and integrate that however they see fit, because they prefer to be able to use everything the hardware supports, instead of having an almost brick running open-source.
I don't think any devices supported by OpenWRT, DD-WRT, VyOS, pfSense, etc support hardware-accelerated routing with QoS. If you know of one, let me know!
It is not always clear, but enabling QoS usually disables hardware offloading, for example with Ubiquiti devices[1] "Traffic to which QoS policies have been applied cannot also take advantage of the EdgeRouter's Offloading feature". The same is true for open source even with binary blobs. The chips simply can't do it.
Using QoS and implicitly disabling hardware offloading significantly drops the throughput as it becomes CPU bound. "Without offloading enabled, IPv4 traffic will be routed via the CPU and will be limited to around 300Mbps on the EdgeRouter Lite (ERLite-3). With offloading enabled, the throughput will be about 950Mbps." [1]
So they should be available. But about 400, instead of maybe 40 to 200 for some cheap plastic trash which melts or resets if you look at it the wrong way.
One downside to the Raspberry Pi (CM)4 is that it doesn't have hardware crypto. So it'd make a poor VPN machine. But otherwise I think it'd be fine. Some people are happy just using a regular Pi 4 connected to a VLAN-capable switch or with a USB adapter for the second NIC.
I recently bought a GL.iNet Brume. It's a nice tiny ARM machine I use as a wired-only router. /proc/cpuinfo confirms it supports hardware crypto...
...although I haven't set up a VPN on it yet. Downsides: the WAN and LAN0/LAN1 ports are all the same switch with only one network interface, so it'd be impossible to achieve >500Mbps full-duplex. (It's never come up for me; my Internet connection's too slow.) It's also a little pricy for what it is.
I might have tried the FriendlyELEC NanoPI R4S instead, which actually has two separate NICs. But if I'd ordered that I'd still be waiting for it...
One thing I don't care about: hardware NAT/routing offload. I think that's often unsupported by OpenWRT, and it's incompatible with SQM.
Concerning HW NAT/Offload support: the DSA support is (iiuc) supposed to be the framework, through which the offload functionalities will be implemented. There is a pull-request for DSA even for architectures as far back as ath79.
I haven't read into the specifics yet, but it sounds like nft-tables configuration will be translated to a eBPF program, that will then hook into network flows, and tell the switching HW/NPE over some side channel which accelerations to use and shortcuts to take.
But do I really want to trust a "Black Box Network Processing Engine" bolted onto my CPU, that can route packets entirely outside the realm of control of the main CPU?
I always wonder about intentional or unintentional "in-band debug features", when people mention, that they run their home-lan on the same switch as the WAN-Uplink. I mean, is there really a HW vendor, that we trust to get the switching logic 100% correct/secure/performant?
My understanding from the kernel docs [1] is that DSA is just for switching, not routing. Do you have a citation that suggests otherwise?
My GL.iNet Brume supports DSA on its switch with OpenWRT 21.02, as does my older Netgear WNDR3800.
I'm not sure there's any hardware/software combination out there that supports offloading NAT/routing with proper QoS. So I'm puzzled when people talk about the importance of offloading or suggest using machines with very low-power CPUs. The Brume is Dual-Core ARM Cortex-A53 @1.0GHz, which gets the job done for me, but I wouldn't want to go any slower than that.
The link you posted mentions "setting up offloads", and unifying the functionality of DSA and switchdev.
To me, DSA (as a "convenient" means to access/name/treat individual switch ports) is a prerequisite to enable usage of whatever Switch-Chip-Level-Offloads the switch chip supports. Without DSA, vendors had to use nasty hacks to make use of e.g. HWNAT, which is why there never was mainline support for these acceleration features.
HWNAT is a routing function, and many/most? switches of the last decade support that. But, OK, true, most of them will probably not be able to HWNAT "with proper QoS". But newer devices are not "just" a switch-chip, they contain a "Network processing engine", which is not a "fixed-function" device, but rather a "programmable" accelerator, that you could perhaps even "teach" how to do PPP, Encrption/VPN wrapping, and/or "offloading NAT/routing with proper QoS".
And now that DSA and eBPF are in mainline, using eBPF to generate a program/set_of_rules for the Ethernet acceleration device from your nftable-rules seems like the natural next step for me.
Or where do you see my reasoning go off the rails?
To paraphrase: you're saying that DSA doesn't support offloads, and most HW NATs don't do QoS, but newer hardware is capable of it, and you expect mainline Linux to make full use of it in the future with DSA.
No, I don't know of any problem in your reasoning. I'll look forward to that happening! I wasn't aware newer hardware was so flexible.
Yes, nearly: DSA currently only supports a few basic offloads, and all?/most of those only work on some of the supported DSA targets. I think, MT76xx devices are the most "advanced" in that respect right now. But nothing "advanced" like even pppoe-offloading (yet).
I just hope, "flexible" doesn't come with a large "Difficult-to-audit-caveat" side-dish. NPEs "governing" traffic could potentially substantially reduce the trust the user can have towards the platform.
I found a passively cooled x86 box that I run openwrt on. It's got 6 Intel gigabit NICs and I use Proxmox to virtualize guests. OpenWrt is one of those guests, as is Home Assistant which controls various home automation things. I posted about it on Reddit a while ago: https://www.reddit.com/r/homelab/comments/hzvfih/new_router_...
At the time it had much better hardware at a similar price to more popular brands like Protectli and Qotom. Not sure what the scene is currently, but there a bunch of similar offerings on AliExpress.
Why did you choose x86 openwrt over opnsense? I chose opnsense because it never occurred to me to run openwrt on not-a-consumer-router and now I'm wondering if I screwed up.
Like you, I run a single x86 box with a handful of guests for random stuff - including Home Assistant!
openwrt is/was better for fq_codel and cake which were linux things. There may also be other packages that you may find on one or the other. I make extensive use of vpn-policy-routing on openwrt which does selective routing over a few different vpn interfaces (wg, openconnect, etc.). Not sure if something like this exists in bsd land.
I did try opnsense, but found that I wanted wireguard more than any of the features it offered. At the time wireguard wasn't a built-in option, so went back to OpenWrt which I was already familiar with anyway from running it on Linksys routers.
I had a similar experience and ended up doing the same. OPNsense does include a userspace implementation of Wireguard, but is obviously inferior to what Linux already has. It ended up being that, how poorly the initial kernel space implementation was handled for FreeBSD and that I wanted Cake for QoS, which made me move back to OpenWRT.
I do want to ask though, has there been any downsides to using OpenWRT on x86?
I haven't really run into notable downsides. Installation was somewhat of a pain since I had to resize the partition (all of the prebuilt images assume small hardware), and all of the default packages are as minimal as possible - like busybox for userspace/shell. Upgrading on X86 is I guess possible (I haven't tried yet), but most of OpenWRT's upgrading instructions/support are geared towards reflashing firmware, not updating packages on ext4.
But, there are a bunch of available packages - coreutils, zsh/bash, etc., that can be installed as desired. In general OpenWRT is pretty set-it/forget-it for me.
If you want something fast and inexpensive than wait for OpenWRT build for Redmi AX6 / AX3600 WIFI routers. For now only manual build is available and some have to reboot from time to time due to memory leak.
Probably depends on how complex your setup will be. We are running a normal 1GB Pi4 with OpenWRT (trunk until now) for quite a while on a 1gbit down/500mbit up fibre uplink with SQM against bufferbloat. Unifi switches handle all VLAN related work, fibre uplink is on VLAN 7 mandated by the carrier, so PPPoE works with only one LAN port on the Pi4. Wifi is also unifi hardware.
Thanks to full duplex, clients are able to use the fibre uplink without slowdown. VPN is managed by a separate system, though we had some successful experiments with WireGuard. Both a colleague and I are running the exact same setup at home (with fibre uplink and VDSL).
It's a very capable and power efficient setup. I'd definitely go with a CM4+dual NIC board today.
If you're looking for a router that does NAT you're not going to beat a purpose built hardware board in terms of perf per dollar, especially only latency and jitter of the NAT.
If you're looking for a network connected server that happens to do a lot of packet processing you can go the rpi route but I'd still front the internet and rest of the home internet off a small cheap hardware box like the Hex.
I moved from an edgerouter4[1] to openwrt on a protectli fw4b. On my home gigabit fiber (centurylink) link, it has been great so far (performance, throughput, etc)!
[1]: Ubiquiti has had packet processing issues in the 2.x firmware series for what seems like forever, and lack of updates lately has prompted me to move to something that is arguably better anyway.
They can be modified, though not necessarily in a typical way. Also, CM4 implementations vary, and most interfaces on 3rd party boards can have MTU set as normal.
Hi, thanks for that correction. Do you have a keyword or 2 to google for "They can be modified, though not necessarily in a typical way." Or is that only or the CM, and not the normal RPI4?
I only found some quick&dirty patch, that seems to make MTU up to 2000 functional. But since the patch aims for 9018, and only gets 2000, that does not seem like the "right" solution.
TP-Link has to be one of the worst when it comes to privacy and features, but they've been offering 3 triband AC2200 mesh routers at Costco for a while for anywhere between $159 and $199.
If I could get OpenWRT working on something like those I'd be so happy.
Been running OpenWRT on routers for the better part of 5+ years now. I'm not crazy about some of the software being very minimal[0], and it sometimes takes a few tries[1], but it runs quite well on a Linksys 1900ac. Time for a weekend upgrade!
[0] Dropbear doesn't {didn't?} support ed25519 at the time I was using it for SSH, but it took me an afternoon of dead ends and "it's not DNS" feelings before I found that out.
[1] I know about the serial console, but I'd prefer a simple, direct access keyboard/mouse setup if I screw it up.
I'd like to express general caution with upgrading to 21.02 on Linksys WRT-series routers; the Marvell "open-source" firmware isn't truly open source (it has proprietary binary blobs) and development seems to have halted sometime in 2020.
Many users report Wi-Fi connectivity issues[0]. When I did an upgrade, I was unable to connect my laptop and Roomba to wifi, and had to rollback to 19.07.8.
Amazing ... I had just checked a few minutes before this post. I tried RC.1-4 and they were definitely improvements on 19.07 in terms of general feel, reduced need for weekly reboots etc.
It was an item on goals page and is listed under “Core components update” on release page.
Unless there is some particular feature that someone wants or a device enablement that only possible starting with a kernel version, do most users care?
I wonder, if DSA works correctly on all platforms in scenarios where MTU > 1500 is needed and/or encapsulations like Batman. Because both are problematic at least on ramips/mt7621 and RTL8380 for me. Better but still not not right with the current 5.10 testing kernel in master. Maybe related to the bug mentioned here: https://github.com/openwrt/openwrt/pull/4493
I was hoping, that 21.02.0 would still include that one.
In any case, many thanks for all the hard work to everybody involved!
I really wanted to have software that can be installed on some Linux computer that our customers would put on their network, and it would redirect DNS to our captive portal (web-hosted by us on the same machine or another machine on the local network) unless the MAC or IP address was whitelisted.
Macs, for example, can add "compname.local" to DHCP using Bonjour. Can I somehow use Wide-Area Bonjour or Zeroconf or something, to accomplish this?
I am not a network expert, all I want is to have a computer join the local network and run a DNS server, tell the router to forward all DNS requests there, and our DNS server will respond with our captive portal for any domain, so we can "take attendance" and checkins via wifi, and after people connect once, every time they walk into the room, their cookie will announce them to the captive portal, we register their attendance and then let the DNS pass through to whatever other DNS server they had.
PS: I guess this wouldn't work if they manually set DNS servers to be the IP address OpenDNS or something like that, right? What is the correct approach to captive portals in that case?
PPS: Why are captive portals so SLOW on every iPhone I ever owned? It takes like a minute or three to come up. What is causing the delays?
Has anyone got a guide for getting openwrt to tether to a 5G mobile hotspot for the upstream WAN? I've found one showing how to connect via USB, but I don't want to have to plug my phone in to my router to be able to use my phone's mobile data.
You can have OpenWRT act as a Wi-Fi client (you might need to install the wpa-supplicant package). At that point your wifi interface is connected and you can adjust the firewall/routing/IP configuration to mark it as "WAN".
OpenWrt doesn't use proprietary drivers and instead try to ships really recent kernel (21.02 ships 5.4, master has 5.10), so that might be why your particular model will never be supported. dd-wrt seems to be maintaining some eol kernel, I'm wondering for how long https://svn.dd-wrt.com/browser/src/linux/universal
