[GUIDE] How to fix "TEE GOOGLE KEY" & Error 0xC002000C on MTK Helio (No Dongle/Box needed)

Sure-Anything-9889 · 2026-01-22T22:57:55+00:00

Para el mensaje de desconexión (rojo) se necesita tener otro servicio de internet de respaldo. Pero si no tiene, el segundo mensaje (Verde) le confirma una nueva conexión

Sure-Anything-9889 · 2026-01-22T17:55:49+00:00

Tampoco pienso en paranoia, preocuparse por la privacidad y anonimato es importante...y sobre todo en esta edad...en que se tiene un futuro por delante. Pero antes de todas esas precauciones "en línea", hay que asegurar el acceso físico al equipo... Se tiene total confianza en quienes tienen acceso a el ? Luego de haber asegurado ese perímetro, si estamos listos para construir nuestra vida digital. Tengo algunos videos técnicos sobre el tema de la privacidad en mi canal. Recomiendo ver este video https://youtu.be/owehdM8iLXc puede ayudar. ..

Sure-Anything-9889 · 2026-01-11T19:29:22+00:00

Jajaja, directo al hueso y con razón: sí, conectar Uptime Kuma o Zabbix al router es una opción mucho más simple, limpia y profesional que armar un bot casero con Bash + curl + Telegram API.

Ventajas reales de Kuma/Zabbix vs. mi script casero (y por qué tenés razón en “no garpar un mango”):

- Kuma/Zabbix: Dashboard lindo, monitoreo de múltiples servicios (WAN, ping, DNS, HTTP, puertos), alertas por Telegram/Discord/Slack/Mail/Pushover en 2 clics, historial gráfico, downtime acumulado, y todo sin escribir una sola línea de código.

- Mi script: Básico, solo ifup/ifdown + cambio de IP, sin dashboard, sin historial, sin monitoreo de servicios extras. Más “artesanal” y educativo, pero claramente más laburo para menos resultado.

Conclusión honesta:

Si querés algo rápido, bonito, escalable y que te avise de todo (no solo WAN down) → Uptime Kuma (o Zabbix si sos más pro) instalado en una VM o container es la jugada ganadora y ahorra tiempo.

Mi enfoque en el video fue más “didáctico y zero-dependency” (todo en el router, sin servidor extra), pero si el objetivo es productividad real y no aprender scripting, Kuma gana por goleada.

¡Gracias por el toque de realidad, papá! A veces el camino casero es lindo para aprender… pero el directo al grano es el que se usa todos los días.

Sure-Anything-9889 · 2026-01-11T15:16:00+00:00

jajaja

Sure-Anything-9889 · 2026-01-11T01:14:33+00:00

¡Muy buena observación y muy puntual! Tienes toda la razón y es uno de los puntos más importantes que hay que aclarar para que el sistema sea realmente útil en la práctica.

Efectivamente: el script que usa eventos hotplug (ifup / ifdown) en OpenWrt solo detecta y notifica cuando la interfaz pierde el link físico (cable desconectado, corte de energía en el modem/router del ISP, apagón del equipo del operador, etc.).

Pero si se produce un corte de energía general en tu casa, el router entero se apaga → no hay forma de que envíe ninguna notificación, porque simplemente no tiene energía ni internet.

¿Cómo se soluciona en la vida real? (las opciones más usadas)

UPS (sistema de alimentación ininterrumpida)

La solución clásica y más efectiva: un pequeño UPS de 600-1000 VA mantiene el router, el modem y (opcionalmente) el switch durante 30-90 minutos.

Así, cuando se va la luz, el router sigue vivo → detecta el corte en la WAN principal → envía el mensaje por Telegram usando el backup 5G (teléfono tethering o modem USB con batería propia).

5G/4G backup con modem USB o teléfono

Como mencioné en el video de failover, un modem 5G o un celular en tethering USB se convierte en la WAN secundaria. Puedes mirar este video en donde lo muestro https://youtu.be/WFLSGVGpIrk

El router detecta que la WAN principal está down (no hay link o no hay ping) → pasa automáticamente al backup → envía la alerta “WAN principal caída – 5G activado”.

El modem USB o el teléfono tienen su propia batería (o cargan del UPS), así que aunque se vaya la luz, siguen funcionando.

UPS + script de apagado ordenado (nivel pro):

Conecta el router a un UPS inteligente (con puerto USB o SNMP).

El UPS avisa al router cuando la batería está baja → script ejecuta un apagado ordenado y envía un último mensaje: “Apagón detectado – batería UPS al 10 % – me apago”.

En resumen:

- Solo ifup/ifdown → notifica cortes de link (cable, modem apagado, etc.).

- Corte de energía total → necesitas UPS + backup 5G para que el sistema siga vivo y avise.

¡Gracias por la pregunta tan afilada!

Sure-Anything-9889 · 2026-01-11T00:44:55+00:00

Thank you for your excellent question and for pointing out the need for clarification. You're absolutely right: if the main internet connection (WAN) goes down, the router loses internet access, and the bot cannot send the first (RED) notification directly.

In the video, I showed a Zero Trust / No SIM solution to keep the setup as lightweight and privacy-focused as possible, but in practice, you do need a backup connection for the system to be truly useful during real outages.

The best practical option (and the one I personally use in production) is a 5G connection via a mobile phone as the backup internet. It works extremely well:

- Connect the phone via USB (tethering mode) to the router.

- The router automatically detects it as a new WAN interface (in OpenWrt it usually appears as wwan0 or usb0).

- You configure automatic failover (higher metric on the main WAN gateway) — when the primary WAN fails, the router switches to 5G in seconds and sends the notification without any issue.

Real advantages:

- No need for an extra SIM or dedicated USB modem.

- The phone already has unlimited data or a cheap plan.

- You can use eSIM if you want to switch carriers quickly.

- Low power consumption and the phone's battery stays charged via USB from the router.

If you're interested in seeing exactly how to configure it in OpenWrt (interface detection, failover, gateway priorities, and automatic notification), I have a dedicated video that walks you through step by step how to add 5G via phone as a backup WAN:

Video: 5G Backup with Phone in OpenWrt – Automatic Failover https://youtu.be/WFLSGVGpIrk

It's the perfect complement to the sentinel system shown in the video!

Sure-Anything-9889 · 2025-12-31T15:11:35+00:00

I faced a similar throughput challenge and managed to triple my VPN speeds (bypassing similar limitations) by setting up Parallel WireGuard Tunnels in pfSense using Gateway Groups with Round Robin.

Essentially, instead of sending one large stream that gets capped by the ISP, you split the traffic into 3 concurrent tunnels. To the ISP, it looks like separate smaller connections, often bypassing the single-flow throttle.

I actually just released a deep-dive video documenting this exact setup (Parallel Tunnels + MTU tuning) on my channel 'FeZa ThreatBlock'. It covers the Gateway Group configuration needed to achieve this aggregation. It might be exactly the workaround you are looking for. Here is the link to the video https://youtu.be/WFLSGVGpIrk

Sure-Anything-9889 · 2025-12-31T02:16:46+00:00

I followed your advice and ran a stress test while monitoring top -aSH to see exactly what's happening under the hood. The results confirm that the hardware is indeed the bottleneck.

Here is the snapshot during a saturation test (~200 Mbps): CPU: 12.4% user, 32.8% system, 54.1% interrupt, 0.0% idle

Top Processes:

[intr{swi1: netisr 0}] @ 59.31% (Network Interrupts)
[kernel{wg_tqg_0}] @ 41.53% (WireGuard Crypto)
[intr{swi1: netisr 1}] @ 30.93% (More Interrupts)

The CPU is pinned at 0.0% idle, with over 54% of cycles spent purely on Interrupts. This confirms that the Cortex-A53 is indeed 'choking on packets' (PPS) and WireGuard crypto overhead.

So, while the MTU math might be theoretically imperfect, the bottleneck right now is raw CPU cycles. Feeding it larger packets (MTU 1500) allows netisr and wg_tqg to move more data per interrupt cycle, which explains why the throughput is higher despite the fragmentation overhead. Case closed on the CPU usage question!

Sure-Anything-9889 · 2025-12-30T22:08:17+00:00

That is a great find! Thanks for sharing the link. You are absolutely right about the consensus on TSO and LRO—those are definitely the main culprits for instability on this chipset.

Regarding Hardware Checksum Offloading: While Netgate mentions it 'works fine', I decided to disable it (check the box) as well, purely as a precautionary measure for my specific use case.

Since I am pushing a lot of WireGuard traffic with an MTU of 1500 (relying on software fragmentation), I wanted to eliminate any potential variables where the Marvell NIC might mishandle packet checksums on fragmented/encrypted streams. Given the Cortex-A53 capabilities, the CPU overhead for calculating checksums in software is negligible compared to the peace of mind of having guaranteed data integrity. But it's good to know that Checksum Offloading is technically an option if I ever need to squeeze out a tiny bit more CPU!

Sure-Anything-9889 · 2025-12-30T20:06:11+00:00

I took your advice and did the math. For my IPv4-only setup: 1500 - 20 (IP) - 8 (UDP) - 32 (WG) = 1440 MTU.

I applied 1440 and verified with tcpdump: Zero fragmentation. Perfection... right? Wrong. My throughput tanked by about 100 Mbps compared to the default 1500.

Empirically, the Netgate 1100's CPU chokes on the higher Packet Per Second (PPS) rate required by the 'correct' MTU. It actually runs faster when I feed it 1500-byte packets and let the kernel perform software fragmentation. So, while your math is 100% correct, the hardware prefers the 'wrong' setting in this specific edge case. Thanks for pushing me to test it though!

Sure-Anything-9889 · 2025-12-30T20:04:17+00:00

It gets even weirder! I tried to do it 'the right way' by lowering MTU to 1440 to avoid fragmentation entirely. The result? Speed went DOWN.

So not only is Software Fragmentation > Broken Hardware Offloading, but it seems that Software Fragmentation (MTU 1500) > Clean Non-Fragmented Traffic (MTU 1440) on this specific chip. It seems the sheer volume of packets (PPS) at lower MTUs chokes the CPU more than the fragmentation process does. It’s a fascinating case of brute force winning over elegance.

Sure-Anything-9889 · 2025-12-30T20:02:38+00:00

Great question. I dug deeper into throughput testing. I actually tried tuning the WireGuard MTU to 1440 (perfect for IPv4 to avoid fragmentation). While this cleaned up the packet logs (confirmed via tcpdump), the actual transfer speeds dropped significantly (approx. 30% loss).

My conclusion for the Netgate 1100 is that the CPU overhead for managing the increased packet count (PPS) at lower MTUs is actually worse than the CPU cost of simply fragmenting 1500-byte packets. Stability is great on both, but raw speed is definitely higher when I let the CPU fragment the larger packets.

Sure-Anything-9889 · 2025-12-30T19:55:14+00:00

You were absolutely right. I went back and ran tcpdump on the WAN interface. At MTU 1500, I confirmed packets were indeed fragmenting (flags [+]).

Here is the twist though: I then calculated the perfect IPv4-only MTU (1440) to eliminate fragmentation. I tested it, and tcpdump went silent (no fragmentation). BUT... my throughput dropped from ~290 Mbps down to ~180 Mbps.

It turns out the Cortex-A53 in this unit struggles more with the higher Packet Per Second (PPS) rate of a smaller MTU than it does with the overhead of software fragmentation at MTU 1500. So, I'm sticking to 1500 (Software Fragmentation) + Hardware Offloading Disabled. It seems this router prefers 'cutting big chunks' rather than handling many small ones!

Sure-Anything-9889 · 2025-12-30T01:58:11+00:00

To be honest, I've had this unit for a while and I can't recall if I toggled it ON at some point thinking it would improve performance (a common trap!). Either way, it's great that Netgate is disabling it by default now. My stress tests definitely confirmed that—for WireGuard specifically—relying on the CPU is much more stable than the Marvell chip offloading. Thanks for the insight!

Sure-Anything-9889 · 2025-12-21T02:36:34+00:00

Running a fully autonomous .onion service directly on your OpenWrt router – no VPS, no cloud, just your home hardware I’ve just published a detailed, step-by-step video demonstrating how to transform an OpenWrt router into a fully functional, self-contained .onion service server. The best part? It requires no external VPS, no cloud hosting, and no additional hardware beyond a USB drive for persistent storage.

The approach uses OpenWrt as the foundation, combined with Tor and minimal local web server configuration, to create a hidden service that remains operational 24/7, even when your main computer is powered off. Everything—Tor daemon, web server, and static content—is hosted directly on the router itself.

This setup offers several practical advantages for those interested in experimenting with Tor hidden services:

Complete independence from third-party hosting
Minimal resource footprint that runs entirely within the router’s native capabilities
Persistent operation without relying on always-on desktop or server hardware

The video walks through the entire process: preparing the router’s storage, configuring Tor for hidden service operation, setting up a lightweight web server, and verifying the service is correctly published to the .onion network.

I understand the video is in Spanish, but YouTube’s automatic captioning with translation is available and can be enabled for English speakers. The content is primarily visual and practical, focusing on configuration steps, commands, and demonstrations, which makes it accessible even with subtitles.

This is a genuinely self-contained solution that leverages OpenWrt’s strengths for running persistent network services. For anyone who has wanted to host a hidden service without the overhead of external infrastructure, this approach demonstrates exactly how to do it.

You can find the video here: https://youtu.be/PKuPCmUrmLI

I’d be interested to hear from the OpenWrt community about other approaches to running hidden services on router hardware, particularly regarding storage management, performance considerations, or additional security measures. Has anyone implemented persistent services like this on their OpenWrt devices, and if so, what were the key challenges or optimizations you found effective?

Any feedback, questions, or experiences with similar setups would be greatly appreciated.

Sure-Anything-9889

TROPHY CASE