Un bug en el software estándar de la F1 dejó sin potencia a varios coches en la vuelta de formación del GP de Baréin (en Sepang). Te cuento qué falló, quién controla realmente qué en un monoplaza, cómo se cargó un parche a toda la parrilla en 20 minutos y por qué no fue la radio.
Desde iOS 27, el iPhone muestra «5G+» cuando está conectado a una red 5G Standalone. La red no es nueva: lo nuevo es que ahora el móvil te lo cuenta. Aprovecho el cambio para explicar las dos caras del 5G. En este episodio Qué ha cambiado en iOS 27: los perfiles de operador (carrier bundles) y el nuevo icono. 5G NSA: la radio 5G anclada al 4G y a su núcleo de red, y por qué el icono «5G» siempre ha sido algo optimista. DSS: cómo se compartieron las frecuencias del 4G para encender el 5G rápido, y por qué aquel 5G iba casi como el 4G. 5G SA: núcleo 5G propio, network slicing, identificador cifrado, eficiencia y VoNR. Por qué el «+» indica arquitectura, no velocidad garantizada. ¿Importa esto al usuario? ¿Y a la industria? Episodios relacionados Ep. 107. Por qué se satura la red en eventos masivos (network slicing) Ep. 113. El secreto del núcleo de red de Digi Ep. 115. Apple keynote 2026 para telecos Enlaces Apple: Usar 5G con el iPhone Xataka Móvil: Qué significa el nuevo icono de 5G+
Empecé la semana con una pregunta inocente: quiero ver el mapa de mi red Thread. Terminé encontrando cuatro problemas distintos, ninguno donde yo creía, y con una casa que funciona bastante mejor que antes. En la primera mitad desmontamos Thread y Matter pieza por pieza: qué hace cada capa, quién estandariza qué, y por qué hay cuatro organismos distintos metidos en que tu bombilla se encienda. En la segunda, el diagnóstico real en orden cronológico. CAPÍTULOS Por qué existe Thread, y quién lo estandariza Anatomía de una malla: roles, líder y autocuración El border router: lo que hace y lo que no Matter: el idioma, no la carretera Las dos arquitecturas al montar el tuyo Entrar en la red Thread que ya creó Apple El border router que se moría cada minuto Elegir canal con datos: escaneo de energía y migración Tres border routers y por qué la geometría manda Las tormentas de suscripciones, y cómo se arreglaron LOS NÚMEROS DEL EPISODIO 400 reinicios del border router en 13 horas, sin que se notara en casa Canal 25 a -49 dBm de ruido; canal 20 a -79 dBm. Treinta decibelios Tras migrar: 4 esperas por canal ocupado en 193.521 transmisiones Y cero tramas corruptas de 710.000 recibidas Final: 16 nodos Matter, 16 routers Thread, 3 border routers, una sola red LAS CINCO LECCIONES El tiempo de funcionamiento es el primer dato, no el último La redundancia esconde fallos: mi red funcionaba con dos averías dentro El canal se elige midiendo; lo que ganas es margen, no potencia La ubicación gana al hardware Cuando la radio está sana y aun así falla, sube de capa ENLACES OpenThread Thread Group Connectivity Standards Alliance
Desde hace más de un año, los bloqueos judiciales de LaLiga contra la piratería afectan a IPs enteras de proveedores CDN como Cloudflare, dejando fuera de juego a cientos de sitios legítimos que nada tienen que ver con el fútbol. Un estudio de OONI (junio 2026) encontró más de 554.000 dominios afectados por estos bloqueos. Ha aparecido una herramienta pensada para paliar justo ese daño colateral: xdp.es, un servidor DNS público y gratuito que reescribe respuestas DNS para esquivar direcciones bloqueadas, sin necesidad de recurrir a una VPN. ¿Cómo funciona? Detecta cuándo una IP dentro de los prefijos de Cloudflare (AS13335) está bloqueada. Sustituye esa IP por otra del mismo prefijo que no esté afectada. Funciona gracias a SNI (Server Name Indication, RFC 6066): el enrutamiento real al sitio lo decide el nombre de dominio enviado en el handshake TLS, no la IP de entrada. Servicio opt-in: el usuario elige activamente cambiar de resolver. ¿Es esto “hacer trampas” con el protocolo DNS? En el episodio analizamos la tensión entre: RFC 1035 — el DNS nunca ha garantizado una única “respuesta verdadera” por dominio (GeoDNS y el propio anycast ya varían la respuesta). RFC 3833 (Threat Analysis of the DNS) — describe este patrón de sustitución de respuestas como parte del modelo de amenazas contra el que se diseñó DNSSEC. RFC 7754 y RFC 8890 (principios IETF sobre bloqueo de servicios y el usuario final) — el factor decisivo es el consentimiento: a diferencia de los bloqueos de los operadores, xdp.es es una elección voluntaria del usuario. Enlaces: xdp.es Prueba de rendimiento (RedesZone) Contexto OONI y cifras de uso (El Chapuzas Informático) Servidor secundario de xdp.es (bandaancha.eu) Implementación de referencia en Rust (GitHub) Episodios relacionados: Ep. 43 (bloqueos de LaLiga), Ep. 93 (LaLiga contra los principios de Internet), Ep. 44 (proxies inversos con Cloudflare), Ep. 40 (DNS y DDNS)
Apple ya controla casi todo el módem de sus iPhone: el nuevo C2 añade mmWave en EE. UU. y dejará a Qualcomm en un solo modelo. Y el iPhone Handoff permite mover tu número entre dos iPhone… si tu operador coopera. Repaso de conectividad del evento del 9 de septiembre.
Un monoplaza de F1 transmite telemetría, vídeo, audio y GPS en tiempo real a más de 300 km/h, rodeado de otros veinte coches compitiendo por el mismo espectro. En este episodio abrimos el capó de la red, no del motor: por qué 4G/5G, DECT o Wi-Fi nunca fueron una opción; cómo se coordina la frecuencia de cada equipo (1.45-1.65 GHz) carrera a carrera en países distintos; y la arquitectura completa que lleva la señal desde el coche hasta tu televisor, pasando por el Event Technical Centre, 54 km de cable por circuito y dos enlaces de fibra de 10 Gbps hacia el centro de distribución global.
El secreto del núcleo de red de Digi Los 7,7 millones de líneas móviles de Digi consumen al mes casi tantos datos como los 20,4 millones de Telefónica, su socio de red. Un usuario de Digi mueve de media 18,8 GB al mes, frente a los 8,5 GB de Telefónica, 7,6 GB de Orange o 4,7 GB de Vodafone. ¿Cómo aguanta Digi ese nivel de consumo ofreciendo, además, la tarifa de datos ilimitados más barata del mercado (10€/mes, o 5€ empaquetada con fibra) y sin los límites ocultos que sí tienen otras “ilimitadas”? El secreto: el packet core propio La mayor parte del núcleo de red de Digi usa software de Nokia, Ericsson o Huawei, como el resto del sector. Pero hay una pieza que Digi ha decidido programar por su cuenta: el packet core, el componente que da salida a Internet a todo el tráfico de datos de sus usuarios. Lo cuenta la propia Digi en su folleto de salida a bolsa: los proveedores tradicionales cobran en función del número de suscriptores y el tráfico que generan, así que cuanto más consumen los usuarios, más factura el operador. Programar el packet core internamente le permite pasar a un modelo de pago por capacidad, como en banda ancha fija, en vez de pagar por cada gigabyte extra. ¿Y el RAN de Movistar? Digi también explica cómo esto convive con su acuerdo con Movistar: en las zonas sin antena propia usa roaming nacional (el core de Movistar gestiona la sesión), y en RAN sharing reutiliza el hierro de las antenas de Movistar pero mantiene su propio core. La clave para que esto funcione con un core casero: el 3GPP estandariza la interfaz entre antena y núcleo de red precisamente para que sea independiente del fabricante. ¿Y las caídas de servicio? Desarrollar un componente tan crítico por tu cuenta tiene riesgos. En el episodio repaso las caídas de Digi de diciembre de 2025 y abril de 2026 y matizo hasta qué punto están realmente relacionadas con esta pieza (spoiler: no está tan claro como parece). Relacionado en RTS/CTS Ep. 111. ¿Qué es una OMV? — el extremo opuesto: un operador sin ninguna red propia. Enlaces Artículo original en bandaancha.eu Folleto de salida a bolsa de Digi (CNMV), pág. 135 5G de Digi ya mueve más tráfico que Vodafone Digi comparte frecuencias con Movistar Se disparan las quejas por los fallos del móvil de Digi (CNMC)
¡Primer episodio de la cuarta temporada del podcast! Te vas de vacaciones tranquilo y, a los pocos días, se te cuelga el minipc que sostiene medio homelab. Sin acceso físico y sin forma de reiniciarlo… hasta que acabas llamando al vecino para que entre en casa a darle al botón. En este episodio cuento ese pequeño desastre y cómo me llevó a rediseñar el setup para no volver a depender de nadie: reinicio remoto del minipc, fiable y sin cloud obligatorio. Lo que cuento en el episodio: El incidente: minipc colgado en plenas vacaciones y por qué me dejó medio homelab tirado. El favor incómodo: pedirle a un vecino que entrara en casa a reiniciarlo a mano. Por qué las soluciones “obvias” no me valían: Zigbee/Thread (el coordinador vive en el propio minipc, así que dependería justo de lo que quiero reiniciar) y vPro/AMT (imposible en un Intel N100). La decisión: un enchufe inteligente WiFi colgado del SAI, con requisitos muy claros — fiable, que no corte la corriente al actualizar el firmware, pequeño para que quepa en la regleta del SAI, y con control local y en la nube a la vez. El elegido: Shelly Plug S MTR Gen3.