[solved] Local (ULA?) IPV6 addresses: how to add?

I noticed that if the wan connection goes down the IPV6 addresses handed out by he.net are retired quite soon, so I would like to add local static addresses to supplement them. Hardly surprising, I know.

I'm sort of thinking out loud here but my idea would be to have odhcpd assign addresses out of the ULA prefix to both local router interfaces and clients. Possibly using the same ip6hint.

What is the recommended approach to this issue?

Isn't this the default behavior?

uci show network.globals.ula_prefix
uci show network.lan
uci show dhcp.lan

No idea, though it makes sense that it should be so.

network.globals.ula_prefix='fdcf:xxxx:xxxx::/48'

network.lan=interface
network.lan.ifname='eth0.101'
network.lan.type='bridge'
network.lan.proto='static'
network.lan.ipaddr='192.168.x.1'
network.lan.netmask='255.255.255.0'
network.lan.ipv6='1'
network.lan.ip6class='he_1_nyc'
network.lan.ip6hint='2'
network.lan.ip6assign='64'
network.lan.stp='1'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.limit='100'
dhcp.lan.leasetime='24h'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.ra_management='1'
dhcp.lan.force='1'
dhcp.lan.start='4'

You need to add local as well.

See: https://openwrt.org/docs/guide-user/network/ipv6/start?s[]=ip6class

1 Like

And now the IPV6 assignment on br-lan is gone :slight_smile:
As I understand it, ip6class is a filter so an empty value means trying all available prefixes.
If I comment it out, it seems to work.

ip6class is a throwback from the time I wanted to get the IPV6 assignment from my ISP to coexist on the main network (lan) with that from he.net on the secondary (guest). At the moment it is not an issue just leaving it out.

OTOH, if listing more than one class should work... ready for testing :slight_smile:

Screenshot%20from%202019-08-21%2017-49-19

network.lan.ip6class='he_1_nyc local'

1 Like

Yup, that's what I wrote. Tried again. No go.
network.lan.ip6class='he_1_nyc local'
This results in no addresses.

Sometimes reload is not enough and you need to restart the service to apply the changes:

service network restart

Also verify the name of the network interface section for the active tunnel broker interface:

network.he_1_nyc=interface
1 Like

Unless I missed something, this works in Debian but not in OpenWRT.
To restart on the router, I simply did "ifup lan" or "ifup guest", even a full "/etc/init.d/network restart" gives me the same result.

Yup, it's the same.

More testing tomorrow, if you have other suggestions.

This should work starting from LEDE 17.01.
Either your firmware version is too old or you preserved settings between major upgrades which is not recommended.
Both options may result in additional complications.

ubus call system board

I am using 18.06.4. I initially attempted to keep the settings across a minor upgrade (from .2) but from a different board and promptly got a reminder that it was indeed a bad idea (switch configuration....), After that, I manually recreated the configuration from scratch. So, no, no leftovers afaik.

{
        "kernel": "4.14.131",
        "hostname": "xxx",
        "system": "ARMv7 Processor rev 5 (v7l)",
        "model": "AVM FRITZ!Box 4040",
        "board_name": "avm,fritzbox-4040",
        "release": {
                "distribution": "OpenWrt",
                "version": "18.06.4",
                "revision": "r7808-ef686b7292",
                "target": "ipq40xx\/generic",
                "description": "OpenWrt 18.06.4 r7808-ef686b7292"
        }
}

This is actually a PBCAK: I was using the bultin shell from mc... this morning it was working as expected, this gave me a clue it was not the installation that was at fault, rather the operating habits.

1 Like

I finally understood why this did not work as expected and how it happened, so I'm documenting it here:

  • ip6class apparently cannot be set via GUI and I am not (yet) used to go through uci when configuring
  • I saw "ip6class" is a list so I had originally written it manually as "list ip6class he_1_nyc" for the guest network and "list ip6class wan6" for the lan, back when I was experimenting with dual IPV6 uplinks.
  • crucially, when I added "local" I should have added a new line in the config with just "list ip6class local"
  • "config ip6class he_1_nyc local" happens to work because the space-separated list is precisely what the list keyword expands to!
  • I had "list" and Very Bad Things happened.

Wrapping it up:
(wrong) network.lan.ip6class='he_1_nyc local'
(right) network.lan.ip6class='he_1_nyc' 'local'

To "future me" and others: either use "uci" when dealing with keywords having no GUI field OR pay close attention to the type of entry you're dealing with!

1 Like

@aboaboit - I apologize. Likewise, I'm not used to the UCI's CLI syntax - I just edit the relevant files. I realized that I never once showed you the syntax in /etc/config/network

ip6class

root@OpenWrt:~# uci show network.lan.ip6class
network.lan.ip6class='henet local'
2 Likes

https://openwrt.org/docs/guide-user/base-system/uci#corrupted_configs

1 Like

That link goes in my configuration logbook RIGHT NOW :slight_smile:

1 Like

If I understand the docs correctly, since ip6class is a list the proper way is to configure it would be this:

list ip6class 'he_1_nyc'
list ip6class 'local'

This will yield the following output:

network.guest.ip6class='he_1_nyc' 'local'

At the moment, having no corresponding GUI function means it makes no difference whether you write it as multiple list items or option with embedded spaces. I don't yet understand the inner workings of uci / luci well enough to determine 100% which one is the correct format, all I know is that mixing them like I did is bad :slight_smile:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.