Oh, man. Apparently, he died a little over a month ago, and I just now found out about it from the latest OpenWrt Developer meeting notes. From what I can see, it looks like no one else posted about it here in that time, but better late than never. This man absolutely deserves some real thanks.

Täht was an instrumental developer in the fight against bufferbloat, an effort to reduce network latency and keep it consistently low under load. I don't know about you guys, but SQM traffic shapers like CAKE and its predecessor FQ-CoDel are one of the main reasons I use OpenWrt. Täht was an active contributor to the OpenWrt project (and previously to the CeroWrt research project, an OpenWrt fork where the anti-bufferbloat efforts began). I remember seeing his posts on the OpenWrt Developer mailing list, the OpenWrt forums, and Reddit, as well as YouTube videos such as his guest appearances on the FLOSS Weekly podcast.

See their recent episode about him and his work after his passing: https://www.youtube.com/watch?v=sRadBzgspeU

He was 59 years old. Dave, thank you. Your contributions to network performance and open-source were fantastic! This is a huge loss, and you will be sorely missed. Rest in peace.

I maintain LuCI Mobile. A recent post presented Yet Another LuCI App as a newly built OpenWrt manager. I need to clarify that it is derived directly from LuCI Mobile, and there is a serious licensing problem. This is easy to verify from Git:

• The repositories share the same history through commit 56e9aa4, which is authored by cogwheel0.

• At that point, LuCI Mobile’s README and LICENSE both specified GPLv3.

• The derived repository continued to identify itself as GPLv3 immediately before changing licenses.

• It then replaced GPLv3 with Apache-2.0.

• Its current NOTICE incorrectly claims that LuCI Mobile was MIT-licensed.

Forking, rebranding, modifying, and selling GPL software are allowed. The issue is that a distributed derivative must remain available under GPLv3 unless the copyright holder separately permits relicensing. I did not authorize changing this code to Apache-2.0 or distributing GPL-derived builds with a closed-source layer.

I am asking the maintainer to:
- Restore GPLv3 for the combined derivative work.
- Correct the false MIT statement.
- Provide corresponding source for every distributed build containing GPL-derived code.

I have no objection to the fork continuing, including as a commercial project, once it follows the license under which the code was provided.

From the mailing list:

OpenWrt: Changes to the Security Support Policy

The OpenWrt project is reducing the security support period for stable releases.

Previous policy: Each major release was supported for at least one year, or six months after the next major release, whichever was later.

New policy: Each major release will be supported until the next major release is published.

This means OpenWrt will provide security maintenance for the main development branch and only one stable release series at a time.

Impact on existing releases

OpenWrt 17.01, 18.06, 19.07, 21.02, 22.03, and 23.05 have been End of Life for a long time and contain many known, unpatched security vulnerabilities.

OpenWrt 24.10 reached End of Life in September 2026 and no longer receives security fixes. This remains unchanged.

OpenWrt 25.12 is the currently supported stable release and will receive security fixes until the next major release is published.

All users running OpenWrt 24.10 or older should upgrade to OpenWrt 25.12 as soon as possible. If your device is no longer supported by OpenWrt 25.12, we recommend replacing it with hardware that supports a maintained release.

The detailed policy is available at:

https://openwrt.org/docs/guide-developer/security

Security advisories

We will also stop maintaining the Security Advisories list in the OpenWrt wiki. Security fixes may instead be documented in release notes or GitHub Security Advisories.

Not every security fix receives a CVE identifier. Many vulnerabilities discovered internally are fixed without one. Tracking or backporting only CVE-related fixes is therefore insufficient to keep a release secure.

Why this change?

Maintaining older releases requires significant effort. OpenWrt release management is handled by a small group of volunteers in their spare time.

By reducing the number of supported releases, we can focus our limited resources on properly maintaining current versions.

We want to be transparent about these limitations rather than create a false sense of security by promising support we cannot reliably provide.

We strongly encourage all users to keep their OpenWrt installations up to date.

Have fun!

The OpenWrt Community

I just wanted to share my travel router build so my experience can help out any one else with a similar project going :)

3 WAN interfaces for maximum connectivity options: 🔴

• 1 Gbit RJ45 WAN Interface

• 802.11ax Wifi adaptor to connect to "Free" and "Open" wifi

• LTE/4G modem if none of the above is possible (Only limited data plan at the moment)

2 LAN interfaces: 🟢

• 1 Gbit RJ45 LAN Interface

• 802.11ac Wifi adaptor to act as access point

HARDWARE: ⚙️

• Raspberry Pi 5 - 2GB

• Raspberry Pi 5 Active Cooler

• SIM7600G-H-PCIE

• Waveshare PCIe TO MiniPCIe GbE USB3.2 HAT+

• Alfa Network Alfa USB-adapter AWUS036AXML (MediaTek MT7921AUN)

List of packages i added to the image: 📦

• kmod-usb-net-qmi-wwan (LTE Modem)

• uqmi (LTE Modem)

• luci-proto-qmi (LTE Modem)

• kmod-usb-net-rtl8152 (1 Gbit interface on the HAT)

• kmod-mt7921-common (USB Wifi adaptor)

• kmod-mt7921u (USB Wifi adaptor)

Here's some tips from various forums to help setup your rpi4 as an openwrt router (LAN only, no wireless)

FYI, I'm getting ~940mbps down and ~940mbps up off this setup with no sweat

Assuming you are going to run a dual nic setup, which gives you full gigabit pass-thru speeds.

Second NIC

For the second nic (use for WAN) grab one of these as the chipset is tested and works great: https://www.amazon.com/TP-Link-Foldable-Gigabit-Ethernet-Compatible/dp/B00YUU3KC6

OpenWrt Image

Download and write wulfy23's excellent openwrt image to the microsdhc card.

https://github.com/wulfy23/rpi4/tree/master/builds

You want one ending with “fac” and not “sys”

Configuring it all

1. As wulfy23's image will appear at 192.168.1.1, and the rpi4 are smart sensing ports, plugging your computer / laptop directly into onboard LAN port (not usb adapter) of the pi is probably easiest. Just a direct ethernet cable.

2. Open 192.168.1.1 in your browser, login using 'root' and no password

3. Time to configure it!

Assuming you're on a 192.168.1.1 network of course:

Network -> Interfaces

Select LAN and hit edit

• Protocol, Static IP - 192.168.1.1

• Bring up on Boot is checked

• ip4 netmask is 255.255.255.0

• Physical Settings 'tab' select "eth0"

At this point if you're using a pihole, and using pihole as your dhcp server:

• custom DNS servers - address of your pihole

• DHCP server tab - check 'ignore interface"

Hit SAVE

ADD NEW INTERFACE

Assuming you are simply a DHCP client of your ISP

• Name 'wan' all lowercase, just like that.

• Protocol - dhcp client

• Interface 'eth1'

• hit save

• Edit the wan now

• firewall settings, make sure firewall zone 'wan' was setup.

Hit 'save' and 'save and apply' from the main Interface screen

You should be able to swap it into where your existing router is, and turn your old router into a wireless access point.

Plug the onboard pi4 LAN port into your switch, and the USB adapter into your ISP's modem

When you're up and running don't forget to save a backup of your settings!

System -> Backup / Flash Firmware

Download backup -> click Generate Archive

update

I did get 1gbps symmetrical fiber and am running Speedtest Tracker on another rpi4 as a docker.

The spikes are just bad servers, not the pi

https://github.com/henrywhitaker3/Speedtest-Tracker

Click here for my results:

https://imgur.com/a/xQlHgmT

Click here for stress test results on a OC’d rpi4

https://www.reddit.com/r/raspberry_pi/comments/vbzjqe/400gb_data_transfer_1_hour_network_stress_test/

running wireguard results

https://www.reddit.com/r/WireGuard/comments/eeafds/wireguard_throughput_on_raspberry_pi_4/

loads under downloads

https://www.reddit.com/r/openwrt/comments/rckpwk/rpi4_gigabit_connection_realtime_load_chart/

OpenWRT is genuinely the best router firmware there is. I'll die on that hill. But every time a non-techie friend touched LuCI, I got a phone call. "What's a DHCP lease?" "Why are there four tabs for Wi-Fi?" "I think I broke the internet."

So I built UnTangled for OpenWRT — a modern web UI for OpenWRT that keeps all the power but doesn't feel like a spreadsheet designed by network engineers (lovingly).

The part I'm actually proud of:

It doesn't replace LuCI. It installs next to it at /untangled/. LuCI stays untouched at /. If you hate mine, you lose nothing.

It's basically impossible to lock yourself out. Risky changes (Wireless, WAN, Firewall, DMZ) apply with an auto-rollback timer. Fat-finger your firewall from across the house? The router quietly reverts it. No more "well, time to grab the ethernet cable and crawl behind the TV."

A ? next to every single setting that explains it in one plain sentence. My mom can reserve an IP. I still get a ⌘K command palette and "Advanced details" everywhere.

It's tiny. The whole UI is ~75 KB gzipped vs LuCI's several MB. No CDNs, no telemetry, no cloud account, no phoning home. The router never needs the internet to serve it.

Visual network map, per-device parental schedules, guest Wi-Fi, QoS/SQM to kill bufferbloat, WireGuard + OpenVPN (server and client), mesh Wi-Fi with proper 802.11r/k/v roaming set up like a consumer mesh, light/dark themes.

How it works under the hood (for the people who'll ask): it's just the UI. It reuses the backend you already have — UCI + ubus + rpcd + uhttpd — over JSON-RPC with standard session auth and rpcd ACLs. No extra daemon, GPL-2.0.

Try it with zero risk: there's a live demo with sample data that runs entirely in your browser — no router needed → https://bidhata.github.io/untangled/demo/

Honest disclaimer: it's beta. Every release is installed and exercised in real OpenWRT 23.05 + snapshot containers, but it has not been validated across a lot of physical routers yet — live radios and vendor Wi-Fi drivers vary. That's genuinely where I need help. If you run it, I'd love an issue with your model + what worked and what didn't.

Repo (install is literally copy-paste a few lines over SSH or LuCI's Custom Commands): https://github.com/bidhata/untangled . If you like it, please star my repo. More stars and feedback will be pushing me to work further.

I've been working on an Android app for managing OpenWrt routers from a phone, and I wanted to share it here and get some feedback from the community.

LuCI works really well, especially on a desktop, but I've found that some quick tasks can be a little inconvenient from a phone—checking bandwidth, seeing connected devices, checking system resources, toggling guest Wi-Fi, etc.

So I built Yet Another LuCI App, an Android companion app built with Flutter and Material 3.

The app is 100% ad-free. There are no cloud servers or analytics tracking involved. Router communication happens directly between the app and the router using OpenWrt's RPC endpoints, and credentials remain stored on the device.

What it currently supports

• Real-time system monitoring — CPU, RAM, Swap, disk usage, and live Rx/Tx bandwidth graphs.

• Connected devices — Combines DHCP leases, ARP entries, and active wireless stations into a single view, including IPv4/IPv6 addresses, vendor information, and Wi-Fi band indicators.

• Guest Wi-Fi — Create isolated guest networks and generate a Wi-Fi QR code for connecting devices.

• Parental controls & profiles — Group devices into profiles with scheduled access and domain blocking.

• OPKG + APK support — Automatically handles the traditional opkg package manager used by older OpenWrt releases and the newer apk package manager.

• Services & VPNs — Manage procd services and monitor interfaces for WireGuard, OpenVPN, Tailscale, and ZeroTier. Root cron jobs can also be edited.

• Sysupgrade backups — Validates backup archive headers and gzip data before uploading them to the router.

I also tried to make potentially powerfull operations a little harder to mess up:

• Self-device protection — Detects the phone's active IP/MAC address to help prevent accidentally blocking the device you're currently using.

• UCI rollback — If an RPC operation fails during a configuration change, the app attempts to revert the affected UCI changes.

Links

Google Play:
https://play.google.com/store/apps/details?id=com.nightcode.luci

GitHub:
https://github.com/nightcodex7/yala

I'm still actively working on it, so I'd particularly appreciate feedback from people who actually use OpenWrt.

If you try it, let me know what works, what doesn't, or which LuCI functionality you'd most like to see added.

PS: Update (September 2026) The licensing concern raised here has been fully addressed.

All 16 files from the original fork commit have been completely rewritten from scratch in a clean-room fashion — no GPL source code from luci-mobile remains in the codebase. The full remediation record, including what was rewritten and verification results, is documented in LICENSE_CHANGE.md.

Special thanks to cogwheel0 for the original luci-mobile concept and for raising this publicly — it pushed the project to be legally cleaner than it otherwise would have been.

PS: Update (v2.0.0 & Full GPLv3 Compliance)

I wanted to follow up here and address the concerns raised in the comments directly. I handled the initial licensing situation and my earlier responses poorly, and I apologize for that. Trying to debate license changes or claim rewrites instead of simply embracing GPL was the wrong move.

I took the community's feedback to heart and made things right:

1. **Proper GPLv3 Licensing & Attribution**: The project is now licensed 100% under GNU GPLv3 as a direct fork of `cogwheel0/luci-mobile`. Upstream credit and dual attribution to cogwheel0 have been properly set in the repository, LICENSE file, and README.

2. **Zero Paid Features / 100% Free**: To clear up some misunderstandings in the comments: the app has never had any paid features or paywalls, and it never will. Any optional donation links and payment endpoints have been completely removed from both the app and the codebase. There are no ads, no trackers, and no monetization whatsoever.

3. **Upstream Sync & v2.0.0 Release**: The codebase has been re-synced with upstream v1.2.1 alongside several fixes (resolved back-button app closing/black screen issues, fixed static DHCP lease deletion on OpenWrt RPC, restricted the UI palette strictly to Material You and Amber.

The project repository and community release are available on GitHub:

- Repository: https://github.com/nightcodex7/yala

- Release (v2.0.0): https://github.com/nightcodex7/yala/releases/tag/v2.0.0%2B220

Thanks to everyone who held me accountable and pointed me in the right direction.

Moved to a new country where the university network blocks WireGuard entirely, both UDP and TCP. I'm using a country-specific OpenVPN TCP profile from ProtonVPN, which automatically selects ports, including 443.

Picked up a Cudy TR3000 and configured it in WISP mode. Running OpenVPN TCP, I'm getting over 70 Mbps on a 100 Mbps line.

Very satisfied at this $42 price point, especially compared to the GL.iNet Wi-Fi 6 router priced at $120.

I have the GL.iNet Flint 1 and Beryl back home. Honestly, the Cudy isn’t bad at all!

UPDATED Nov 2026: Replaced AgustinLorenzo buils with ppe-nss

I previously made a post asking the community about the Linksys LN1301 Tri-Band AX4200 WiFi 6 Wireless Router. davidlucking made an excellent post on the OpenWRT forum summarizing everything you need to know about these units, and I've copied it below (and updated it for 2025):

There are two variants of the LN1301 router: Homewrk and MX4300. They have different bootlog, u-boot environments, and mtd maps and requires different OpenWRT builds. DO NOT rely on the labels on your device or shipping box to determine which one you have.

If your original firmware looks like this: OpenWrt support for Linksys MX4200 - #1332 by wmd, then your router is a MX4300.

If your original firmware looks like this: OpenWrt support for Linksys MX4200 - #1190 by Tour, then your router is a Homewrk.

Support for the MX4300 was added to OpenWRT on Dec 31, 2024, and the latest stable version can be found here.

Community member JuliusBairaktaris builds OpenWRT images for the MX4300 and other devices here with NSS support. You can find the build for the MX4300 here, for example. NSS support for OpenWRT offloads the network processing from the CPUs onto qualcomm proprietary cores. Due to the proprietary nature of the NSS code, we don't expect the changes to be added to mainline stable OpenWRT.

How to install OpenWRT for the first time:

1. Open Linksys Web UI - http://192.168.1.1/ or http://10.65.1.1/ depending on your setup.

2. Login with your admin password. The default password can be found on a sticker under the device.

3. To enter into the support mode, click on the “CA” link and the bottom of the page.

4. Open the “Connectivity” menu and upload the squash-factory image with the “Choose file” button.

5. Click start. Ignore all the prompts and warnings by click “yes” in all the popups.

6. The Wifi radios are turned off by default. To configure the router, you will need to connect your computer to the LAN port of the device.

If you don't have a graphical interface,

1. Connect the router to the internet.

2. SSH into the router: ssh 192.168.1.1

3. Run opkg update && okpg install luci

(As of this being merged, the following instructions may be out of date. Or they might not be related; I haven't looked into it)

The router has 2 firmware partitions. The above instructions will upload the OpenWRT firmware to your current partition and you can use that without modifying the second partition. If you want to load the OpenWRT onto the second partition, the instructions are:

1. SSH into the router: ssh 192.168.1.1

2. Check booted partition, by running: fw_printenv -n boot_part

3. SCP the squashfs-factory.bin onto the router.

4. If that command returns a "1", then you can install OpenWRT onto the alternate partition by running: mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq807x-linksys_mx4300-squashfs-factory.bin alt_kernel

5. If that command returns a "2", then you can install OpenWRT onto the primary partition by running: mtd -r -e kernel -n write openwrt-qualcommax-ipq807x-linksys_mx4300-squashfs-factory.bin kernel

If you mess up a partition, you can switch to the other one by power cycling the devices 3 times with less than 5 seconds between each power cycle.

If you want to go back to the original firmware at any point, you can download it here.

(source)

Some additional notes:

• Check out this thread to keep up to date on the latest developments for the MX4300, or to post if you need additional support.

• There has been mixed information on whether or not NSS makes a difference. Your can check the thread linked above to see some people's testing.

• DD-WRT has official support as well and apparently includes NSS as well. Here is their guide.

• If you are not interested in using custom firmware yet, these routers support mesh with the stock firmware, but the USB port is disabled.

The Cavium CN6640-SNIC10E is a dual-port 10GbE PCIe card that shows up on eBay for ~$15–20. It's an OEM "SmartNIC," an 8-core Octeon II SoC meant to run Cavium's vendor LiquidIO firmware. Problem: the stock liquidio driver basically doesn't work with these OEM boards (its flash-handshake boot model doesn't match), and secondhand cards tend to have bootloaders in a rough state. There's a good writeup of people hitting a wall on this back in 2021 on the OpenWrt forums. Both PCIe BARs would read back all-0xFF and the board looked architecturally dead as anything but LiquidIO.

Turns out that "BAR wall" is just unprogrammed PEM inbound registers, not a hardware limit. You can program them from the card side with plain u-boot write64 (no firmware needed) and open a full bidirectional PCIe channel.

On top of that I built:

- an OpenWrt image that runs on the card from RAM (nothing flashed, fully reversible)

- a reverse-engineered PCIe BAR2 shared-memory datapath between host and card

- an out-of-tree host kernel module (octnic) that registers the card as two independent Linux NICs, oct0/oct1

Result: line-rate 10GbE, TX at 9.7–9.8 Gb/s (zero-copy), RX at 8.1–8.8 Gb/s (DMA via the Octeon DPI engine), both ports live simultaneously on a DAC. Boots with no serial cable after a one-time provisioning step. A systemd service brings both NICs up automatically at boot, so day to day it's just a normal 10GbE card as far as the rest of the homelab is concerned.

No vendor NDA firmware anywhere in the stack, host OS untouched, and the whole thing is undoable if you want the card back to stock.

Repo (driver, boot tooling, docs): https://github.com/nicologiuliani6/cavium-cn6640-snic10e-octeon-ii-nic

Docs cover architecture, first-time flashing/provisioning over serial, usage, and full performance numbers if anyone wants to reproduce this on their own card.

Happy to answer questions. This took a fair bit of reverse engineering to get past the BAR wall so ask away if you're stuck on one of these boards.

If you want to help out (test on your own board, contribute code, whatever) open an issue or discussion on the repo. If you'd like to support the project, GitHub Sponsors is enabled there too.

UPDATE: new idea, Another interesting use case is running OpenWrt standalone directly on the card.

For around $13, you basically get a dual-port 10GbE SFP+ router, without needing a separate x86 machine. And with two or more of these, you could potentially build a pretty cheap multi-router failover setup.

That's actually one of the things I'd like to explore next.

I just got the update from the mailing list: https://lists.openwrt.org/mailman/listinfo/openwrt-announce

Hi all,

Recently I created and published an SSH-only OpenWrt installation guide and automated flasher for the Jio AX6000 (JIDU6J11 / Qualcomm IPQ50xx) router: https://github.com/themayankraut/Jio-AX6000-6J11-OpenWRT-SSH

A tech YouTuber running the channel THE_DIY_DADDY (youtube.com/@the_diy_daddy) downloaded my files, renamed the variables, added fake technical comments, bundled my pre-built firmware binaries, and published an entire video claiming it as his own work without permission or credit.

The Forensic Evidence

When inspecting his distributed ZIP (6j11_diy_daddy_autoflash.zip):

1. diy_daddy_flash.sh is my flash.sh line-for-line:

   • Same dual-slot active boot partition detection (grep -oE 'ubi\.mtd=[^ ]+' /proc/cmdline)

   • Same idle slot resolution (rootfs <-> rootfs_1)

   • Identical ubidetach, ubiformat, and post-write ubiattach volume validation

   • Identical U-Boot environment modification (_BOOTCMD, _MTDPARTS, mtdids=nand0=nand0)

   • Exact same background reboot workaround ( sleep 3; reboot ) </dev/null >/dev/null 2>&1 &

2. diy_daddy_autoflash_windows.bat is my flasher script:

   • Same PowerShell TCP reachability check

   • Exact same *factory.ubi wildcard dynamic resolution pattern

   • Identical certutil SHA-256 pre-calculation and validation

   • Exact same SCP transfer arguments and line-ending sanitization

3. The firmware binaries are identical:

   • openwrt-qualcommbe-ipq95xx-jiorouter_ax6000-jidu6j11-initramfs-factory.ubi

   • openwrt-qualcommbe-ipq95xx-jiorouter_ax6000-jidu6j11-squashfs-sysupgrade.bin Both have my custom naming convention and are identical to my GitHub releases.

The Most Absurd Part: The "Hardware Constants" Obfuscation

To make the script look original and technical, he scattered pseudo-hardware constants across the code with names like MEM_INIT, TCP_OPT, RSA_PAD, CRC_CHK, FW_REV, BAUD_RT, VOL_IDX, etc.

When you take the hex values and decode them:

• \x53\x75\x62\x73\x63 = "Subsc"

• \x72\x69\x62\x65\x20 = "ribe "

• \x74\x6f\x20\x54\x48 = "to TH"

• \x45\x5f\x44\x49\x59 = "E_DIY"

• \x5f\x44\x41\x44\x44 = "_DADD"

• \x59\x20\x63\x68\x61 = "Y cha"

• \x6e\x6e\x65\x6c\x3a = "nnel:"

• \x20\x79\x6f\x75\x74 = " yout"

• \x75\x62\x65\x2e\x63 = "ube.c"

• \x6f\x6d\x2f\x40\x74 = "om/@t"

• \x68\x65\x5f\x64\x69 = "he_di"

• \x79\x5f\x64\x61\x64 = "y_dad"

• \x64\x79 = "dy"

Full decoded string:

"Subscribe to THE_DIY_DADDY channel: youtube.com/@the_diy_daddy"

He literally hid a channel promotion string inside hex values to disguise plagiarism, then wrote a fake _verify_geometry() function that checks if the string length is 248 characters to pretend it's a "UBI sector boundary check"!

False Attribution

At the end of his script, he added: Credit: A special thanks to MAHENDRA MALI. For the original script. No such person contributed to or authored this project. It was fabricated to deflect from the original repo.

Action Taken

• Official DMCA copyright removal request has been submitted to YouTube and is currently in review.

• Project is officially licensed under GNU GPL-3.0 on GitHub.

• Public notice issue tracked here: https://github.com/themayankraut/Jio-AX6000-6J11-OpenWRT-SSH/issues/1

Open-source hardware reverse engineering takes weeks of testing, bricking routers, and writing code. Don't let low-effort content creators hijack community work and pass it off as their own.

Full disclosure: Agentic coding was definitely used here, but otherwise, under my full command. No AI used while writing this post.

TLDR: Having two or more openwrt APs made me want something that makes me view my entire network status in a single pane of glass, UniFi style.

So yes, this has been brewing for a while and it started when I realised, I have three access points and if I want to see network overview of our entire network, I have to open three firefox windows. And then I also typically use iftop to investigate what devices eat the most data, etc.

Then, since my network infrastructure has an OpenWrt edge-router as well that runs as an lxd container, i thought to myself, why not use packet capture so it can categorise traffic.

For this I let claude write a go-based ndpi collector. The job is to count data usage, independent of the metrics / single pane of glass control pane. I then manually verified findings, investigated CPU usage and memory usage, etc.

Anyways, I wonder if I should (better) add router control so, for example, you can kick clients off APs, remote openwrt settings configuration so it will be something like unifi controller, etc.

Currently I am cleaning crap away off the repository and preparing for a public release. Yes, it will be open source. For now, what are your thoughts about it?

I run a BananaPi R3 (full size) as my home router, when I needed a router for my boat (networking sensors and smarthome controls, as well as remote monitoring) the r3-mini seemed an obvious choice.

It took me a while to figure out installation of openwrt (I got it to work just before openwrt added the mini to the baseline) but I've been very happy so far!

I have installed a Quecetel EC25g that I chose for it's price and compatibility (I found a kit on eBay that included antennae for ~$50). It was a little tricky to get working but again, very happy with it and with T-Mobile's $10/month plan. It provides data for the boat when underway (with better reception of course than my phone) as well as GNSS localisation for instrumentation.

I wrote a Python daemon to manage the modem, including a control-over-sms system for the boat and the router that I'm also quite proud of.

I've been through a few revs of the case and I'm really happy with where I've ended up. I'm pleased to have kept it compact while still including all of the features that I need.