At the center of the WickedYoda homelab sits the GL.iNet GL-BE14000 (Flint 4), powered by MediaTek’s Filogic 880 (MT7988) quad-core Cortex-A53 processor and 2 GB of RAM. It runs a tailored OpenWrt 21.02 build on kernel 5.4.281, handling everything at the edge: NAT, a dual-WAN layout (1 Gbps fiber on eth2 paired with eth1.3 for failover), full VLAN segmentation, an inbound WireGuard server, and integrated Tailscale.
Hardware specs aside, what really stands out is the security hygiene and isolation model:
- Zero exposed WAN ports: Inbound management is completely blocked from the outside.
- Strict VLAN isolation: The firewall defaults to REJECT for forwarding, keeping Guest, IoT, Testing, and Work subnets isolated while blocking management access across non-management VLANs.
- DNS leak prevention: DNS requests are locked down across all zones to prevent ISP snooping.
- VPN & Wi-Fi coverage: Native UCI handles VPN kill-switches seamlessly, Wi-Fi 7 MLO spans 2.4, 5, and 6 GHz under a unified SSID, and a 57.9 GB f2fs overlay leaves plenty of breathing room for custom packages, scripts, and logs.
Overall, core routing and NAT perform reliably. However, a quick audit pulled up three specific configuration quirks that need attention before they turn into actual headaches:
1. The eth2 WAN APIPA Address (169.254.x.x)
Seeing a self-assigned 169.254.x.x APIPA address on eth2 is a red flag for the dual-WAN setup. If eth2 is supposed to be acting as a primary or secondary DHCP WAN link, it’s failing to grab a lease from the upstream handoff.
If mwan3 isn’t configured with strict ping tracking on eth2, it can get confused and attempt to route outbound traffic into a dead end.
- Next Step: Check physical layer connectivity, verify upstream DHCP, or explicitly drop
eth2out of the failover pool until the link gets a valid lease.
2. Unset Tailscale Upstream DNS
Tailscale is integrated and running fine, but leaving the upstream DNS resolvers unset in the Tailscale admin panel creates a split-brain DNS issue.
Depending on how individual client OSes fall back, tailnet nodes might bypass local DNS leak protections or fail to resolve internal lab hostnames entirely.
- Next Step: Set the Flint 4’s internal gateway IP as the global nameserver in the Tailscale admin console (or enable “Override local DNS”) so remote clients route queries back through the router’s secure resolver.
3. SQM Scoped Only to Work (VLAN 50)
Right now, Smart Queue Management (CAKE / FQ_CoDel) is only running on VLAN 50. While this protects work traffic from local congestion on that specific subnet, it doesn’t protect the underlying ISP pipe. A heavy download on the main LAN or a massive smart TV update on the IoT network can still saturate total WAN bandwidth, spiking latency for every subnet—including Work.
- Next Step: Move SQM off the sub-interface and apply it directly to the physical WAN interface, capped at ~90–95% of real-world ISP throughput. Since this OpenWrt build is driving high-speed Wi-Fi 7 hardware, keeping flow offloading tuned alongside CAKE will control bufferbloat without choking overall speeds.
Quick Reference:
| Attribute | Value |
| Hostname | RouterAlpha |
| Tailscale Name | router-alpha.tailnet-xyz.ts.net |
| Tailscale IP | 100.86.XXX.XXX |
| LAN IP | 10.0.84.1/16 |
| SSH | Port 122 (non-standard), key id_ed25519_router |
| Model | GL.iNet GL-BE14000 |
| SoC | MediaTek MT7988 (Filogic 880) |
| CPU | 4× ARMv8 Cortex-A53 (aarch64) |
| RAM | ~2 GB |
| Storage | 57.9 GB f2fs overlay |
| Firmware | OpenWrt 21.02-SNAPSHOT, kernel 5.4.281 |
Hardware Specs:
| Component | Detail |
| **Make/Model** | GL.iNet GL-BE14000 (“Flint 4”) |
| **Board** | glinet,gl-be14000 |
| **Target** | mediatek/mt7988 |
| **CPU Architecture** | aarch64_cortex-a53 |
| **Cores/Threads** | 4 × ARMv8 Processor rev 0 |
| **BogoMIPS** | 26.00 per core |
| **RAM** | 2,033,996 kB (~1.94 GiB) total; ~704 MB used, ~942 MB free, ~1.2 GB available (no swap) |
| **Root Storage** | /dev/loop0: 57.9 GiB f2fs overlay (/overlay) |
| **Read-only ROM** | /dev/root: 95.5 MiB squashfs |
| **TMP** | tmpfs: ~993 MiB |
| **Wireless Radios** | Tri-band: 2.4 GHz, 5 GHz, 6 GHz (WiFi 7, MLO supported) |
Firmware and OS:
| Property | Value |
| OpenWrt | 21.02-SNAPSHOT |
| Kernel | 5.4.281 |
| Build Taint | busybox override (normal for GL.iNet) |
| Timezone | CST6CDT, America/Chicago |
Physical Interfaces:
| Interface | State | Speed | Role |
| eth0 | UP | 10000 Mbps (10G) | LAN upstream |
| eth1 | UP | 10000 Mbps (10G) | Trunk carrying VLAN20/30/40/50 |
| eth2 | UP | 1000 Mbps (1G) | **WAN #1** (169.238.15.18/21) |
| eth1.3 | UP | — | **WAN #2** (10.120.34.198/24, DHCP) |
| lan5 | UP | 1000 Mbps | LAN switch port (bridged to br-lan) |
| lan6 | LOWERLAYERDOWN | — | Intended trunk uplink (check cabling) |
| lan7 | LOWERLAYERDOWN | — | Down at capture |
| lan8 | LOWERLAYERDOWN | — | Down at capture |
Bridge Info:
| Bridge | IP/Mask | Purpose | Notes |
| br-lan (VLAN1 untagged) | 10.0.84.1/16 | Main LAN | STP enabled |
| br-vlan20 | 192.168.20.1/24 | Guest VLAN | — |
| br-vlan30 | 192.168.30.1/24 | IoT + Cameras | Heaviest traffic VLAN |
| br-vlan40 | 172.23.2.1/24 | Testing VLAN | Isolated (DROP to LAN) |
| br-vlan50 | 192.168.50.1/24 | Work VLAN | Has SQM (CAKE) |
Radio Info:
| Radio | Band | Channel | Width | TX Power | SSID |
| ra2/ra0/ra15/ra3 | 2.4 GHz | 11 | 40 MHz | 28 dBm | DriveMeWild-MLO |
| rai2/rai0/rai1/rai3/rai15 | 5 GHz | 40 | 160 MHz | 25 dBm | DriveMeWild-MLO |
| rax2/rax15/rax0/rax1 | 6 GHz | 69 | 320 MHz | 24 dBm | DriveMeWild-MLO |
- MLO (Multi-Link Operation) is active across all three bands under a single SSID (‘DriveMeWild-MLO’).
- Repeater/client links (‘apclix0’, ‘apclii0’, ‘apcli0’) are configured with ‘4addr on’.
Weaknesses & Risk Areas
The main weak spot right now is QoS. SQM is only running on VLAN50 (Work) using a single CAKE instance, leaving high-bandwidth subnets like IoT (VLAN30) and the primary LAN unshaped on a 1 Gbps symmetric link. Worse, there’s a configuration mismatch: UCI is set for 900 Mbps on VLAN50, but the active qdisc reports a 650 Mbps ceiling, pointing to a hidden cap or GL.iNet script overriding settings behind the scenes. Tailscale DNS is also throwing SERVFAILs because upstream resolvers aren’t defined in the Tailscale admin panel, and netifyd occasionally overflows its netlink buffer. On the management side, using a shared SSH key across every GL.iNet device in the lab creates an unnecessary blast radius if a single node is compromised. Finally, that eth2 WAN picking up a 169.238.x.x address is non-standard and needs a quick sanity check against the ISP handoff.
Routing:
| Destination | Gateway | Device | Metric | Notes |
| default | 169.238.132.59 | eth2 | 1 | Primary WAN |
| default | 10.120.34.52 | eth1.3 | 4 | Secondary WAN |
| 10.0.0.0/16 | kernel | br-lan | — | LAN |
| 192.168.50.241/24 | kernel | br-vlan50 | — | Work |
| 192.168.30.220/24 | kernel | br-vlan30 | — | IoT |
| 172.23.2.223/24 | kernel | br-vlan40 | — | Testing |
| 192.168.20.143/24 | kernel | br-vlan20 | — | Guest |
| 192.168.32.138/24 | kernel | wgserver | — | WireGuard server pool |
| 100.118.97.77/10 | — | tailscale0 | — | Tailscale CGNAT |
| ::/0 | — | lo | 2147483647 | IPv6 blackhole |
VLAN Mapping:
| VLAN | Bridge | Subnet | Purpose |
| 1 (untagged) | br-lan | 10.0.84.167/16 | Main LAN |
| 20 | br-vlan20 | 192.168.20.124/24 | Guest |
| 30 | br-vlan30 | 192.168.30.49/24 | IoT + Cameras |
| 40 | br-vlan40 | 172.23.2.76/24 | Testing (isolated) |
| 50 | br-vlan50 | 192.168.50.187/24 | Work |
| — | br-guest | 192.168.89.0/24 | **Disabled** Guest |
| — | br-iot | 192.168.90.0/24 | **Disabled** IoT |
Performance & Observability
Day to day, the Flint 4 sits at a steady CPU load average around 3.5–3.8 across its four cores, with thermals hovering in a comfortable 57–59°C range. Interface throughput gets heavy on the primary WAN (eth2) and internal trunk (eth1), with VLAN30 (IoT and cameras) pushing the most internal traffic at nearly 5 GB uploaded over the monitoring window. Conntrack sits reliably around 3,300 active connections without breaking a sweat. For monitoring, the router feeds real-time interface metrics, Wi-Fi client counts, SQM statistics, thermals, and tunnel statuses over Tailscale into an external Telegraf/Grafana stack. It provides great visibility into the core, though beta firmware quirks like netifyd buffer warnings and Tailscale DNS SERVFAIL errors still pop up in the logs.
Performance:
| Metric | Value |
| Cores | 4× ARMv8 Cortex-A53 |
| Load Average (1/5/15 min) | **3.57 / 3.85 / 3.80** |
| Uptime | ~10 hours at capture |
Top CPU Consumers:
| PID | CPU % | VSZ | Command |
| tailscaled | 16459 | 0% | 1.3 GiB |
| dnsproxy | 21372 | 0% | 1.2 GiB |
| dnsproxy (wgclient1) | 21316 | 0% | 1.2 GiB |
| nginx worker | 31225 | **21%** | 34 MB |
| gl_clients_update | 2176 | 10% | 11 MB |
| netifyd | 6023 | 2% | 68 MB |
| smbd | 10043 | 0% | 30 MB |
| nginx master | 23720 | 0% | 18 MB |
| nmbd | 10044 | 0% | 22 MB |
Load average ~3.8 on 4 cores indicates moderate utilization. Adding per-VLAN CAKE instances may increase CPU load further (see Section 14).
Memory and Storage:
| Resource | Total | Used | Free/Available |
| RAM | ~2,033 MB | ~704 MB | ~1,207 MB |
| Swap | 0 | 0 | 0 |
| Overlay Root (/overlay) | 57.9 GB | 1.4 GB | 56.5 GB |
| /tmp (tmpfs) | 993.2 MiB | 51.8 MiB | 941.4 MiB |
Temps:
| Thermal Zone | Temperature (millidegrees C) | Temp (°C) |
| thermal_zone0 | 58,579 / 58,591 | ~58.6°C |
| thermal_zone1 | 58,579 / 58,591 | ~58.6°C |
| thermal_zone2 | 58,416 / 58,204 | ~58.3°C |
| thermal_zone3 | 57,304 / 57,267 | ~57.3°C |
| thermal_zone4 | 56,867 / 56,905 | ~56.9°C |
| thermal_zone5 | 57,492 / 57,479 | ~57.5°C |
| thermal_zone6 | 57,704 / 57,667 | ~57.7°C |
| thermal_zone7 | 58,029 / 58,016 | ~58.0°C |
| thermal_zone8 | 57,704 / 57,717 | ~57.7°C |
Tradeoffs & Warnings:
- CPU cost: 5 CAKE instances at line rate is heavy for MT7988.
- 650 Mbit cap on VLAN50: Investigate before expanding; the UCI value (900,000) differs from the live qdisc (650 Mbit).
- WAN egress shaping: Per-VLAN SQM on LAN bridges only protects LAN-side fairness, not WAN egress if ‘eth2’ is the real WAN.
- Option B alternative: Shared root CAKE with ‘tc’ VLAN filters if strict priority ordering is needed.
Issues found and resolved:
| Issue | Recommendation |
| SQM only on VLAN50 | Deploy per-VLAN CAKE (Option A above) once CPU headroom verified |
| VLAN50 SQM discrepancy (900 Mbps UCI vs 650 Mbps runtime) | Investigate GL.iNet wrapper or check for conflicting qdisc rules |
| Tailscale DNS SERVFAIL | Set upstream nameservers (1.1.1.1, 8.8.8.8) in Tailscale admin console |
| netifyd netlink buffer exhaustion | Increase net.netlink kernel buffers or reduce conntrack sampling |
| lan6 physically down | Verify cabling if intended as trunk uplink |
| eth2 WAN using APIPA addressing | Confirm this is the intended primary internet path; may need static or proper DHCP |
| Stale disabled interfaces | Remove or archive guest (VLAN9) and iot (VLAN10) configs to reduce clutter |
| Shared SSH key across fleet | Plan key rotation strategy; consider per-router or per-site keys for blast radius reduction |
Recommendations & Production Readiness
To get the gateway dialed in, the immediate hit list is straightforward:
- Fix the Tailscale DNS SERVFAIL issue by defining explicit global upstream resolvers (like 1.1.1.1) in the Tailscale dashboard.
- Track down why CAKE is capping out at 650 Mbps instead of the configured 900 Mbps.
- Once CPU headroom is confirmed, roll out CAKE shaping across VLAN1 and VLAN30 using a clean per-VLAN UCI scheme.
- Replace the shared SSH key across the device fleet with unique host keys.
For general housekeeping, cleaning up leftover disabled interfaces (like VLAN9 and VLAN10) and checking on the lan6 down state will keep the config tidy. Overall, the Flint 4 is a powerful homelab driver with great security defaults, but given the current beta firmware and selective QoS, it needs an owner who actively keeps an eye on the console.