What people believe

The idea gets around a lot: if you want another IP, turn airplane mode on for a few seconds and turn it off again. And it often works, which is why people keep repeating it. The problem is the «always»: sometimes the IP comes back the same, and not always for the same reason

What actually happens

To understand it you have to separate two IPs that tend to get mixed up. When the phone uses mobile data, it opens a data session with the carrier's network (in LTE it's called a PDN connection), and the core of that network assigns it an IP. With many carriers that IP is private: the phone doesn't reach the internet with it, but through a CGNAT, a carrier-side NAT that shares a few public IPs among a huge number of users

phone
 │ data session
 ▼
tower ──► carrier core
            │ assigns a private IP (for example 10.x.x.x or 100.64.x.x)
            ▼
          CGNAT
            │ translates it to a shared public IP
            ▼
          what the internet sees: 190.130.xxx.204

The 100.64.0.0/10 range exists precisely for this: RFC 6598 reserved it for the space between a carrier and its CGNAT. And RFC 6888 requires that, by default, a CGNAT keep the same public IP for the same internal IP while it's in use («paired pooling»), so a user's connections don't go out through different addresses

When airplane mode really powers the radio off, that session closes. When it comes back, the phone opens a new session and the carrier assigns it an IP again, usually a different one. But what the internet sees depends on which public address the CGNAT hands it: it may be a new one, or the same one as before

That's why the result isn't guaranteed. There are at least three reasons for the IP to come back the same:

• The radio didn't really go off. If only a setting changes, the session stays open and the carrier has no reason to give you another IP. That's exactly what happened in my first attempt
• The CGNAT gives you the same public IP again. The session is new, but the shared address you get can repeat
• What's being measured isn't the mobile network. If Wi-Fi is still on, traffic goes out through the home internet, and that IP won't change no matter how many times you toggle airplane mode

ideaIn short: airplane mode isn't what changes the IP. What can change it is the data session closing and a new one opening; airplane mode is just one way to trigger that, and it doesn't always manage to

The first attempt

IP Rotator's modes A and B used this:

$ adb shell settings put global airplane_mode_on 1

It looked like it worked, because the setting changed. But the radio logs (logcat -b radio) told a different story: the radio never let go of the tower. The command only flipped a stored value, so the carrier kept the same CGNAT session and the same IP

In December 2025 the verdict went into the v0.1.0 README: ADB couldn't do it without system permissions

The right command

Six months later, while I was building Goket (my network panel), Claude found another way:

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

The difference is the path it takes. This command goes through ConnectivityService, the same path as the system toggle, and it really powers the radio off. It works without root since Android 12. On Android 16, the old AIRPLANE_MODE broadcast can't even be sent from ADB anymore: it throws SecurityException

The details that mattered

The command alone wasn't enough. It took three more things:

• The phone's Wi-Fi is switched off during the test (svc wifi disable). Otherwise tethering goes out through the home internet and the measured IP isn't the carrier's
• Under CGNAT a new IP isn't guaranteed on the first try, so it repeats short cycles: 7 s off, 12 s to settle, up to 5 times
• The IP is measured through the tethering interface (curl --interface), so the PC never loses its own internet

In the real test on September 30, 2026, the IP changed on the first try, in 20 s. It shipped as v0.2.0

Other ideas, untested

If what changes the IP is the data session closing and a new one opening, airplane mode shouldn't be the only way. Two ideas I'm writing down, not tested yet:

• Turning only mobile data off and on. It would close the data session without powering off the whole radio, and it might be faster than a full airplane-mode cycle
• Switching the preferred network type. Going from 5G or 4G down to 3G and back would make the phone register with the network again, and so open a new session

If either one works, it would need to be checked the same way as airplane mode: measure the IP before and after, and look at the radio logs

Limits

• What was measured comes from a single phone and a single carrier. Another carrier may assign IPs differently, or even give a fixed IP per line
• How many cycles it takes to get a new IP depends on the carrier's CGNAT; the 5 attempts are a practical cap, not a number measured in general
• The two ideas above are hypotheses: there's no data yet

What stuck with me

December's verdict was true for that command: with it, it really couldn't be done. What was wrong was treating the question as closed when what had failed was the tool. And it was the radio logs, not intuition, that showed where the problem was

What a phone knows about the network

A connected phone knows more than it shows: the country and carrier (MCC and MNC), the area (LAC in 3G, TAC in LTE and 5G), the cell serving it (Cell ID) and the signal quality. In LTE, the reference signal power is measured as RSRP and its quality as RSRQ (both defined in the 3GPP TS 36.214 specification); RSSNR is the signal-to-noise ratio. CellTraceLogger records all of it, on 5G NR, LTE and 3G

observation (one NDJSON line)
 │ MCC · MNC · TAC · Cell ID · RSRP · RSRQ · RSSNR
 ▼
celltrace ◄── OpenCellID: Cell ID → approximate position
 │ does one cell dominate over time? is the signal stable?
 ▼
most likely tower · confidence

Mind what a Cell ID identifies: the cell, usually one sector of an antenna, not an exact point. And a cell's position in OpenCellID comes from crowdsourced measurements, so it's approximate too. That's why celltrace infers infrastructure (which tower or sector), not where a person is

celltrace: low, medium or high confidence

Every inference comes with a confidence level, based on how stable the signal was and whether one cell dominates over time. If cells overlap or the network is unstable, it says so instead of picking one. The project page has a simulation: when the phone sits between two towers, the observations split and confidence goes down

AccessScope: rules that vote

AccessScope joins a Minecraft server like a player would (with Mineflayer) and classifies what the server replies: the kick message, the MOTD, the version. The classification uses hand-written rules, and the rules vote. If two point to different things, the result is «ambiguous» and none is picked:

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

  whitelist  ✓  → whitelist
  ban        ✓  → ban
  ─────────────────────────────
  result        → ambiguous

It doesn't stretch the evidence either: an account problem isn't reported as a ban, because it's no evidence of one

The underlying idea: abstaining

This has a name in pattern recognition: a classifier with a reject option. C. K. Chow formalized it in 1970: if a system can decline to decide in doubtful cases, it makes fewer errors on the ones it does decide, at the cost of answering less often. It's a trade-off between precision and coverage

always answer        → high coverage, more errors stated with confidence
abstain when unsure  → lower coverage, fewer errors in what gets answered
                       and the doubtful cases stay in plain sight

Both tools pick the second side. And in AccessScope the aggregation rule is conservative on purpose: the majority doesn't win, there has to be no contradiction

ideaA wrong answer stated with confidence does more harm than an «I don't know». If the tool admits doubt, whoever uses it knows when to trust it and when to take a closer look

Limits

• AccessScope's rules only cover messages I've already seen; a new one stays unclassified until its rule is written. That happened with a ban message in Spanish it didn't recognize at first
• celltrace's quality depends on how many cells in the area are in OpenCellID; where data is scarce, confidence drops even with a good signal
• I didn't measure how much precision goes up by abstaining: the argument is a design one, not an experimental result

The underlying problem: two leaders

In distributed systems this is known as split-brain: two nodes believe at the same time that they're the leader, and each one accepts changes on its own. When they meet again there isn't one correct version, there are two. In a Minecraft world that means lost builds or inventories

jukz avoids it in two ways: by asking before opening, and by using a generation number to settle the case where two people open the world at once

Opening a world is asking

Every world has a permanent UUID and a short share code. When you open it, jukz asks whether someone already has it open: on the same network, over multicast; from different homes, through a rendezvous server of my own written in Rust (Axum). If someone has it, you join that person's world live. If not, it opens on your PC and you're announced as the host

At first I had planned a DHT for finding each other, but it got dropped: the rendezvous server was simpler and more reliable

Never two hosts

Every announcement carries a token with a generation number. If two people open the same world at the same time, the newest generation wins and the other one finds out: they can keep their local copy or join the live game as a guest

Nob opens the world        → host, generation 7
Kai opens it at once       → host, generation 8
                             8 wins
Nob finds out              → keeps the local copy
                             or joins as a guest

It's the same idea Martin Kleppmann describes as a fencing token: a number that only goes up and travels with whoever holds the permission. Anything that arrives with an old number is recognized as old, even if its owner still thinks it's in charge

Getting through each home's NAT

For a friend to join the world, their PC has to reach the host's, and there's almost always a router doing NAT in between. jukz combines three pieces:

UPnP ──► the host asks its router to open a port
STUN ──► each PC finds out what its public address is
 │ if the port can't be opened (behind CGNAT, for example)
 ▼
WebSocket relay on the rendezvous server: joins the two outgoing connections

The last step is the same idea TURN standardizes (RFC 8656): if two machines can't connect directly, both connect outward to a third party that passes the data along. It costs a bit more latency, but it works even when neither can accept incoming connections

Handing the world over

When the host quits with guests connected, it saves, snapshots the world with JGit and hands it to a guest, who applies it and carries on as the host. If it quits with nobody around, the snapshot goes up to the cloud (R2) and the next person to open the world downloads it and picks up from there

This didn't work the first time. On June 11 the world fell out of sync: handing it to the next host was losing changes. The fix was a WebSocket relay on the rendezvous server, which carries the world copy

Testing it without opening the game

The hard logic (picking the host, the tokens, the protocol) lives in a pure Kotlin module, with no Minecraft in it, and 67 tests that run in seconds. Handing the world over was tested inside the game, including a round trip A → B → A

ideaKeeping the hard logic apart from the game made it possible to test the odd cases (two opens at once, a host that leaves) in seconds, without launching Minecraft every time

Limits

• It's meant for small groups of friends: one host at a time means the world depends on the PC and connection of whoever is hosting at that moment
• The automated tests cover the logic; the real network was tested by hand, not with many players or under hard network conditions at scale
• The relay adds one more hop: it's the last resort, not the ideal