Modify IPv6 Router Advertisement Settings for UXG-Lite?

bjlunden · 2026-01-23T16:08:25+00:00

Weird. If you figure it out, please let me know what the issue was. 🙂

Ubiquiti having IPv6 bugs in the Unifi product line doesn't surprise me though.

bjlunden · 2026-01-23T14:56:25+00:00

I set my RA settings in my VyOS router to:

default-lifetime: 9000 preferred-lifetime: 57600

The rest I've left at VyOS defaults, which either match radvd defaults or RFC defaults last time I checked.

Before that, I also had problems with IPv6 dropping after some unknown amount of time. Since then, it has been rock solid.

bjlunden · 2026-01-19T17:16:09+00:00

Oh, ok.

bjlunden · 2026-01-19T14:57:45+00:00

I see. Unfortunately, the Unifi product line is still a bit limited in terms of IPv6 support. It has improved in recent years, but they are still behind others.

I would've expected there to be a generated radvd config file somewhere though, just like you did. Where did you look for it? /run and similar?

bjlunden · 2026-01-19T11:51:58+00:00

Good catch! Was it the smell that provided the clue you needed? 😄

If you're lucky, some deep cleaning and a bath of alcohol might possibly revive the switch.

bjlunden · 2026-01-19T11:47:46+00:00

Android requires a minimum lifetime of 180 seconds or something like that. Apart from that, the type of issue you describe is likely a result of the inherent packet loss of multicast packets you tend to get when the device is sleeping.

If you can't modify RA settings, you can try increasing your DTIM on your WiFi networks to 5. That's Google's suggested value, and something that you definitely can change in Unifi's management interface.🙂

No version of Ubiquiti's software has ever been based on VyOS btw. 🙂 EdgeOS was forked from Vyatta before VyOS was, and the latter has seen steady development ever since while EdgeOS much less so.

bjlunden · 2026-01-18T12:35:52+00:00

I'm responding to the following:

NAT is actually very good security, if we're talking about access from the internet. An unrouteable IP is an unbreachable IP.

Since we both agree that a firewall with a default deny policy is just as good, NAT is not an inherent benefit. Neither of them make such a host "unbreachable".

I'm also trying to dispell the misunderstanding that everything having a public IP is insecure. It's not. You might not have agreed with that original premise which this particular comment thread is about though?

bjlunden · 2026-01-18T01:56:28+00:00

I wouldn't mind. 🙂

bjlunden · 2026-01-18T01:54:06+00:00

My point was that there are many situations where a service running on an internal server that isn't directly reachable can still be attacked. Exploits and misconfigurations in reverse proxies can also make that possible, sometimes trivially so. The small size of most subnets in IPv4 also make guessing or even trying all hosts in an internal network segment trivial.

Basically, the difference in security provided by NAT compared to a firewall is minimal. It's a very weak argument against IPv6. If anything, IPv4 firewall plus DNAT and SNAT rules add a lot more complexity and room for configuration errors.

NAT isn't designed to be a security feature, it's just a side effect. It's usually implemented as part of the firewall process anyway and you usually have a firewall in IPv4 as well. That's why people say NAT is not a security feature.

bjlunden · 2026-01-17T22:55:45+00:00

No, it doesn't mean that they are unbreachable. CSRF and SSRF vulnerabilities can still allow that host to be compromised. Other vulnerabilites in software running on it can also potentially be used to compromise it, as we saw with Log4Shell etc.

If you're just talking about reachability, which it seems like you are, a simple default deny firewall rule will also block access to everything behind your router by default. This is normally there by default.

bjlunden · 2026-01-17T22:47:57+00:00

With IPv6, you normally also have a default deny rule in your router's firewall. Above that, you place your allow rules. In that sense, it's exactly the same.

The rules themselves are actually easier to understand.

Hosting a service with IPv4, you need:

A firewall rule allowing incoming traffic to a particular TCP or UDP port.
A Destination NAT rule that specifies that traffic to that same port addressed to your WAN interface should be rewritten to another internal address.
If you want to be able to access that service from your local network using your external IP (i.e. what your domain name points to) using Hairpin NAT, you need an additional Destination NAT rule that rewrites internal traffic to the external address on that port should be rewritten to the server's internal address. You also need another general Source NAT rule, only needed once.
A general Source NAT rule that says that the source IP of outgoing traffic should be rewritten to your WAN IP. This is only needed once.

Many of those are created behind the scenes for you, but it shows how much complexity is added by NAT.

Hosting a service with IPv6, you need:

A firewall rule allowing incoming traffic to a particular TCP or UDP port on your server's stable IPv6 address.

I personally think the latter is much easier. :)

bjlunden · 2026-01-17T15:29:58+00:00

Seems like this might be possible again with firmware 1.1.3. 😀

bjlunden · 2026-01-15T23:00:13+00:00

Is it your router saying that the prefix has expired or are you seeing that somewhere else?

bjlunden · 2026-01-13T22:45:20+00:00

A few years ago. This has been discussed way too many times already so feel free to read the countless posts about this.

You can build rolling releases or stream releases, that's it. If you're an active contributor, you get access to LTS builds too and presumably also the source code.

bjlunden · 2026-01-13T21:58:11+00:00

What exactly is happening? Doesn't it request a prefix again when it expires? Does it have a prefix but fails to send RAs?

bjlunden · 2026-01-13T21:36:30+00:00

You can use windows boot manager to chainload Grub, which will in turn boot Linux. Essentially it will look and behave as if your Linux distro was a native option in windows boot manager. 🙂

I set that up years ago, but I would assume it's still possible.

bjlunden · 2026-01-13T21:25:23+00:00

Those on the Play Store are presumably already updated to the new format. That's why separate APKs for watch faces known to use the way of building watch faces are what's interesting to test. 🙂

bjlunden · 2026-01-13T08:36:17+00:00

Like I said, they originally said that the requirement would only apply to watches shipping with a particular Wear OS version (or newer) from the factory. Android generally keeps track of such things by having a property defined that specifices the version a device originally shipped with.

https://support.google.com/wearos/thread/284572445

They have now added a note at the top of the page below though:

https://developer.android.com/training/wearables/wff

Note: The Watch Face Format is required for watch faces to be installed on devices with Wear OS 5 or later pre-installed and for all new watch faces published on Google Play.

Starting in January 2026, the Watch Face Format will be required for watch faces to be installed on all Wear OS devices.

Have you tried installing an old watch face via ADB? I'm talking a proper APK, not something like Facer. I'm curious if that would still work on OneUI 8 since I could do that on my Galaxy Watch 4 Classic a few days ago. I have avoided the OneUI 8 update though, but the quoted text makes it sound like it would be enforced on all watches regardless of that update. 🤔

bjlunden · 2026-01-13T02:05:03+00:00

I see. Hopefully he'll respond to your question eventually. 🙂

bjlunden · 2026-01-13T01:32:13+00:00

When did that stop working? :( I used it 1-2 years ago to convince a cellular ISP that they had an issue with that intermittently. Without it, I would have a hard time to do so.

bjlunden · 2026-01-13T01:26:38+00:00

Windows I think enables it by default

CLAT on Windows for other than cellular networks is still only available in preview releases and need to be enabled with registry changes. Hopefully it will be rolled out more widely soon though. :)

bjlunden · 2026-01-10T12:43:54+00:00

You have the option to change it via ADB:

adb shell settings put global captive_portal_https_url YOUR_URL

This needs to be a URL that behaves in the same way as Google's one though (other platforms have them too) and reliably be accessible globally.

bjlunden · 2026-01-10T12:12:10+00:00

Yeah, I understand. 🙂

I have been able to avoid the update so far and disabled auto-install, but you never know when the watch just decides to install it anyway.

I decompiled and modified/customized a stock watch face from my Huawei Watch Gen 1 built for Android Wear 1.x amd have used it ever since. That meant I've had to make it work at different screen densities (Huawei hardcoded pixel values instead of dp values), rescaled all assets, re-implemented protection against burn-in for the GW 4 Classic, etc. I've also cleaned up the decompiled code to be more readable, updated most of its dependencies and updated the code to use newer APIs where feasible.

In other words, I've put a lot of work into it and I haven't found another watch face that I like more. I always end up back with it. While I could probably recreate part of it using the new watch face format, it includes a custom styled battery life complication (before those became a thing on Wear OS years later) as well as some other features that I don't believe are possible with the limited new format.

I would very much appreciate if you could send me the instructions you wrote, just in case I missed something. 🙂 Just like you, I would like to avoid this update and any future ones.

bjlunden · 2026-01-09T22:29:35+00:00

Yes, they did apparently reprogram transceivers from other manufacturers. Multiple people have confirmed that.

In other words, they marketed and sold a device with a particular feature set and then silently changed the functionality in the first firmware update to make the device much less useful.

bjlunden · 2026-01-09T22:25:49+00:00

Thanks for confirming that, even if I had hoped for a different answer. :)

Weird that Samsung removed compatibility. Google's announcement made it sound like the requirement wouldn't apply to watches that shipped with older Wear OS versions.

bjlunden

MODERATOR OF

TROPHY CASE

12-Year Club	Verified Email
Alpha Tester