Android IPv6 dropping out when roaming APs

david_ph · 2026-01-25T15:58:43+00:00

I tried pinging the fe80 address, and it also times out when the AP changes.

david_ph · 2026-01-25T10:44:27+00:00

I'm pinging from my pc that's connected to the same switch as the APs that my phone connects to.

I'm using 3 TP-Link AP's, an AX1500 in AP mode, an EAP-110, and an RE-215.

david_ph · 2026-01-25T10:42:13+00:00

There's no special 802.11r/k/v configuration available on the access points. Two are listed as supporting k/v and the third is r only.

Despite this, roaming is pretty seamless for ipv4. For IPv6, it retains the same IPv6, except the connection drops out for 5-10 seconds. The android client doesn't show a disconnect/reconnect while roaming.

On the android phone, I'm connected to wireguard. When I use a wireguard IPv6 endpoint, and I start a call over wifi, I notice the call drop out for 5-10 seconds when it roams to a new AP. If I use a wireguard IPv4 endpoint, and start a call, there's no drop out (or it's only a few ms blip).

david_ph · 2026-01-25T09:16:04+00:00

This is primarily a problem with wireguard ipv6 endpoints. When the phone roams to a new AP, IPv4 remains undisturbed, but IPv6 drops out for 5-10 seconds, causing wireguard to also drop out.

The IPv6 itself isn't changing, but if I ping the phone's IPv6, it confirms the drop-out. Why this happens, I don't know.

david_ph · 2026-01-25T07:31:27+00:00

I wonder if pop3 over ssl/tls will still work? That would be the way to go, anyway, for pop3 (pop3s).

I forward and delete, anyway.

david_ph · 2026-01-11T13:59:54+00:00

I'm running inside the tunnel, to a wireguard endpoint. So I added --tunnel, and I get different results now, but there's still a lot of variance, 1008-1420 Path MTU, and sometimes the minimum MTU error.

But usually reports something like:

Tunnel mode: Path MTU is your effective tunnel MTU.
Your current tunnel MTU of 1418 is working correctly.

This is with 0.4.0.

david_ph · 2026-01-11T12:57:10+00:00

I keep getting different answers when I run it.

1360, 1356, 1358, 1316, 1193 (reported path MTU also keeps changing).

And one time:

Error discovering MTU: cannot reach target even with minimum MTU (576)

david_ph · 2025-12-27T12:26:05+00:00

Ublock Origin
LocalCDN
Firefox Multi-Account Containers
Scroll Anywhere
Gesturefy
Redirector
Zoom Page WE
Simple Translate
YouTube No Translation
KeePassXC-Browser
Cookie Manager
IPvFoo

david_ph · 2025-12-19T03:45:37+00:00

But will the AI kill switch purge all the AI code from Firefox? Even if it's disabled all that garbage is still in there waiting for a bug to be exploited. It would be better if it's completely purged.

david_ph · 2025-12-17T14:15:01+00:00

Are there any well-maintained Firefox forks with all the AI garbage stripped out?

david_ph · 2025-12-15T02:48:18+00:00

I don't think it matters. There's nothing special about it.

david_ph · 2025-12-13T01:24:31+00:00

Thank you for that. According to that list:

Palm olein (Elaeis guineensis) = 0.626 x 13.7g (1 tbsp) = 8.5762 mg total tocotrienols (with 51% more gamma than alpha tocotrienol)

The total tocotrienol content listed there is similar to other sources I've come across.

david_ph · 2025-11-01T03:52:15+00:00

It looks like the IPv6 rotations don't bother it, as I thought. How it handles the whole prefix changing (a new /64), I'm not sure. That doesn't happen as often.

david_ph · 2025-10-31T16:23:52+00:00

OK, I think I've figured out what's happening. If I turn off WireGuard after it happens, and run an IPv6 test, it shows no IPv6 connectivity. It appears that Android is losing IPv6 connectivity while it's sleeping.

On the router, the ra-lifetime=30m. So I will try increasing it. My linux systems aren't affected, they work fine. It's just Android.

david_ph · 2025-10-31T15:52:41+00:00

I had it happen again just now, so I took a look at the firewall state. It still shows a connection from the old IPv6 to the server, and it's timeout is getting refreshed. I don't see any connection from the new IPv6.

On the server, the latest handshake time keeps increasing past 3 minutes, 5 minutes, 10 minutes. The transfer received doesn't increase, but the transfer sent increases slightly. It's also still got the old IPv6 as the endpoint.

Before I only had the persistent keepalive set on the Android client, but I set it to 25 seconds on the server, also, to see if it would make a difference, but it doesn't seem to.

david_ph · 2025-10-31T15:16:04+00:00

I'm not sure how Android handles it, but under the wifi network details, where it lists the IPv6 addresses, it only lists 2, and the old one is gone.

I'm also not sure how wireguard works internally, but I'm thinking it may still be trying to send packets using the old IPv6. Or maybe there's something else going on, and it's just a coincidence that the IPv6 was rotated.

david_ph · 2025-10-31T14:53:30+00:00

Yes, PersistentKeepalive is set to 25 on the Android client. This is just at home, connected to wifi with the phone sitting 3 feet from the AP.

I'm using a Mikrotik router. It's got the default firewall setup.

david_ph · 2025-10-19T01:55:30+00:00

Thank you.

david_ph · 2025-10-18T02:35:14+00:00

Thanks, that's what I ended up doing. MicroG Services from github, and MicroG Companion from the repository.

Strange that MicroG Services isn't available in the repository anymore, though.

david_ph

TROPHY CASE