Travel Routers

Travel Routers

Travel routers are compact, portable networking devices commonly used by security professionals, military personnel, and privacy-conscious travelers. This guide focuses on the GL.iNet ecosystem — particularly the Mudi V2 (GL-E750V2) — covering privacy hardening, automated reconnaissance, and field deployment.

For general router security, see Router Hardening.

Why a Travel Router?

• Network isolation — Place an encrypted tunnel between you and untrusted hotel/airport WiFi
• Consistent security posture — Same firewall rules, DNS, and VPN everywhere you go
• Portable recon platform — GPS logging, spectrum analysis, and packet capture in a pocket-sized device
• Cellular failover — Models with LTE/5G provide independent backhaul

GL.iNet Model Comparison

Model	CPU	RAM	Wi-Fi	Battery	Cellular	Best For
Mudi V2 (GL-E750V2)	QCA9531 @ 650 MHz	128 MB	AC750	7,000 mAh	LTE Cat-12	Mobile recon, wardriving
Mudi 7 (GL-E5800)	Qualcomm QC 2.2 GHz	2 GB	AX WiFi 7	5,380 mAh	5G NR	Next-gen mobile recon (~$370) 1
Beryl AX (GL-MT3000)	MT7981B @ 1.3 GHz	512 MB	AX3000	None	None	Hotel/travel VPN gateway
Slate AX (GL-AXT1800)	IPQ6000 @ 1.2 GHz	512 MB	AX1800	None	None	Best upstream OpenWrt support
Puli AX (GL-XE3000)	MT7981B @ 1.3 GHz	512 MB	AX3000	6,400 mAh	5G NR	5G mobile (higher cost)
Flint 2 (GL-MT6000)	MT7986A @ 2.0 GHz	512 MB	AX6000	None	None	Home base station (not portable)

Choosing a Model

The Mudi V2 is the only model with built-in battery + cellular + compact form factor at ~$130. The new Mudi 7 (announced CES 2026) adds WiFi 7, 5G NR, 2 GB RAM, dual SIM + eSIM, and a 2.8” touchscreen — but at 3x the price. For pure compute (Kismet, heavy logging), the Beryl AX or Slate AX have 4x the RAM and faster CPUs — but require external power and cellular.

GL.iNet Mudi V2 Specs

• SoC: Qualcomm QCA9531 @ 650 MHz (MIPS24Kc), ath9k driver (supports monitor mode on 2.4 GHz)
• Modem: Quectel EM060K-GL (LTE-A Cat 6, M.2 form factor; 300/50 Mbps theoretical, DL 2× carrier aggregation + 64QAM), GNSS capable via AT commands — confirmed live: firmware EM060KGLAAR01A11M2G, 2CA active (B66 20 MHz + B2 5 MHz)
• Storage: 16 MB NOR + 128 MB NAND + microSD up to 1 TB
• Ports: 1x USB 2.0, 1x 10/100 Ethernet (LAN/WAN), nano-SIM slot
• Display: OLED status screen (IP, signal, battery)
• Battery: 7,000 mAh LiPo (~8 hours moderate use, <6 W draw)
• Dimensions: 145 x 78 x 23 mm, 285 g
• Firmware: GL.iNet SDK 4.x (based on OpenWrt 22.03, kernel 5.15)
• Default IP: 192.168.8.1 (SSH on port 22, user root)

Firmware: GL.iNet SDK vs Vanilla OpenWrt

GL.iNet ships a proprietary overlay on top of OpenWrt. Security-conscious users should understand the tradeoffs.

	GL.iNet SDK 4.x	Vanilla OpenWrt
Pros	VPN wizard, cellular modem UI, OLED driver, AdGuard Home toggle	Direct upstream security patches, smaller attack surface, full package catalog, community-audited 2
Cons	Slower CVE patch cadence, 15 telemetry packages pre-installed, unaudited proprietary components 3	Lose GL.iNet UI, cellular modem requires manual AT commands, no OLED status
Mudi V2 support	Full support	Not available — V2 has no upstream OpenWrt target 4

Mudi V2 Firmware Lock-in

The GL-E750V2 does not have a merged upstream OpenWrt target as of April 2026. You must use GL.iNet firmware. The original GL-E750 (V1) has upstream support. If long-term vanilla OpenWrt matters, the Slate AX (GL-AXT1800) is the better base. ⁴

Known GL.iNet CVEs

GL.iNet publishes security advisories at gl-inet.com/security-updates. Notable issues:

CVE	Date	Severity	Description
CVE-2024-39227	Aug 2024	Critical	Unauthenticated RCE via gl-rpc path traversal + arbitrary library loading 5
CVE-2024-39226	Aug 2024	High	Authenticated command injection via s2s (root execution) 5
CVE-2024-57391	Apr 2025	High	Post-auth command injection 6
CVE-2025-2850	Apr 2025	Medium	Unauthorized file download 6
CVE-2025-2851	Apr 2025	Medium	Buffer overflow via plugins.so 6

Verify Firmware Version

Before any sensitive use, confirm your firmware is at or above the patched version for your model. Check the GL.iNet Security Advisories page.

---

Privacy Hardening

Mudi Configurator (Android App)

The mudi-configurator is an Android application that automates privacy and security hardening of GL.iNet routers over SSH — directly from your phone.

Credit: David L (@samedayhurt)

Supported models: GL-E750 (Mudi, fw 4.3.8+), GL-AXT1800 (Slate AX, fw 4.5.16+), GL-MT1300 (Beryl, fw 4.0+), GL-AR750S (Slate, fw 4.0+), GL-X3000 (Spitz AX, fw 4.0+)

What It Does

1. Removes GL.iNet telemetry — Strips 15 cloud/analytics packages:

   gl-cloud  gl-sdk4-cloud  gl-cloud-ui  gl-mqtt  mqtt
   gl-rtty   rtty-openssl   gl-traffic   gl-bigdata
   gl-upload gl-tertf       gl-ddns      gl-s2s
   gl-gps    gl-siderouter

2. Installs LuCI — Replaces GL.iNet’s proprietary UI with the standard OpenWrt web interface

3. MAC address spoofing — Randomizes WAN MAC using client-device OUIs (Apple, Samsung, Google, Dell, HP — 400+ OUIs) and radio MACs using router OUIs (Ubiquiti, Cisco, Netgear — 50+ OUIs)

4. Hostname randomization — Prevents router fingerprinting by generating random or custom hostnames

5. Firewall hardening — Blocks WAN inbound traffic, disables IPv6, sets TTL to 65 via iptables mangle rules (bypasses mobile hotspot tethering detection)

6. VPN configuration — Supports OpenVPN, WireGuard, L2TP/IPSec, PPTP, IKEv2 with kill-switch

7. DNS override — Cloudflare, Quad9, AdGuard, Mullvad, or custom DNS

8. Blue-merle IMEI randomization (Mudi GL-E750 only) — Downloads and installs the SRLabs blue-merle package for IMEI changes via shell, AT command, QMI, or MBIM

IMEI Legal Warning

Changing IMEI numbers is illegal in many jurisdictions, including the UK (Theft Act 1968), parts of the EU, and India. In the US, legality varies by state and use case. Only modify IMEI with proper authorization and legal guidance for your jurisdiction.

Getting Started

The app must be built from source (no published APK):

git clone https://github.com/samedayhurt/mudi-configurator.git
cd mudi-configurator
./gradlew assembleDebug
# Install APK from app/build/outputs/apk/debug/

The app connects to your router over WiFi via SSH (port 22, user root) and presents a before/after comparison of all changes before applying them.

No License File

The README claims MIT but no LICENSE file exists in the repository as of April 2026. Verify licensing before redistributing or forking.

Manual Hardening (Without the App)

If you prefer SSH-based hardening without the Android app:

# Connect to router
ssh root@192.168.8.1

# Remove telemetry packages
opkg remove gl-cloud gl-sdk4-cloud gl-cloud-ui gl-mqtt mqtt \
  gl-rtty rtty-openssl gl-traffic gl-bigdata gl-upload gl-tertf \
  gl-ddns gl-s2s gl-gps gl-siderouter

# Verify removal
opkg list-installed | grep gl-

# Install LuCI
opkg update && opkg install luci

# Restrict SSH to LAN only (prevent WAN exposure)
uci set dropbear.@dropbear[0].Interface='lan'
uci commit dropbear
service dropbear restart

# Change LAN subnet (avoid 192.168.8.x double-NAT conflicts in hotels)
uci set network.lan.ipaddr='10.70.74.1'
uci commit network

# Disable IPv6
uci set network.lan.ipv6='0'
uci set network.wan.ipv6='0'
uci commit network

# Set TTL to 65 on ALL outgoing traffic (bypass tethering/hotspot detection).
# Do NOT pin -o eth0: that is only the Ethernet WAN. With a SIM in the slot the
# egress interface is the cellular modem (wwan0 / rmnet / usb0 depending on model),
# so an eth0-only rule silently leaves cellular traffic untouched. Match all egress.
iptables -t mangle -A POSTROUTING -j TTL --ttl-set 65

# Change DNS to Cloudflare
uci set network.wan.dns='1.1.1.1 1.0.0.1'
uci commit network
/etc/init.d/network restart

On current GL.iNet firmware the iptables command above is silently ignored — use nftables

GL.iNet firmware 4.x is built on OpenWrt 22.03, which replaced iptables with fw4/nftables. This includes the Mudi V2 (GL-E750 v2) itself — verified on firmware 4.3.28 = OpenWrt 22.03.4 — as well as the Beryl AX / Slate AX / Mudi 7. The iptables -t mangle rule runs without error but never takes effect. Use the nftables hook instead (verified on a live Mudi V2 with fw4 check):

mkdir -p /usr/share/nftables.d/chain-pre/mangle_postrouting/
echo 'ip ttl set 65' > /usr/share/nftables.d/chain-pre/mangle_postrouting/01-set-ttl.nft
fw4 check   # optional: validates without applying — expect "Ruleset passes nftables check"
fw4 reload

fw4 auto-includes any .nft file in that directory into the mangle_postrouting chain, and unlike a runtime rule it survives reboots (the include dir is read on every fw4 start). For IPv6 add ip6 hoplimit set 65 to the same file. To confirm it works, ping from a client behind the router and check the carrier-side TTL is 64 — one hop past the router’s 65, matching a phone’s own traffic.

Note the egress interface varies by uplink mode — wwan0 / 3g-modem_* with a SIM, wlan-sta0 in WiFi-repeater mode, eth0 on Ethernet WAN — which is exactly why the rule must match all outbound traffic rather than pin one interface.

For a more detailed hardening walkthrough, see Logan Marchione’s Beryl travel router with OpenWrt guide. ⁷

Encrypted DNS (DoT / DoH)

GL.iNet firmware 4.x supports four encrypted DNS modes natively in the web UI: DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), DNSCrypt-Proxy, and Oblivious DoH (ODoH). See the GL.iNet DNS documentation for the built-in configuration. ⁸

For full control with Unbound + DNS-over-TLS:

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

Add to /etc/unbound/unbound_ext.conf:

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-ssl-upstream: yes

For more detail, see the GL.iNet blog post on DNS-over-TLS with Unbound. ⁹

VPN Configuration

On low-power MIPS/ARM routers like the Mudi V2 (QCA9531), WireGuard throughput is 2-3x higher than OpenVPN due to kernel integration and ChaCha20-Poly1305 (hardware AES is absent). ¹⁰

Kill switch — The most reliable method on OpenWrt is firewall-based: remove WAN from the LAN firewall zone’s “Allow forward to destination zones.” When the WireGuard interface drops, the firewall drops all forwarded traffic instead of falling back to cleartext. This is more reliable than software kill switches that die with the VPN process. ¹¹

Split tunneling — Provision two VLANs via OpenWrt: one routes through the VPN interface, one through WAN directly. Policy-based routing (ip rule / ip route table) selects which VLAN a client joins. GL.iNet SDK 4.x also has a built-in “VPN Policy” feature in the web UI. ¹²

Blue-Merle IMEI Randomization

blue-merle v3.0 (June 2025) is the current release, supporting both GL-E750 (V1) and GL-E750V2 on firmware up to 4.3.26. ¹³

IMEI randomization ≠ “make the router look like a phone”

Two different goals get conflated here. Defeating carrier tethering/hotspot detection so a phone-plan SIM works in the router is the TTL trick above (the carrier inspects TTL, not IMEI, to spot routed traffic). blue-merle’s IMEI change is for anonymity — breaking the link between a device identity and a SIM. It generates a random or IMSI-deterministic IMEI; it does not clone a real handset’s Type Allocation Code (TAC), so it won’t reliably impersonate “a phone” to a carrier’s device-type checks, and a clearly-router or unallocated TAC can itself draw attention. Use TTL for tethering bypass, blue-merle for anonymity — and mind the legal warning below.

How it works:

• Sends AT+EGMR command to the Quectel baseband over the AT command port to change the IMEI
• Radio is brought offline first to prevent the old IMEI from registering during transition
• Two generation modes:
  • Deterministic — Hashes the SIM’s IMSI to produce a repeatable IMEI per SIM (consistent pseudonym across power cycles)
  • Random — Cryptographically random IMEI each activation
• Also randomizes: WAN MAC, WiFi BSSID, and wipes the MAC association log (prevents forensic recovery of connected client devices) ¹⁴

v2.0 fixes (October 2023): v1 did NOT randomize the upstream MAC when the router was in repeater mode — v2.0+ fixes this by modifying glconfig.general.macclone_addr. ¹⁴

OPSEC requirements:

• Always change physical location between SIM swap and IMEI swap — registering a new IMEI from the same cell tower as the old one defeats the purpose
• Never co-locate the IMEI-randomized device with identity-linked devices
• The deterministic mode is generally preferred — it produces the same IMEI for a given SIM, avoiding the suspicion of a brand-new IMEI on every boot

Install (v3.0+) — blue-merle is not in any opkg feed, so download the release .ipk and install the file (don’t opkg install blue-merle, there’s nothing to resolve):

# From the router (SSH, root@192.168.8.1). Adjust arch: GL-E750 is mips_24kc.
opkg update   # refresh lists so dependencies resolve (pulls python3-light, python3-pyserial, libffi, libbz2)
curl -LO https://github.com/srlabs/blue-merle/releases/download/v3.0/blue-merle_3.0.5-0_mips_24kc.ipk
opkg install ./blue-merle_3.0.5-0_mips_24kc.ipk

Firmware newer than 4.3.26 triggers an interactive prompt that aborts a piped install

v3.0 is verified through firmware 4.3.26. On anything newer (e.g. 4.3.28, current Mudi V2) the preinstall script prints “…not been verified to work… continue on your own risk? (y/N)” and reads the answer from stdin. A plain opkg install over a non-interactive SSH command gets no answer and aborts with preinst script returned status 1 — note the Python dependencies still install, only blue-merle itself fails. Answer it by allocating a TTY and feeding y — verified working: blue-merle installs and the binary runs on a 4.3.28 Mudi V2 with the Quectel EM060K-GL modem (note: blue-merle’s docs reference the older EP06; the EM060K-GL uses the same AT+EGMR IMEI-write path, but treat IMEI changes on it as field-unverified until you confirm the write took):

yes y | opkg install ./blue-merle_3.0.5-0_mips_24kc.ipk   # over ssh, add -tt for a pty

If install instead fails with an MCU version verification warning, accept that prompt, let the router shut down, power it back on, then re-run opkg update and the install. Minimum firmware is 3.215.

Then run the guided swap over SSH (or use the hardware toggle / web UI at System → Advanced Settings → Network → Blue Merle):

blue-merle   # interactive: radio off → set interim IMEI → swap SIM → set new IMEI

Record the old IMEI from http://192.168.8.1/ first, and physically relocate between the SIM swap and the IMEI swap so the old and new identities never register from the same cell tower.

A mirror with LuCI web interface branch is available at git.hackliberty.org if srlabs.de is inaccessible. ¹⁵

---

Cellular Performance & Stability

Field-verified on a Mudi V2 (GL-E750 v2, firmware 4.3.28, Quectel EM060K-GL) on T-Mobile (Mint MVNO, MCC/MNC 310260, LTE Band 66 + 2 carrier aggregation). These settings are the difference between “connects but nothing loads” and a stable link.

Running a phone-plan SIM (Mint / T-Mobile MVNO) in the router

A consumer “unlimited” plan is unlimited phone data but a small hotspot/tethering bucket (a few GB, then throttled to ~128 kbps–600 kbps). A SIM in a travel router is tethering. Getting it working and fast is a layered problem — the first three settings make the link work and give the router’s own traffic full speed; the fourth (a VPN) is what gets that speed to your client devices on modern T-Mobile:

#	Setting	Where	Purpose
1	APN = carrier’s current value (fast.t-mobile.com for current Mint)	modem iface (below)	Without the right APN the modem registers but can’t route data (“connected, no internet”)
2	MTU = 1428	modem iface (below)	Stops T-Mobile’s 1500-MTU data blackhole
3	TTL = 65 (ip ttl set 65)	nftables hook — see Manual Hardening	Hides the extra router hop (necessary but no longer sufficient on T-Mobile)
4	VPN tunnel (WireGuard / Tailscale exit node)	router	Encapsulates client traffic as the router’s own encrypted traffic — the only reliable defeat of modern tethering detection. See Tethering throttle.

Settings 1–3 persist across reboot and SIM swap (the modem interface is keyed on the USB slot path, not the SIM).

Field reality, verified June 2026

With TTL 65 + MTU 1428 + correct APN, the router’s own traffic hit ~15.5 Mbps down / ~11 up — but forwarded client traffic was still throttled to ~0.5–4 Mbps download (upload unaffected). T-Mobile now detects tethering beyond TTL (traffic fingerprinting + the modem’s data-module IMEI TAC). TTL alone no longer bypasses the throttle for client devices — a VPN does.

SIM-swap playbook — do this when inserting a new SIM

1. Power the router OFF, swap the SIM, power back ON. The modem does not hot-detect a swapped SIM — insert-while-running leaves it at +CME ERROR: 13 (“SIM failure”) and +QSIMSTAT: 0,0 (not present), so the OLED shows no service. If you already hot-swapped, force a modem reset instead of a reboot: gl_modem AT 'AT+CFUN=1,1', wait ~35 s, recheck AT+CPIN? (should be READY). After a reset the modem may re-enumerate to a new interface name — a full reboot is cleaner.
2. Verify APN: gl_modem AT 'AT+CGDCONT?' → context 1 must show your APN. For current Mint this is fast.t-mobile.com, not wholesale (see APN section — wholesale registers but won’t route on newer SIMs). Let the modem’s auto-pick stand, or set it: uci set network.modem_1_1_2.apn='fast.t-mobile.com'; uci commit network; ifdown modem_1_1_2 && sleep 4 && ifup modem_1_1_2.
3. Verify MTU 1428 + TTL 65 survived: ip link show 3g-modem_1_1_2 | grep mtu and nft list ruleset | grep 'ttl set' (both persistent — sanity check). Confirm registration: AT+CEREG? → 0,1 (home).
4. Test data with ping, not a download: ping -I 3g-modem_1_1_2 -c3 1.1.1.1. Don’t read the GL UI’s signal labels — it tags RSRP −110 as “Excellent” (it isn’t; −110 is weak). Read the AT values: AT+QCSQ gives real RSRP/SINR.
5. Client devices slow/no internet but router fine? That’s the tethering throttle, not a config bug — set up the VPN fix. (Older levers — TTL 64, an IMEI change to a phone TAC — are weaker and increasingly defeated; the VPN is the reliable fix.)

MTU — the #1 stability fix on T-Mobile

Default MTU 1500 silently blackholes data on T-Mobile / its MVNOs

T-Mobile carries traffic over IPv6 with 464XLAT; the usable IPv4 MTU is 1428, not 1500. With the cellular interface left at 1500, TCP connections and ICMP succeed but bulk data transfer returns zero bytes — full-size data packets are dropped while small control packets pass. The symptom is maddening: ping works, the OLED shows signal and an IP, but web pages hang and curl reports http 000 after a successful connect. LAN clients behind the router lose internet over cellular for the same reason.

Diagnose: if ping over the modem works but a download stalls at 0 bytes, suspect MTU before signal or carrier.

# Runtime fix (test immediately) — replace 3g-modem_1_1_2 with your modem device (ip link show)
ip link set 3g-modem_1_1_2 mtu 1428

# Persist it (survives reboot/modem reconnect) — find the iface name via: uci show network | grep modem
uci set network.modem_1_1_2.mtu='1428'
uci commit network

Confirm MSS clamping is on so forwarded LAN-client traffic is also corrected (it clamps MSS to MTU−40 = 1388):

uci get firewall.@zone[1].mtu_fix   # must be 1 for the wan zone

The moment MTU dropped 1500 → 1428 on the test device, cellular downloads went from http 000 / 0 B/s to http 200. AT&T/Verizon are usually fine at 1500; T-Mobile and its MVNOs (Mint, Metro, Google Fi data-only, etc.) need 1428.

APN — match the actual carrier, not the modem’s auto-pick

The wrong APN is the classic “interface connected, but the Internet can’t be accessed” state: the modem registers (signal, operator name, an IP) but can’t route data. The modem auto-selects an APN from its internal IMSI database and gets it wrong on MVNOs — one test SIM came up on fast.metropcs.com (the Metro APN).

Mint’s APN changed — wholesale is legacy, fast.t-mobile.com is current

The older Mint APN wholesale is widely documented, but on a current Mint SIM (2026) it registered fine yet passed zero data — ping 100% loss despite full signal. Switching to fast.t-mobile.com (what that SIM’s modem auto-selected) fixed it instantly: 0% loss. Rule of thumb: trust the modem’s auto-picked APN first; only override if it’s clearly a different carrier’s APN. For current Mint use fast.t-mobile.com.

# See what's configured vs. what the network is
gl_modem AT 'AT+CGDCONT?'   # context 1 = your data APN
gl_modem AT 'AT+COPS?'      # registered operator name

# Set the correct APN. current Mint/T-Mobile = fast.t-mobile.com; Metro = fast.metropcs.com; legacy Mint = wholesale
uci set network.modem_1_1_2.apn='fast.t-mobile.com'
uci commit network
ifdown modem_1_1_2 && sleep 4 && ifup modem_1_1_2

Verify the context took (AT+CGDCONT?) and that data flows (ping -I <modem-dev> 1.1.1.1 — don’t burn a metered/trial SIM on downloads).

Tethering throttle — the VPN fix

This is the key finding. On the same SIM, same TTL 65 egress, same NAT’d source IP:

Traffic	Download
Router’s own (e.g. curl --interface from the router)	~15.5 Mbps ✓
Forwarded client (a laptop behind the router)	~0.5–4 Mbps (throttled) — upload stays ~11 Mbps either way

Both leave at TTL 65, so the carrier isn’t using TTL to tell them apart. Modern T-Mobile detects tethering by traffic fingerprinting (client OS TCP/TLS signatures, DNS patterns) and the modem’s IMEI TAC (a Quectel data-module TAC ≠ a phone), then throttles forwarded download to ~512 kbps regardless of TTL. So TTL 65 is necessary but not sufficient for client devices anymore.

The reliable defeat is a full-tunnel VPN on the router: all client traffic is encrypted and encapsulated, reaching the carrier as the router’s own single-destination encrypted flow — indistinguishable from phone traffic, impossible to fingerprint as tethered. Two options:

• Direct WireGuard to a box with a public IP — best raw throughput (direct UDP, no relay), at the cost of opening one UDP port. See Install WireGuard and Tailscale.
• Tailscale exit node — no inbound firewall needed (NAT-traversal). Caveat on GL hardware: the GL-pinned Tailscale build is old (1.32.x) and can’t use a modern tailnet’s exit node, and the current official mips build segfaults on the soft-float ath79 CPU (the Mudi). So Tailscale-for-traffic is effectively a dead end on the Mudi — prefer direct WireGuard here.

On GL.iNet, you MUST use the native WireGuard client — a raw uci interface won’t route clients

GL firmware uses fwmark-based policy routing for its VPN. A WireGuard interface you create by hand via uci (config interface 'wg0' + proto wireguard) will hand-shake and show a default route, but GL’s policy routing sends forwarded LAN-client traffic straight out the cellular wwan0, bypassing it — ip route get shows wg0 while the wg show transfer counter stays flat. You must configure the tunnel through the GL native WireGuard client (web UI: VPN → WireGuard Client → Add manually / Import config, or the matching /etc/config/wireguard peer schema) so GL marks LAN traffic into the tunnel and applies its kill-switch.

Verify it’s actually carrying traffic (don’t trust the route table): the wg show <iface> transfer RX/TX must grow by roughly your test’s byte count, and every client’s public IP (icanhazip.com) must equal the VPN server’s egress IP. If the counter is flat or the egress IP is still the SIM’s, GL isn’t routing through the tunnel.

The GL client does not auto-reconnect across reboots or uplink changes, and the CLI can’t start it (the gl-ngx backend owns the wgclient interface + fwmark — setting uci flags and poking wireguard_watchdog won’t create it). Toggle it on in the web UI each trip, or enable “Reconnect automatically” in the client’s settings.

The egress box’s own uplink becomes your effective speed, plus one hop of latency. If that box is multi-homed, route the WG-client subnet out its fastest uplink with a policy rule (e.g. ip rule add from 10.99.99.0/24 lookup <fast-uplink-table> in the server’s wg-quick PostUp). VLESS/Xray is not the tool here — it’s for state-censorship circumvention, not carrier throttling; only relevant if the carrier actively blocks WireGuard (T-Mobile does not).

Reality check — the throttle is location/condition-dependent

The forwarded-client throttle is not universal — measured across three locations on the same SIM:

Location	Client (direct)	Notes
Poor signal (SINR ~4)	~0.5 Mbps	throttle biting hard (router-own was ~15.5)
Good signal	~80 Mbps	no throttle at all, no tunnel needed
Mediocre signal (SINR ~6)	~45 Mbps	no throttle

So treat the VPN as a per-location toggle, not always-on. It defeats the throttle, but it costs ~30% (WireGuard overhead + the extra hop to the egress box) — turning it on where there’s no throttle actually makes you slower (e.g. ~45 Mbps direct dropping to ~13 through the tunnel). Flip it on only when devices crawl despite a decent signal bar; leave it off otherwise.

Don’t use router-side curl as the client-speed proxy

On a low-power MIPS router (the Mudi), the router’s own HTTPS download is CPU-bound (software TLS), so curl --interface from the router under-reads true throughput — at one spot the router measured ~25 Mbps while a laptop behind it pulled ~45 Mbps over the same link. Measure the client for the real number. A client that’s faster than router-origin is the opposite of the throttle signature (throttled clients sit far below router-origin at ~0.5 Mbps). Also, gl_modem AT '<cmd>' auto-detects the AT port — more reliable than hardcoding /dev/ttyUSBx (varies by firmware; this device’s control port is /dev/ttyUSB3).

fast.com measures your video speed — on T-Mobile that’s the video throttle, by design

fast.com is run by Netflix and deliberately tests against Netflix’s own servers, precisely so it surfaces ISP video throttling. A low fast.com on T-Mobile isn’t an error — it’s correctly reporting your video-streaming throughput, which T-Mobile’s “streaming video optimization” (Binge On) caps to SD, “up to 2.5 Mbps” per their own network-management policy. ¹⁶ The mistake is reading that number as your link speed. (This is a separate mechanism from the tethering throttle above — it bites even when tethering is not throttled.)

Two different questions, two correct answers — measured on a GL-X3000 (Spitz AX, T-Mobile 5G), same public IP, same instant:

Test	What it actually measures	Result
fast.com (Netflix OCA)	how fast video streams	2.5 Mbps (the video cap)
Cloudflare	general download	225 Mbps
Apple networkQuality	general download	~400 Mbps

Both numbers are real: ~2.5 Mbps for video, ~400 Mbps for everything else. The cap is content-classified, not a slow link — the tell is download (2.5) sitting below upload (12) with low latency (~24 ms); a real bottleneck tanks both directions. It’s also independent of the tethering throttle: forwarded clients here got the full ~400 Mbps, yet video was still capped.

To raise the video number (HD/4K streaming on the road): disable Binge On / enable HD per line (dial #263#, or T-Mobile app → Media Settings → HD Video Resolution) ¹⁷, or run a full-tunnel VPN so the carrier can’t classify the traffic as video ¹⁸. A split-tunnel VPN won’t help — video isn’t in the tunneled routes. For a general link-speed reading, use speedtest.net, Cloudflare, or networkQuality — that’s not what fast.com is for.

SQM on cellular: shape egress, not ingress

cake/SQM tames upload bufferbloat (that buffer is at the router’s egress — it’s what wrecks video calls). It can’t fix download bufferbloat on cellular: that lives in the carrier RAN, upstream of the router, so a CPE ingress cap either never engages or just throws away peak speed (tested on the GL-X3000 — a 250 Mbit ingress cap made loaded latency worse and download still burst past it; CPU was not the limit). Shape egress to ~90% of measured upload; leave the download cap generous.

Cellular OPSEC

Separate Threat Surface

A travel router with VPN protects IP-layer traffic only. Voice calls, SMS, and any traffic that traverses the cellular baseband directly bypass the router entirely. The cellular and IP threat surfaces must be addressed separately.

IMSI Catcher Detection

Rayhunter (EFF, March 2025) is an open-source IMSI catcher detector that runs on a $20 Orbic RC400L hotspot. It analyzes control-plane traffic between the hotspot and cell tower, flagging 2G downgrade requests and anomalous IMSI disclosure events. ^{19 20}

2G Downgrade Mitigation

IMSI catchers exploit 2G’s breakable A5/1 cipher by forcing a downgrade from LTE. Disable 2G fallback on the Quectel modem:

# Lock to LTE-only (disable 2G/3G fallback). Use the gl_modem wrapper so it finds
# the AT port automatically — the raw /dev/ttyUSBx number varies by firmware
# (e.g. the EM060K-GL's control port is ttyUSB3, not ttyUSB2).
gl_modem AT 'AT+CNMP=38'

This is the most effective software mitigation short of a Faraday bag. ²¹

SIM OPSEC

In order of anonymity (strongest first):

1. Cash-purchased prepaid SIM at retail in a non-home area with no ID (US does not require ID for prepaid in most states)
2. eSIM purchased with Monero via Bitrefill or similar ²²
3. Standard prepaid SIM with pseudonymous registration
4. Contract SIM — fully identity-linked, no anonymity

Best practices: activate on public WiFi with a clean device; never co-locate the SIM with identity-linked devices; store in a Faraday bag when not in active use. ²³

Baseband Isolation Limits

The Quectel modem runs its own RTOS on a separate processor with no memory isolation from the application processor on the Mudi. A compromised baseband can theoretically access the Linux filesystem. Google Project Zero documented 18 zero-click vulnerabilities in Samsung Exynos basebands (2023); similar risk categories apply to Quectel chipsets. ²⁴

Mitigations: Keep modem firmware updated; disable 2G fallback; use a VPN kill switch so even if the baseband is compromised, IP traffic remains encrypted. Airplane mode is insufficient — baseband processors have documented cases of maintaining radio activity independently of the OS power state. ²³

---

Automated Reconnaissance Setup

This section covers configuring a Mudi V2 as an automated recon platform that captures GPS coordinates and WiFi spectrum data with zero interaction after power-on.

Credit: David D

Prerequisites

• SSH access to the router (default: ssh root@192.168.8.1)
• GPS source: USB NMEA dongle (recommended, e.g., u-blox 7/8 VK-172) or built-in Quectel modem GNSS
• OpenWrt with opkg access

Clear SSH Keys After Factory Reset

If you’ve factory-reset the router, clear the stale host key first:

ssh-keygen -R 192.168.8.1

Install Packages

ssh root@192.168.8.1

opkg update && opkg install tmux nano horst gpsd gpsd-clients python3 python3-pyserial tcpdump

Optional packages:

• zerotier — Remote access to the router from anywhere via ZeroTier overlay network
• kmod-usb-acm — Kernel module for USB GPS dongles that appear as /dev/ttyACM0
• aircrack-ng — For monitor mode management (airmon-ng)

Storage Overflow on Flash

If packages + captures exceed the internal flash, redirect opkg and captures to USB/microSD:

mkdir /mnt/sda1/packages
echo "dest usb /mnt/sda1/packages/" >> /etc/opkg.conf
opkg --dest usb install tcpdump aircrack-ng
ln -s /mnt/sda1/packages/usr/bin/tcpdump /usr/bin/tcpdump

Add swap if running memory-intensive tools: mkswap /dev/sda2 && swapon /dev/sda2 ²⁵

Create Working Directories

mkdir -p /root/scripts /root/logs/gps /root/pcap

GPS Logging

Option A: USB GPS Dongle (Recommended)

A u-blox-based USB GPS dongle (e.g., VK-172, BU-353S4) is the most reliable option. It appears as /dev/ttyUSB0 or /dev/ttyACM0 and outputs standard NMEA sentences.

Save as /root/scripts/gps.py:

#!/usr/bin/env python3
"""GPS NMEA logger — reads serial GPS and writes timestamped log files."""
import serial
from datetime import datetime

PORT = "/dev/ttyUSB0"       # Adjust if your dongle uses ttyACM0
BAUD = 9600
LOG_DIR = "/root/logs/gps/"

timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
log_file = f"{LOG_DIR}gps_{timestamp}.log"

try:
    with serial.Serial(PORT, BAUD, timeout=1) as ser, open(log_file, "w") as f:
        print(f"Logging GPS to {log_file}")
        while True:
            line = ser.readline().decode("utf-8", errors="replace").strip()
            if line:
                f.write(line + "\n")
                f.flush()
except serial.SerialException as e:
    print(f"GPS serial error: {e}")
except KeyboardInterrupt:
    print("GPS logging stopped")

chmod +x /root/scripts/gps.py

Option B: Built-in Quectel Modem GNSS

The Mudi V2’s Quectel modem supports GNSS via AT commands. This avoids using the USB port but requires manual activation:

# Find the AT command port (usually ttyUSB2 on Mudi)
echo -e "AT+QGPS=1\r" > /dev/ttyUSB2

# Configure gpsd to read NMEA from the modem
uci set gpsd.@gpsd[0].device="/dev/ttyUSB1"
uci set gpsd.@gpsd[0].enabled="1"
uci commit gpsd
/etc/init.d/gpsd restart

# Verify GPS fix
gpspipe -r | head -20

Wardriving Tool Comparison

Tool	Best For	OpenWrt Package	GPS	WiGLE Export	Passive Only	RAM Usage
HORST	Lightweight spectrum/channel assessment	horst (opkg)	No	No	Yes	~5 MB
Kismet	Full wardriving, WIDS, multi-source	Stale in opkg 26	gpsd native	kismetdb_to_wiglecsv	Yes	~150 MB
airodump-ng	Quick capture, handshake collection	aircrack-ng (opkg)	gpsd (CSV)	Manual conversion	No (sends probes)	Low
Sparrow WiFi	GUI analysis with BT/SDR integration	Desktop Linux only	gpsd + MAVLink	No	Configurable	High 27

Spectrum Scanning with HORST

HORST (Highly Optimized Radio Scanning Tool) is a lightweight 802.11 analyzer that shows per-node RSSI, channel utilization, encryption type, and ESSID. At ~5 MB RAM, it is the practical choice for the Mudi V2’s 128 MB limit.

# Basic scan with file output
horst -i wlan0 -o /root/logs/horst_$(date +%Y%m%d_%H%M%S).log

Useful HORST Flags

Flag	Purpose
-i <iface>	Specify interface (e.g., wlan0 or wlan0mon for monitor mode)
-C <channel>	Lock to a specific channel
-V spectrum	Spectrum analyzer view (signal level + utilization per channel)
-V history	Scrolling packet history with RSSI bars
-V essid	Group results by ESSID
-V statistics	Aggregate packet type counts
-o <file>	Write records to file
-s	Start directly in spectrum mode
-d <ms>	Display refresh interval

Kismet Wardrive Mode

Kismet is the standard tool for GPS-correlated WiFi surveys with WiGLE export. The --override wardrive flag disables HT/VHT channels, enables AP-only survey mode, and simultaneously writes a .kismet database and .wiglecsv file. ²⁸

Kismet on OpenWrt is Stale

The Kismet OpenWrt package has had no maintainer since 2016 and may not build on current firmware. The recommended approach is to run Kismet on a companion device (Raspberry Pi, laptop) using remote capture, with the GL.iNet router providing the WAN uplink. ²⁶

Alternatively, if your router has sufficient storage (microSD), you can attempt to build Kismet from source or use a pre-compiled binary.

On a companion device (recommended):

# On the companion device (Pi/laptop):
kismet --override wardrive \
  --source wlan0mon:type=linuxwifi \
  --gps gpsd:host=localhost,port=2947

Converting and uploading to WiGLE:

# Convert .kismet database to WiGLE CSV
kismetdb_to_wiglecsv --in capture.kismet --out capture.wiglecsv

# Convert to KML for Google Earth visualization
kismetdb_to_kml --in capture.kismet --out capture.kml

# Convert to PCAP-NG for Wireshark analysis
kismetdb_to_pcap --in capture.kismet --out capture.pcapng

Upload the .wiglecsv file at wigle.net/uploads. WiGLE accepts Kismet native, NetStumbler, WiGLE WiFi Android, and other formats. ²⁹

For the Kismet wardrive documentation, see kismetwireless.net. For a practical wardriving walkthrough, see th4ntis.com. ^{28 30}

WiGLE Cardinal Rules

The WiGLE community requires passive mapping only — no packet payloads, no TCP logging. Capturing payload data may violate wiretap statutes. Review the WiGLE Cardinal Rules before uploading. ³¹

USB WiFi Adapter Selection

The Mudi V2’s internal radio (QCA9531/ath9k) supports monitor mode on 2.4 GHz only. For dual-band capture or 5 GHz injection, add an external USB adapter. Choose adapters with in-tree OpenWrt drivers — out-of-tree (DKMS) drivers break on kernel updates.

Chipset	Example Adapter	Bands	Driver	OpenWrt In-Tree	Monitor	Injection	Notes
MT7612U	Alfa AWUS036ACM	2.4+5 GHz	mt76	Yes	Yes	Yes	Best current pick for OpenWrt 32
AR9271	Alfa AWUS036NHA	2.4 GHz	ath9k_htc	Yes	Yes	Yes	Zero driver friction, 2.4 GHz only
RT5572	Panda PAU09 N600	2.4+5 GHz	rt2800usb	Yes	Yes	Yes	Reliable dual-band, lower power
RTL8812AU	Alfa AWUS036ACH	2.4+5 GHz	DKMS only	No	Yes	Yes	Popular but requires out-of-tree driver 33

For a comprehensive compatibility list, see the morrownr/USB-WiFi project — the authoritative community reference for Linux WiFi adapter support. ³²

Monitor Mode

The QCA9531’s ath9k driver supports monitor mode on 2.4 GHz. This enables raw 802.11 frame capture:

# Method 1: Using airmon-ng
opkg install aircrack-ng
airmon-ng check kill       # Kill interfering processes (wpa_supplicant, etc.)
airmon-ng start wlan0      # Creates wlan0mon

# Method 2: Manual iw (no airmon-ng dependency)
wifi down
iw phy phy0 interface add wlan0mon type monitor
ip link set wlan0mon up

# Use with horst or tcpdump
horst -i wlan0mon -V spectrum -o /root/logs/horst_$(date +%Y%m%d_%H%M%S).log

# Or capture PCAPs
tcpdump -i wlan0mon -w /root/pcap/capture_$(date +%Y%m%d_%H%M%S).pcap

5 GHz Monitor Mode

The 5 GHz radio (ath10k) can throw kernel errors during packet injection. Passive capture works on both bands, but for active testing on 5 GHz, add an external adapter — the Alfa AWUS036ACM (MT7612U, in-tree mt76 driver) is recommended over the RTL8812AU options that require DKMS. ³²

Confirmed monitor mode support across GL.iNet models: GL-USB150, AR150, AR300M, AR750, AR750S, AXT1800, A1300. Not supported: MT300N-V2. Unstable: MT3000 on stock firmware (requires upstream OpenWrt). ³⁴

Automated Startup

This tmux script launches GPS logging and spectrum scanning automatically on boot.

Save as /root/scripts/autostart.sh:

#!/bin/sh
# Automated recon startup — runs GPS logger and HORST in a tmux session
LOGDIR="/root/logs"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

tmux new-session -d -s recon

# Pane 1: GPS logging
tmux send-keys -t recon "python3 /root/scripts/gps.py" C-m

# Pane 2: Spectrum scanning
tmux split-window -v -t recon
tmux send-keys -t recon "horst -i wlan0 -o ${LOGDIR}/horst_${TIMESTAMP}.log" C-m

chmod +x /root/scripts/autostart.sh

Why a variable for the timestamp?

The original guide embedded $(date ...) directly inside a heredoc, which would expand at script-write-time (giving every boot the same timestamp). Using a variable at the top of the script ensures the timestamp is generated fresh at each boot.

Enable on Boot

Edit /etc/rc.local and add before exit 0:

# Wait for interfaces to initialize
sleep 10
/root/scripts/autostart.sh &

Retrieving Data

Pull logs from the router to your workstation:

# Sync all logs (removes source files after transfer)
rsync -avz --remove-source-files root@192.168.8.1:/root/logs/ ~/Desktop/recon-data/

# Or sync without deleting source
rsync -avz root@192.168.8.1:/root/logs/ ~/Desktop/recon-data/

# Sync PCAPs separately
rsync -avz root@192.168.8.1:/root/pcap/ ~/Desktop/recon-data/pcap/

rsync —remove-source-files

The --remove-source-files flag deletes files from the router after successful transfer. Only use this if you’re confident your local destination is correct. Consider doing a dry run first: rsync -avzn --remove-source-files ...

Deployment Checklist

1. Power on router
2. rc.local runs autostart.sh after 10s delay
3. tmux session "recon" starts GPS + HORST
4. Logs saved automatically to /root/logs/
5. Retrieve via rsync when ready

---

Field Deployment Tips

Power

• Internal 7,000 mAh battery lasts ~8 hours at <6 W draw
• Disable 5 GHz + set 2.4 GHz TX power to LOW to extend runtime to 13-15 hours (community-tested) ³⁵
• Turning off the LTE modem when not needed is the single largest power saving on cellular models
• A 20,000 mAh USB-C power bank extends runtime to ~12-14 hours beyond internal battery
• For static deployments, a 10 W+ solar panel (5V/2A) can sustain the device indefinitely

Storage

• Format microSD as ext4 for large pcap writes: mkfs.ext4 /dev/mmcblk0p1
• Mount for capture storage: mount /dev/mmcblk0p1 /mnt/sdcard
• With 1 TB microSD, storage is effectively unlimited for text logs; budget ~1 GB/hour for full pcap on busy networks

USB Port Management

The single USB 2.0 port is a bottleneck. If you need both an external WiFi adapter and a GPS dongle, use a powered USB hub. Priorities:

1. GPS dongle only — Most common field config
2. GPS + external WiFi adapter — Requires USB hub
3. Built-in modem GNSS + external WiFi — Frees USB port but GNSS setup is less reliable

Captive Portal Bypass

When connecting through hotel/airport WiFi:

1. Try Extender mode first (not Repeater) — triggers automatic captive portal page on simple networks ³⁶
2. Browse to 1.1.1.1 directly (not a domain name) to force the portal redirect ³⁷
3. MAC Clone mode — clone your phone’s MAC via Repeater > MAC Mode > Clone for portals that lock by MAC address ³⁷
4. Temporarily disable DNS rebind protection for captive portals that use split-horizon DNS:

   uci set dhcp.@dnsmasq[0].rebind_protection='0'
   uci commit dhcp && service dnsmasq restart
   # After authenticating, re-enable:
   uci set dhcp.@dnsmasq[0].rebind_protection='1'
   uci commit dhcp && service dnsmasq restart

In-Flight WiFi — When MAC Clone Isn’t Enough

In-flight portals (American’s aainflight.com, plus Viasat/Panasonic/Intelsat backends) are the hardest captive portals to repeater through. A clone that works in hotels routinely fails at 35,000 ft. The failure modes, in order of how often they bite:

1. You cloned the wrong MAC (the #1 cause on iPhone). Modern iPhones default to Private Wi-Fi Address ON, and Apple uses a rotating private MAC specifically for “weaker” networks — including captive portals and open networks like airline WiFi. ³⁸ So the address shown under Settings → Wi-Fi → ⓘ is per-SSID, and the phone’s hardware MAC (or its private MAC for a different network) is not what the portal authorized. GL.iNet’s own MAC-clone screen warns that the displayed address may not be the device’s real one for this reason. ³⁷

The fix is to clone the exact MAC the airline saw:

• On the phone, join aainflight.com first, then read Settings → Wi-Fi → (i) next to aainflight.com → Wi-Fi Address. That hex string — not the phone’s hardware MAC — is what to paste into the router’s MAC Clone field. ³⁹
• A clone value beginning with a digit whose low nibble is 2/6/A/E (e.g. DE:…, 3A:…) is a locally-administered/randomized MAC, i.e. exactly what iOS generates — confirm it matches the current per-SSID value, since iOS regenerates it if Private Address is toggled off/on.

Duplicate-MAC collision

Once the router clones the phone’s MAC, forget the network on the phone (or disable its WiFi). Two devices presenting the same MAC to the same AP collide — both flap and neither holds the authenticated session. ⁴⁰

2. The connectivity watchdog tears the link down before you finish the portal. GL.iNet runs mwan3track, which pings 1.1.1.1 / 8.8.8.8 to decide if an uplink is “online.” On a captive portal those pings fail until you authenticate, so the watchdog marks the repeater interface down and can flap it in a loop — you never stay connected long enough to load the portal. Symptoms: the WISP connects, drops after ~20–30 s, reconnects, repeats — a recurring complaint with repeater-mode captive portals. ⁴¹ Workarounds: complete the portal fast, or temporarily relax tracking on the repeater interface (mwan3 → raise reliability/down thresholds, or stop mwan3 while authenticating), then restore it once you’re through.

3. The portal lives on 2.4 GHz. Aircraft APs are almost always 2.4 GHz only. If the repeater is scanning/locked to 5 GHz it will never see aainflight.com. Force the repeater radio to 2.4 GHz before scanning.

4. VPN/DNS must be fully down for the first connection. A WireGuard/OpenVPN client set to auto-connect, a kill-switch zone, AdGuard, or a DoH/DoT proxy all prevent the portal’s HTTP redirect from resolving. Disable every VPN client and custom DNS, authenticate, then bring the tunnel up. ³⁷

Field recovery order for “it just won’t connect”

1. Repeater radio → 2.4 GHz, rescan, select the airline SSID.
2. MAC Clone → paste the phone’s per-SSID Wi-Fi Address; forget the WiFi on the phone.
3. VPN clients off, custom DNS off, DNS-rebind protection off.
4. Browse to http://1.1.1.1 (plain HTTP, not HTTPS) to force the redirect. ³⁷
5. If it keeps dropping mid-login, that’s the mwan3 flap — relax/stop tracking, authenticate, restore.
6. Keep the cellular modem as a fallback uplink; it does not need to be disabled and its config (APN, SIM) is unaffected by toggling the WiFi repeater.

Toggling cellular does not wipe config

Disabling the LTE modem from the GL.iNet UI only brings the modem_* interface down (disabled='1'); it leaves the APN, repeater profiles, LAN IP, WireGuard peers, and WiFi settings intact in /etc/config. A factory reset wipes settings — a modem toggle does not. Verify with uci show network | grep modem (the qmi interface and apn= survive) and cat /etc/config/repeater (saved WISP profiles survive).

Remote Access

Install ZeroTier for remote management without exposing ports:

opkg install zerotier
# Configure with your network ID
uci set zerotier.sample_config.enabled='1'
uci set zerotier.sample_config.join='<your-network-id>'
uci commit zerotier
/etc/init.d/zerotier restart

Operational Use Cases

Red team portable kit: Mudi V2 + AWUS036ACM (USB hub) + VK-172 GPS dongle covers: cellular uplink with IMEI randomization (blue-merle), WiFi survey (Kismet wardrive + HORST), passive packet capture (tcpdump to microSD), remote management (ZeroTier), and full VPN tunnel with kill switch. Total kit weight under 500g.

Journalist/activist travel: Priority is network isolation and DNS privacy, not recon. Configuration: disable all GL.iNet cloud packages, enable WireGuard to a trusted exit node (Mullvad or self-hosted), enforce DoT or ODoH, enable firewall-based kill switch. Carry Rayhunter on a secondary device to detect IMSI catcher activity at checkpoints. ¹⁹

Supply chain baseline: Treat all pre-loaded firmware as untrusted. After reflashing, run tcpdump -i eth0 not port 53 and not port 123 for 5 minutes to baseline outbound traffic. Audit /etc/crontabs/root and /etc/rc.local after first boot. ⁴²

---

Legal and Ethical Considerations

Know Your Legal Boundaries

Wireless scanning legality varies by jurisdiction and activity type. Understand the law before deploying.

Generally Accepted (Low Legal Risk)

• Passive beacon/probe collection — SSIDs, BSSIDs, signal strength, GPS coordinates from public spaces
• Spectrum analysis — Channel utilization and RF congestion assessment
• Your own networks — Full testing authority on networks you own or administer

Requires Authorization

• Active probing — Sending probe requests or associating with networks
• Packet capture of traffic — Capturing payload data from any network
• Deauthentication frames — Illegal under FCC Part 15 and 47 U.S.C. 333 (interference)
• Network penetration testing — Requires written rules of engagement

Key US Laws

• Computer Fraud and Abuse Act (CFAA, 18 U.S.C. 1030) — Criminalizes “unauthorized access” to computer systems; “without authorization” is not precisely defined
• FCC Part 15 — Governs unlicensed radio devices; intentional interference is prohibited
• State laws — California Penal Code 502 and similar state statutes may impose stricter standards than federal law
• Wiretap Act (18 U.S.C. 2511) — Prohibits interception of electronic communications; passive beacon collection is generally excluded

---

Resources

• GL.iNet Documentation — Official firmware guides and specs
• GL.iNet Security Advisories — CVE notifications and patches
• mudi-configurator — Android privacy hardening app (David L)
• blue-merle — IMEI randomization for GL-E750 (SRLabs)
• Rayhunter — IMSI catcher detector (EFF)
• HORST — Lightweight 802.11 analyzer
• Kismet — Full wireless network detector and sniffer
• Sparrow WiFi — GUI WiFi analyzer with BT/SDR integration
• morrownr/USB-WiFi — Linux WiFi adapter compatibility reference
• OpenWrt Packages — Community package repository
• WiGLE — Wardriving database and community
• Router Hardening — General router security guide

---

References

Footnotes

1. Mudi 7 (GL-E5800) Product Page — GL.iNet ↩

2. MT6000 GL.iNet firmware vs OpenWrt discussion — OpenWrt Forum ↩

3. GL.iNet suggestion for recommendation — Privacy Guides Community ↩

4. GL-E750V2 upstream OpenWrt support thread — OpenWrt Forum ↩ ↩²

5. Security Advisories Aug 1, 2024 (CVE-2024-39226/39227/39228) — GL.iNet ↩ ↩²

6. Security Advisories Apr 24, 2025 (CVE-2024-57391/2025-2811/2850/2851) — GL.iNet ↩ ↩² ↩³

7. Beryl travel router with OpenWrt — Logan Marchione ↩

8. DNS configuration guide — GL.iNet Docs ↩

9. Privacy-Protecting Portable Router: Adding DNS-Over-TLS with Unbound — GL.iNet Blog ↩

10. Empirical Performance Analysis: WireGuard vs OpenVPN — MDPI Computers ↩

11. WireGuard gateway with killswitch and port forwards on WAN — OpenWrt Forum ↩

12. Split Tunnel via VPN Policy or WireGuard AllowedIPs — GL.iNet Forum ↩

13. blue-merle Releases — SRLabs GitHub ↩

14. blue-merle README — SRLabs GitHub; SRLabs Blog Post ↩ ↩²

15. blue-merle LuCI mirror — HackLiberty ↩

16. Network Management Practices — streaming video optimization (SD, up to 2.5 Mbps) — T-Mobile ↩

17. Activate HD video streaming / disable Binge On — T-Mobile Support ↩

18. How to bypass T-Mobile throttling with a VPN — BleepingComputer ↩

19. Meet Rayhunter: A New Open Source Tool from EFF to Detect Cellular Spying — EFF ↩ ↩²

20. Rayhunter: Device to Detect Cellular Surveillance — Schneier on Security ↩

21. Cell-Site Simulators / IMSI Catchers — EFF Street Level Surveillance ↩

22. Bitrefill eSIM — cryptocurrency-purchased eSIMs ↩

23. Cell Phones in Combat Zones — SLNT ↩ ↩²

24. Multiple Internet-to-Baseband Remote Code Execution in Exynos Modems — Google Project Zero ↩

25. GL-iNet sniff setup gist — GitHub ↩

26. Kismet, Monitor Mode, Wardriving — stale package discussion — OpenWrt Forum ↩ ↩²

27. Sparrow WiFi — ghostop14, GitHub ↩

28. Kismet Wardrive Mode Documentation — Kismet ↩ ↩²

29. WiGLE Uploads — WiGLE ↩

30. Wardriving Guide — th4ntis (March 2024) ↩

31. WiGLE Cardinal Rules of Wardriving FAQ — WiGLE ↩

32. USB WiFi Adapters with Linux In-Kernel Drivers — morrownr/USB-WiFi ↩ ↩² ↩³

33. rtl8812au out-of-tree driver — aircrack-ng, GitHub ↩

34. Updated list of routers which support Monitor Mode — GL.iNet Forum ↩

35. 13-15 hours of battery life with Mudi E750 — GL.iNet Forum ↩

36. Easy captive portal login with Beryl — GL.iNet Forum ↩

37. Connect to public hotspot with Captive Portal — GL.iNet Docs ↩ ↩² ↩³ ↩⁴ ↩⁵

38. Wi-Fi privacy: private (rotating) Wi-Fi addresses for captive portals and open networks — Apple Platform Security ↩

39. Captive Portals and Cloning MAC Address — GL.iNet Forum ↩

40. Cloning a MAC address to bypass a captive portal — Fedora Magazine ↩

41. Can’t get to captive portal (hotel) using repeater mode (Beryl/MT1300) — GL.iNet Forum ↩

42. How secure are GLiNET devices? — GL.iNet Forum ↩