Lo que se cree

La idea circula mucho: si quieres otra IP, activa el modo avión unos segundos y vuelve a desactivarlo. Y muchas veces funciona, por eso se repite. El problema está en el «siempre»: a veces la IP sale igual, y no siempre por la misma razón

Qué pasa de verdad

Para entenderlo hay que separar dos IP que se suelen confundir. Cuando el celular usa datos móviles, abre una sesión de datos con la red del operador (en LTE se llama conexión PDN), y el núcleo de esa red le asigna una IP. Con muchos operadores esa IP es privada: el celular no sale a internet con ella, sino a través de un CGNAT, un NAT del operador que reparte unas pocas IP públicas entre muchísimos usuarios

celular
 │ sesión de datos
 ▼
torre ──► núcleo del operador
            │ asigna una IP privada (por ejemplo 10.x.x.x o 100.64.x.x)
            ▼
          CGNAT
            │ la traduce a una IP pública compartida
            ▼
          lo que ve internet: 190.130.xxx.204

El rango 100.64.0.0/10 existe justamente para esto: el RFC 6598 lo reservó para el espacio entre el operador y su CGNAT. Y el RFC 6888 pide que, por defecto, un CGNAT mantenga la misma IP pública para una misma IP interna mientras dure su uso («paired pooling»), así las conexiones de un usuario no salen por direcciones distintas

Cuando el modo avión apaga el radio de verdad, esa sesión se cierra. Al volver, el celular abre una sesión nueva y el operador le vuelve a asignar una IP, que normalmente es otra. Pero lo que ve internet depende de qué dirección pública le toque en el CGNAT: puede ser otra, o puede repetirse la de antes

Por eso el resultado no es seguro. Hay al menos tres razones para que la IP salga igual:

• El radio no se apagó de verdad. Si solo cambia un ajuste, la sesión sigue abierta y el operador no tiene por qué darte otra IP. Es justo lo que pasó en mi primer intento
• El CGNAT te vuelve a dar la misma IP pública. La sesión es nueva, pero la dirección compartida que te toca puede repetirse
• Lo que se mide no es la red móvil. Si el Wi-Fi sigue encendido, el tráfico sale por el internet de la casa, y esa IP no cambia por más veces que actives el modo avión

ideaEn resumen: el modo avión no es lo que cambia la IP. Lo que la puede cambiar es que la sesión de datos se cierre y se abra otra; el modo avión es solo una forma de provocarlo, y no siempre lo logra

El primer intento

Los modos A y B del IP Rotator usaban esto:

$ adb shell settings put global airplane_mode_on 1

Parecía funcionar, porque el ajuste cambiaba. Pero los registros del radio (logcat -b radio) contaban otra historia: el radio nunca soltaba la torre. El comando solo cambiaba un valor guardado, así que el operador mantenía la misma sesión de CGNAT y la misma IP

En diciembre de 2025 la conclusión quedó escrita en el README de la v0.1.0: ADB no podía hacerlo sin permisos de sistema

El comando correcto

Seis meses después, mientras armaba Goket (mi panel de red), Claude encontró otro camino:

$ adb shell cmd connectivity airplane-mode enable
$ adb shell cmd connectivity airplane-mode disable

La diferencia está en por dónde pasa. Este comando va por ConnectivityService, el mismo camino que usa el botón del sistema, y sí apaga el radio de verdad. Funciona sin root desde Android 12. En Android 16, en cambio, el aviso viejo de AIRPLANE_MODE ya ni siquiera se puede mandar desde ADB: lanza SecurityException

Los detalles que hicieron falta

El comando solo no alcanzaba. Hicieron falta tres cosas más:

• El Wi-Fi del celular se apaga durante la prueba (svc wifi disable). Si no, el tethering sale por el internet de la casa y la IP que se mide no es la del operador
• Con CGNAT no hay garantía de IP nueva al primer intento, así que se repiten ciclos cortos: 7 s apagado, 12 s para estabilizarse, hasta 5 veces
• La IP se mide por la interfaz del tethering (curl --interface), así el PC no pierde su propio internet en ningún momento

En la prueba real del 30 de septiembre de 2026 la IP cambió al primer intento, en 20 s. Salió como la v0.2.0

Otras ideas, sin probar

Si lo que cambia la IP es que la sesión de datos se cierre y se abra otra, el modo avión no debería ser el único camino. Dos ideas que quedan anotadas, todavía sin probar:

• Apagar y prender solo los datos móviles. Cerraría la sesión de datos sin apagar todo el radio, y quizás sería más rápido que un ciclo completo de modo avión
• Cambiar el tipo de red preferida. Pasar de 5G o 4G a 3G y volver obligaría al celular a registrarse de nuevo en la red, y con eso a abrir otra sesión

Si alguna funciona, habría que comprobarla igual que el modo avión: medir la IP antes y después, y mirar los registros del radio

Límites

• Lo medido sale de un solo celular y un solo operador. Otro operador puede asignar las IP de otra forma, o incluso dar una IP fija por línea
• Cuántos ciclos hacen falta para una IP nueva depende del CGNAT del operador; los 5 intentos son un tope práctico, no un número medido en general
• Las dos ideas de arriba son hipótesis: no hay datos todavía

Lo que me quedó

La conclusión de diciembre era cierta para ese comando: con él, de verdad no se podía. Lo que estaba mal era dar la pregunta por cerrada cuando lo que había fallado era la herramienta. Y fueron los registros del radio, no la intuición, los que mostraron dónde estaba el problema

Qué sabe un celular de la red

Un celular conectado sabe más de lo que muestra: el país y el operador (MCC y MNC), el área (LAC en 3G, TAC en LTE y 5G), la celda que lo atiende (Cell ID) y la calidad de la señal. En LTE, la potencia de la señal de referencia se mide como RSRP, y su calidad como RSRQ (las dos están definidas en la especificación 3GPP TS 36.214); RSSNR es la relación señal/ruido. CellTraceLogger anota todo eso, en 5G NR, LTE y 3G

observación (una línea NDJSON)
 │ MCC · MNC · TAC · Cell ID · RSRP · RSRQ · RSSNR
 ▼
celtrace ◄── OpenCellID: Cell ID → posición aproximada
 │ ¿una celda domina en el tiempo? ¿la señal es estable?
 ▼
torre más probable · confianza

Ojo con lo que identifica un Cell ID: la celda, que suele ser un sector de una antena, no un punto exacto. Y la posición de una celda en OpenCellID viene de mediciones colaborativas, así que también es aproximada. Por eso celltrace infiere infraestructura (qué torre o qué sector), no la ubicación de una persona

celltrace: confianza baja, media o alta

Cada inferencia trae un nivel de confianza según qué tan estable fue la señal y si una celda domina en el tiempo. Si hay celdas que se solapan o la red está inestable, lo dice en vez de elegir una. En la página del proyecto hay una simulación: cuando el celular queda entre dos torres, las observaciones se reparten y la confianza baja

AccessScope: reglas que votan

AccessScope entra a un servidor de Minecraft como lo haría un jugador (con Mineflayer) y clasifica lo que el servidor le responde: el mensaje de expulsión, el MOTD, la versión. La clasificación usa reglas escritas a mano, y las reglas votan. Si dos apuntan a cosas distintas, el resultado es «ambiguo» y no se elige ninguna:

mensaje: "This server is whitelisted. Banned players cannot join."

  whitelist  ✓  → lista blanca
  ban        ✓  → baneo
  ─────────────────────────────
  resultado     → ambiguo

Tampoco se estira lo que dice la evidencia: un problema de cuenta no se presenta como baneo, porque no es evidencia de eso

La idea de fondo: abstenerse

Esto tiene nombre en reconocimiento de patrones: un clasificador con opción de rechazo. C. K. Chow lo formalizó en 1970: si un sistema puede negarse a decidir en los casos dudosos, comete menos errores en los que sí decide, a cambio de responder menos veces. Es un intercambio entre precisión y cobertura

responder siempre      → cobertura alta, más errores dichos con seguridad
abstenerse si hay duda → cobertura menor, menos errores en lo que se responde
                         y los casos dudosos quedan a la vista

Las dos herramientas eligen el segundo lado. Y en AccessScope la regla de agregación es conservadora a propósito: no gana la mayoría, hace falta que no haya contradicción

ideaUn resultado equivocado dicho con seguridad hace más daño que un «no sé». Si la herramienta admite la duda, quien la usa sabe cuándo puede confiar y cuándo tiene que mirar más de cerca

Límites

• Las reglas de AccessScope solo cubren los mensajes que ya vi; uno nuevo queda sin clasificar hasta que se escriba su regla. Así pasó con un mensaje de baneo en español que al principio no reconocía
• La calidad de celltrace depende de cuántas celdas de la zona estén en OpenCellID; donde hay pocos datos, la confianza baja aunque la señal sea buena
• No medí cuánto sube la precisión al abstenerse: el argumento es de diseño, no un resultado experimental

El problema de fondo: dos líderes

En sistemas distribuidos esto se conoce como split-brain: dos nodos creen al mismo tiempo que son el líder, y cada uno acepta cambios por su lado. Cuando se vuelven a encontrar ya no hay una versión correcta, hay dos. En un mundo de Minecraft eso significa construcciones o inventarios que se pierden

jukz lo evita de dos formas: preguntando antes de abrir, y resolviendo con un número de generación el caso en que dos personas abren a la vez

Abrir un mundo es preguntar

Cada mundo tiene un UUID permanente y un código corto para compartir. Al abrirlo, jukz pregunta si alguien ya lo tiene abierto: en la misma red, por multicast; desde casas distintas, en un servidor rendezvous propio escrito en Rust (Axum). Si alguien lo tiene, entras en vivo al mundo de esa persona. Si no, se abre en tu PC y quedas anunciado como host

Al principio había planeado una DHT para encontrarse, pero quedó descartada: el rendezvous era más simple y más confiable

Nunca dos hosts

Cada anuncio lleva un token con un número de generación. Si dos personas abren el mismo mundo a la vez, gana la generación más nueva y la otra se entera: puede quedarse con su copia local o entrar como invitada a la partida en vivo

Nob abre el mundo      → host, generación 7
Kai lo abre a la vez   → host, generación 8
                         gana la 8
Nob se entera          → se queda con su copia local
                         o entra como invitado

La idea es la misma que Martin Kleppmann describe como fencing token: un número que solo crece y que acompaña a quien tiene el permiso. Lo que llega con un número viejo se reconoce como viejo, aunque su dueño todavía crea que manda

Atravesar el NAT de cada casa

Para que un amigo entre al mundo, su PC tiene que llegar al del host, y casi siempre hay un router con NAT en medio. jukz combina tres piezas:

UPnP ──► el host le pide a su router que abra un puerto
STUN ──► cada PC averigua cuál es su dirección pública
 │ si no se puede abrir el puerto (por ejemplo, detrás de CGNAT)
 ▼
relay por WebSocket en el rendezvous: une las dos conexiones salientes

El último paso es la misma idea que estandariza TURN (RFC 8656): si dos equipos no pueden conectarse directo, los dos se conectan hacia afuera, a un tercero que pasa los datos. Cuesta un poco más de latencia, pero funciona aunque ninguno pueda recibir conexiones

Pasar el mundo

Cuando el host cierra con invitados conectados, guarda, toma una foto del mundo con JGit y se la pasa a un invitado, que la aplica y sigue como host. Si cierra sin nadie, la foto sube a la nube (R2) y el siguiente que abra el mundo la descarga y sigue desde ahí

Esto no salió bien a la primera. El 11 de junio el mundo se desincronizaba: al pasarlo al siguiente host se perdían cambios. La solución fue un relay por WebSocket en el rendezvous, por donde viaja la copia del mundo

Probarlo sin abrir el juego

La lógica difícil (elegir host, los tokens, el protocolo) vive en un módulo de Kotlin puro, sin Minecraft, con 67 pruebas que corren en segundos. El paso del mundo sí se probó dentro del juego, incluida una ida y vuelta A → B → A

ideaSeparar la lógica difícil del juego hizo posible probar los casos raros (dos aperturas a la vez, un host que se va) en segundos, sin abrir Minecraft cada vez

Límites

• Está pensado para grupos chicos de amigos: un solo host a la vez significa que el mundo depende del PC y la conexión de quien hostea en ese momento
• Las pruebas automáticas cubren la lógica; la red real se probó a mano, no con muchos jugadores ni en condiciones de red difíciles a escala
• El relay agrega un salto más: es la opción de último recurso, no la ideal