Repository navigation
Conversation
-u <prefix> (ULA in ap.conf) takes a /48 in fd00::/8 and sets vaplan's ip6addr to its /64 numbered after the gateway's third octet, ::1 for the gateway, the way ipaddr sets the IPv4 side. It is written on every start, so a changed prefix replaces the old one. Empty, the default, keeps the /64 from the container's own ULA. Droidspaces' fd64:7370::/48 is refused, since the container's uplink uses it. Signed-off-by: poqdavid <poq-david@live.com>
Managed mode's Advanced card gets an IPv6 prefix box: a random /48 in fd00::/8 picked once and kept in ap.conf, editable, showing the /64 and gateway the hotspot gets. An invalid prefix blocks Start through isValid(). Signed-off-by: poqdavid <poq-david@live.com>
How-It-Works describes the ULA setting, its fallback to the container's own ULA, and that both addresses are rewritten on every start. Signed-off-by: poqdavid <poq-david@live.com>
|
It is better to allow the address to be specified manually. Example: I can use |
Oh thats a good point i will make that change while keeping the once randomly generated ula and i will add another setting for specifying ipv6 address under the ipv4 |
-G <address> (IP6_GW in ap.conf) sets vaplan's ip6addr to that address with its /64, ahead of -u. It takes a global or unique local unicast address, in 2000::/3 or fc00::/7, bare or with /64, and a bare /64 gets ::1. On a ULA-only LAN clients rank IPv6 below IPv4 and barely use it; a prefix outside fc00::/7, such as 2001:db8::/32 or 3fff::/20, makes them prefer it. Anything else, or an address in Droidspaces' fd64:7370::/48, is refused with a warning and -u applies. Managed mode only. Signed-off-by: poqdavid <poq-david@live.com>
Managed mode's Advanced card gets an IPv6 gateway box under Gateway IP, saved as IP6_GW, with the address the IPv6 prefix gives as its hint. The prefix box moves up under it, out of the MAC boxes, and is greyed out but kept while a gateway is set, so clearing the gateway brings the same /64 back. The address is parsed by hand: InetAddress sends what it cannot parse to DNS, and the numeric-only parser needs API 29. Signed-off-by: poqdavid <poq-david@live.com>
How-It-Works lists where the LAN's IPv6 comes from, IP6_GW first, why a prefix outside fc00::/7 matters to clients, and that it needs masq6 in the container to get out. Signed-off-by: poqdavid <poq-david@live.com>
|
I just did some changes once i finish testing them i will add a screenshot of the changes as well |
What's new
Why it mattersThe container still has to route that IPv6 out (with fw3, an ip6tables MASQUERADE rule from a firewall include; with fw4, UIIn managed mode, the Advanced section is now ordered: Gateway IP → IPv6 gateway → IPv6 prefix → MAC mode → MAC address. The IPv6 gateway box shows the address the prefix would give as its hint. The prefix box is greyed out while a gateway is set. @kokoromagic Thanks for the suggestion about setting the address by hand. I've pushed a few more commits on top of the ULA prefix work. |
The script provisions fw3 on iptables-legacy, which has no masq6 option: there the LAN's IPv6 goes out through an ip6tables MASQUERADE rule that a firewall include adds. masq6 on the wan zone is fw4's way. Signed-off-by: poqdavid <poq-david@live.com>
dhcp.vaplan.ra_flags gets managed-config beside odhcpd's default other-config. Clients that do DHCPv6, Windows and Linux among them, then take an address from it beside SLAAC's, so a static lease's IPv6 suffix reaches them; with other-config alone they ask it for DNS only. Android never asks and keeps SLAAC. Set on every start, like the other keys. Signed-off-by: poqdavid <poq-david@live.com>
How-It-Works says the router advertisements carry the managed and other-config flags, and what that gives Windows and Linux clients. Signed-off-by: poqdavid <poq-david@live.com>
Problem
In managed mode VirtualAP writes the LAN's IPv4 side into the container itself (
network.vaplan.ipaddrfromIP_GW), but the IPv6 side was left toip6assign 64, a /64 out of whatever ULA the container happened to generate at first boot. The hotspot's IPv6 prefix couldn't be seen or set from the app, changing it meant editing the container by hand, and a new or reinstalled container came with a new ULA, so every client on the hotspot was renumbered with it.Fix
The backend gets
-u <prefix>, saved inap.confasULA: a /48 infd00::/8.openwrt_provision()setsnetwork.vaplan.ip6addrto its /64 numbered after the gateway's third octet, the same way theip6hintfrom #6 and the routed NAT66 /64 number it, with::1as the gateway, the way.1is for IPv4. Sofd12:3456:789a::/48with192.168.42.1givesfd12:3456:789a:42::1/64. It's written on every start, so a changed prefix replaces the old one, andip6assignis removed so the container doesn't add a second /64 from its own ULA beside it. Empty, the default, keeps today's behaviour: a /64 from the container's ULA, pinned byip6hint. A prefix outsidefd00::/8, one that isn't a /48, or Droidspaces' ownfd64:7370::/48, which the container's uplink already uses, is a warning and falls back to that default, not a failed start.ula_lan()has a test intests/check.c.In the app, the Advanced card in managed mode gets an IPv6 prefix box under the gateway MAC. It holds a random /48 (RFC 4193's 40 random bits after
fd), picked once and kept inap.conf, so no two hotspots share a prefix. It's editable, and it shows the /64 and gateway the hotspot will get. An invalid prefix blocks Start throughAPConfig.isValid(), so the Quick Settings tile follows it too. Anyone who wants to keep the prefix their container already hands out can type its ULA in, and the hotspot stays on the same /64.How-It-Works.md describes the setting and its fallback.
Tested on my device in managed mode with the OpenWrt container