When I ran Chaos Calmer, I was able to route a /56 through an OpenVPN link to one of my sites. However, it appears that the network configuration subsystem has gotten too clever for its own good in the upgrade to 19.07.05. If I set a static route on one of the client PCs, I can route ipv6 fine. But no amount of coercing and cajoling seems to want to make OpenWRT respect the ra server directives in its dhcp config anymore.
Is there any way to force it to do RA?
Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board; \
uci export network; uci export wireless; \
uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; \
ip -6 addr ; ip -6 ro li tab all ; ip -6 ru
Also explain which /56 prefix needs to be routed over the OpenVPN.
OK, all redacted. In the example 2001:db8:f00f:100::/56 would be the prefix I would be routing (obviously an example). The prefix I'm using (not the example) worked fine with the same router with the same configuration running Chaos Calmer.
Interestingly, I've discovered that if I manually set a default ipv6 route after the VPN tunnel is up, nothing changes, but around 30 minutes later all of my systems start getting routes distributed to them. If I could shorten that refresh to less than a minute, I could probably kludge that into my startup scripts as a sloppy workaround.
Thank you for your help. 
Here's my redacted config:
{
"kernel": "4.14.209",
"hostname": "site-router",
"system": "Atheros AR9344 rev 2",
"model": "NETGEAR WNDR3700v4",
"board_name": "wndr3700v4",
"release": {
"distribution": "OpenWrt",
"version": "19.07.5",
"revision": "r11257-5090152ae3",
"target": "ar71xx/nand",
"description": "OpenWrt 19.07.5 r11257-5090152ae3"
}
}
package network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option ifname 'eth0.10'
option force_link '1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option ip6addr '2001:db8:f00f:2::1/64'
option ip6gw '2001:db8:f00f:2::1'
config interface 'wan'
option ifname 'eth0.1'
option macaddr '00:00:5e:06:06:06'
option proto 'dhcp'
config interface 'wlan'
option proto 'static'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
option broadcast '192.168.3.255'
option ip6hint '3'
option ip6assign '64'
option dns '8.8.8.8'
option ip6addr '2001:db8:f00f:3::1/64'
option ip6gw '2001:db8:f00f:3::1'
config interface 'wlan2'
option proto 'static'
option ipaddr '192.168.4.1'
option netmask '255.255.255.0'
option broadcast '192.168.4.255'
option ip6hint '4'
option ip6assign '64'
option dns '8.8.8.8'
config interface 'sdmz'
option ifname 'eth0.12'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option broadcast '192.168.1.255'
option ip6assign '64'
option ip6hint '1'
option ip6addr '2001:db8:f00f:1::1/64'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
option enable_vlan4k '1'
config switch_vlan
option device 'switch0'
option vlan '10'
option ports '0t 1 2 3'
config switch_vlan
option device 'switch0'
option vlan '12'
option ports '0t 4'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 5'
config interface 'vpnc0'
option ifname 'tun0'
option proto 'none'
option auto '1'
option ipv6 '1'
option force_link '1'
option ip6prefix '2001:db8:f00f:100::/56'
option ip6addr '2001:db8:f00f::1000/64'
package wireless
config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ar934x_wmac'
option htmode 'HT20'
config wifi-iface
option device 'radio0'
option network 'wlan'
option mode 'ap'
option ssid 'SSID1'
option encryption 'psk2'
option key 'REDACTED'
config wifi-device 'radio1'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'pci0000:00/0000:00:00.0'
option htmode 'HT20'
config wifi-iface
option device 'radio1'
option network 'wlan2'
option mode 'ap'
option ssid 'SSID2'
option encryption 'psk2'
option key 'REDACTED'
package dhcp
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '0'
option rebind_localhost '1'
option local '/lan/'
option domain 'example.com'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option localservice '0'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option ra 'server'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
option start '30'
option limit '169'
option leasetime '12h'
config dhcp 'wlan'
option interface 'wlan'
option start '30'
option limit '464'
option leasetime '12h'
option ra 'server'
list dhcp_option '6,192.168.1.1'
config dhcp 'wlan2'
option interface 'wlan2'
option start '30'
option limit '464'
option leasetime '12h'
option ra 'server'
list dhcp_option '6,192.168.1.1'
config dhcp 'sdmz'
option interface 'sdmz'
option start '30'
option limit '464'
option leasetime '12h'
option ra 'server'
option dhcpv6 'server'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
config host
option mac '01:00:5e:ff:44:77'
option name 'test-system'
option ip '192.168.1.2'
package firewall
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'lan'
list network 'lan'
list network 'sdmz'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option log '1'
config zone
option name 'wlan'
list network 'wlan'
list network 'wlan2'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'ACCEPT'
option mtu_fix '1'
option conntrack '1'
config forwarding
option src 'lan'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'lan'
config forwarding
option src 'wlan'
option dest 'wan'
config forwarding
option src 'wan'
option dest 'wlan'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
config rule
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config rule
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '555'
option name 'CN-SSH'
config rule
option name 'Allow-WAN-DNS-UDP'
option src 'wan'
option proto 'udp'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Allow-WAN-DNS-TCP'
option src 'wan'
option proto 'tcp'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Allow-WLAN-DNS-UDP'
option src 'wlan'
option proto 'udp'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Allow-WLAN-DNS-TCP'
option src 'wlan'
option proto 'tcp'
option dest_port '53'
option target 'ACCEPT'
config rule
option name 'Allow-WAN-DHCP-Request'
option src 'wan'
option src_port '67-68'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Allow-WLAN-DHCP-Request'
option src 'wlan'
option src_port '67-68'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Allow-WAN-DHCP-Response'
option dest 'wan'
option src_port '67-68'
option dest_port '67-68'
option proto 'udp'
option target 'ACCEPT'
config zone 'vpnc'
option name 'vpnc'
option network 'vpnc0'
option device 'tun0'
option input 'ACCEPT'
option forward 'ACCEPT'
option output 'ACCEPT'
option masq '0'
config forwarding 'vpnc_forwarding_lan_out'
option src 'lan'
option dest 'vpnc'
config forwarding 'lan_forwarding_vpnc_out'
option src 'vpnc'
option dest 'lan'
config forwarding 'vpnc_forwarding_wlan_out'
option src 'wlan'
option dest 'vpnc'
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::b0db:6aff:fe22:c61d/64 scope link
valid_lft forever preferred_lft forever
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:f00f:2::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::120d:7fff:fe4d:56f6/64 scope link
valid_lft forever preferred_lft forever
7: br-sdmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:f00f:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b0db:6aff:fe22:c61d/64 scope link
valid_lft forever preferred_lft forever
9: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::120d:7fff:fe07:707/64 scope link
valid_lft forever preferred_lft forever
10: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:db8:f00f:3::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::120d:7fff:fe4d:56f6/64 scope link
valid_lft forever preferred_lft forever
11: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::120d:7fff:fe4d:56f8/64 scope link
valid_lft forever preferred_lft forever
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 100
inet6 2001:db8:f00f::1000/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::2684:a677:5dd5:7e01/64 scope link
valid_lft forever preferred_lft forever
2001:db8:f00f::/64 dev tun0 metric 256
2001:db8:f00f:1::/64 dev br-sdmz metric 256
2001:db8:f00f:2::/64 dev br-lan metric 256
2001:db8:f00f:3::/64 dev wlan0 metric 256
2000::/3 dev tun0 metric 1
fe80::/64 dev eth0 metric 256
fe80::/64 dev br-sdmz metric 256
fe80::/64 dev eth0.1 metric 256
fe80::/64 dev br-lan metric 256
fe80::/64 dev wlan0 metric 256
fe80::/64 dev wlan1 metric 256
fe80::/64 dev tun0 metric 256
local ::1 dev lo table local metric 0
anycast 2001:db8:f00f:: dev tun0 table local metric 0
local 2001:db8:f00f::1000 dev tun0 table local metric 0
anycast 2001:db8:f00f:1:: dev br-sdmz table local metric 0
local 2001:db8:f00f:1::1 dev br-sdmz table local metric 0
anycast 2001:db8:f00f:2:: dev br-lan table local metric 0
local 2001:db8:f00f:2::1 dev br-lan table local metric 0
anycast 2001:db8:f00f:3:: dev wlan0 table local metric 0
local 2001:db8:f00f:3::1 dev wlan0 table local metric 0
anycast fe80:: dev br-sdmz table local metric 0
anycast fe80:: dev eth0 table local metric 0
anycast fe80:: dev br-lan table local metric 0
anycast fe80:: dev eth0.1 table local metric 0
anycast fe80:: dev wlan0 table local metric 0
anycast fe80:: dev wlan1 table local metric 0
anycast fe80:: dev tun0 table local metric 0
local fe80::120d:7fff:fe07:707 dev eth0.1 table local metric 0
local fe80::120d:7fff:fe4d:56f6 dev br-lan table local metric 0
local fe80::120d:7fff:fe4d:56f6 dev wlan0 table local metric 0
local fe80::120d:7fff:fe4d:56f8 dev wlan1 table local metric 0
local fe80::2684:a677:5dd5:7e01 dev tun0 table local metric 0
local fe80::b0db:6aff:fe22:c61d dev br-sdmz table local metric 0
local fe80::b0db:6aff:fe22:c61d dev eth0 table local metric 0
ff00::/8 dev eth0 table local metric 256
ff00::/8 dev br-lan table local metric 256
ff00::/8 dev br-sdmz table local metric 256
ff00::/8 dev eth0.1 table local metric 256
ff00::/8 dev wlan0 table local metric 256
ff00::/8 dev wlan1 table local metric 256
ff00::/8 dev tun0 table local metric 256
0: from all lookup local
32766: from all lookup main
4200000001: from all iif lo lookup unspec 12
4200000005: from all iif br-lan lookup unspec 12
4200000007: from all iif br-sdmz lookup unspec 12
4200000009: from all iif eth0.1 lookup unspec 12
4200000010: from all iif wlan0 lookup unspec 12
4200000011: from all iif wlan1 lookup unspec 12
4200000012: from all iif tun0 lookup unspec 12
Did you keep the configuration during upgrading or started from a clean installation and configured it manually? The first is not advised as major releases have configuration differences, let alone going from 15.xx to 19.xx
Remove that from lan.
remove these from wlan. The dns should be configured under wan interface, where it is reachable from. Remove it also from wlan2.
In sdmz keep the ip6address or the ip6assign and ip6hint.
I believe this is the prefix in question, under vpnc0. What you have configured here is that the other end of the vpn tunnel has allocated you this /56. So this is not routed over to the other side of the vpn, but the peer is supposed to route towards your end. Other than that you can have ip6assign and ip6hint to allocate a prefix from this /56 to an interface, or assign an ip6address to do it manually.
Thank you. I have removed the ipgw and dns directives. I usually upgrade with the config in place and then fix whatever is broken later. Only once have I had to flash a stock config and manually add in the pieces. But you're right, reading up on deprecation would probably smoothe the process.
The ip6prefix should be correct as it is allocated by the other end of the VPN and up until the upgrade from Chaos Calmer was correctly apportioned out to the interfaces on this router. That's the core of the issue. From what I can tell, there isn't any directive to tell openwrt to use that prefix downstream, because it only seems to want to know about non-openvpn, non-tun interfaces when it's making its configuration decisions.
The thing I am trying to figure out is if there is a way to force it to do the right thing in the configuration files, or if not, if there is a way to kludge something into place to manually do the things it would have done for RA/SLAAC/DHCPv6 so that I can have connectivity downstream.
First do a ifstatus vpnc0.
Then a few remarks: 2001:db8:f00f:100::/56 is 2001:0DB8:F00F:0100:0000:0000:0000:0000 - 2001:0DB8:F00F:01FF:FFFF:FFFF:FFFF:FFFF
The sdmz address you have is out of this range. But as I told you, you should use either the ip6addr or the ip6assign and ip6hint.
wlan and lan the same, addresses you have assigned statically are out of the range you were assigned. A correct address would be 2001:db8:f00f:0102::1/64
Yeah I guess I over-anonymized in redacting the network names. The addresses I am using are within the /56. Again, this is a configuration that worked before. I am not attempting something new or in violation of RFCs (to my knowledge, at least.)
I would use the ip6assign and ip6hint, but unfortunately they are not honored because of precisely the issue I am reporting here. I added the ip6addr lines to try to force the interface to get the correct address in the hopes of making it work. I had tried some interfaces with just the ip6addr in the hopes of making that work, but no luck.
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 25527,
"l3_device": "tun0",
"proto": "none",
"device": "tun0",
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
}
}
As mentioned before, OpenWRT does not honor the tun0 interface as part of its magical internal configuration gymnastics for ipv6. The result is that the ipv6 configuration directives do nothing to make ipv6 configure itself as documented.
What I am trying to find is whether there is another way to force it to pick up the requested configuration, which worked in previous versions, or if not, if there is a way to run a script or something on boot to accomplish those same things differently.
It would be easier to paste it in a notepad and find/replace some characters.
That is not what I see in mine. I added ipv6 and a prefix in one tunnel of mine.
root@magiatiko / > uci show network.vps
network.vps=interface
network.vps.ifname='tun0'
network.vps.proto='static'
network.vps.ipaddr='10.0.20.2'
network.vps.netmask='255.255.255.252'
network.vps.dns='10.0.20.1'
network.vps.ip6prefix='fdaa:dddd::/56'
network.vps.ip6addr='fdaa:aaaa::1/64'
and immediately worked:
root@magiatiko / > ifstatus vps
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 123,
"l3_device": "tun0",
"proto": "static",
"device": "tun0",
"updated": [
"addresses",
"prefixes"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
{
"address": "10.0.20.2",
"mask": 30
}
],
"ipv6-address": [
{
"address": "fdaa:aaaa::1",
"mask": 64
}
],
"ipv6-prefix": [
{
"address": "fdaa:dddd::",
"mask": 56,
"class": "vps",
"assigned": {
"lan": {
"address": "fdaa:dddd::",
"mask": 60
},
"iot": {
"address": "fdaa:dddd:0:30::",
"mask": 64
}
}
}
],
...
What I suspect is the
Try to switch it to static or dhcp.
Switching to static and omitting the ip6addr gets me a link, but the ip6hints are still ignored, which means I still have no RA.
The network numbers assigned are in order from 1 to x starting with LAN no matter what I do. I have double, triple, and quadruple-checked the output of sipcalc for the /56 I am allocating, and have no idea why netifd is unable to select the prefixes requested.
I have also checked the routing table on the VPN server. I have pinged the network from external systems and can see the packets entering into the router. But openwrt's allocation nazi refuses to let me pick the networks with ip6hint. No explanation. Nothing. Just a sequential handout of numbers within a /61, without even letting me allocate which goes to which interface even if I select a /61 that contains only the networks I want.
At this point I have wasted nearly two days trying to untangle openwrt's voodoo internals; It would have been quicker to manually renumber the dozen or so systems on the site, but in principle I shouldn't have to do that.
Any idea how to debug netifd's decisionmaking process when deciding whether a given network number is possible or not to allocate?
Post once again the configs and the ifstatus vpnc0.
It's not substantially different from what I already posted. Is there really no way to see what it is doing when it is bringing an interface up? Or to force it to do quickly what it does after 25 minutes or so of uptime when devices start working?
Did you remove the ip6addr from all interfaces and left the ip6assign and ip6hint?
Thank you again for your determination in helping me get to the bottom of this.
Yes I did remove the ip6addr from all interfaces and left the ip6assign and ip6hint. For an hour or two of rebooting and waiting at least. Then I added the ip6addr back to the sdmz interface so that whatever mysterious process that happens 25 minutes after setting a default route could happen.
I still can't figure out why it won't honor the ip6hints. I tried both hex values and decimal values but it didn't make any difference. They're definitely in the /56 (within the range of 0100 to 01ff in this case) but netifd, in its capriciousness, tells me the following for each interface:
daemon.warn netifd: Failed to assign requested subprefix of size 64 for lan, trying other
But even if I assign 102 for lan and 101 for sdmz, for instance, it still insists on giving lan 101 and sdmz 102. That's why I was curious if there was a way to get some debugging info from netifd in that part of the process, so I could see what assumptions it is working with.
I don't think it is a problem of not honouring the ip6hint.
I am delegated a /56 prefix from my provider and it is working fine:
root@magiatiko / > ifstatus wan6
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": false,
"uptime": 227896,
"l3_device": "pppoe-wan",
"proto": "dhcpv6",
"device": "pppoe-wan",
"metric": 20,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
{
"address": "2222:3333:1111:75d3:4415:b44e:6dea:2350",
"mask": 64,
"preferred": 604698,
"valid": 2591898
}
],
"ipv6-prefix": [
{
"address": "2222:3333:4444:7500::",
"mask": 56,
"preferred": 448,
"valid": 538,
"class": "wan6",
"assigned": {
"lan": {
"address": "2222:3333:4444:7500::",
"mask": 60
},
"guest": {
"address": "2222:3333:4444:7517::",
"mask": 64
},
"iot": {
"address": "2222:3333:4444:7530::",
"mask": 64
}
}
}
],
root@magiatiko / > uci show network.lan
network.lan=interface
network.lan.proto='static'
network.lan.netmask='255.255.255.0'
network.lan.ipaddr='10.0.2.1'
network.lan.force_link='0'
network.lan.ip6ifaceid='::1'
network.lan.ifname='eth0.4'
network.lan.dns='10.0.2.3' '10.0.2.2'
network.lan.ip6assign='60'
root@magiatiko / > uci show network.guest
network.guest=interface
network.guest.proto='static'
network.guest.netmask='255.255.255.0'
network.guest.ipaddr='172.17.17.1'
network.guest.ip6ifaceid='random'
network.guest.force_link='0'
network.guest.ip6assign='64'
network.guest.ip6hint='17'
network.guest.ip6class='wan6'
network.guest.ifname='eth0.2'
root@magiatiko / > uci show network.iot
network.iot=interface
network.iot.proto='static'
network.iot.netmask='255.255.255.0'
network.iot.ipaddr='172.30.30.1'
network.iot.ifname='eth0.3'
network.iot.force_link='0'
network.iot.ip6ifaceid='eui64'
network.iot.ip6assign='64'
network.iot.ip6hint='30'
You cannot give 3 hex chars for hint, you have only 2 hex chars available
That solved the allocation issue! The funny thing is I vaguely remember encountering that problem before on a 18.06 box awhile back.
The behavior of the machines losing ipv6 connectivity until around 30 minutes after a reboot is still there. Some close examination shows it to be connected with the RA lifetime. If I set ra_lifetime to 301, there is only five minutes of outage.
I see RA messages going out, but none of the systems are willing to accept them until the end of the thirty minute waiting period. Looking at the routing tables, I can confirm the systems all stay stuck on the previous reboot's fe80:: address before adopting the new one thirty minutes later.
I suppose I could drop the ra_lifetime and resend values all down to ridiculously low values less than 30 in order to reduce the perceived downtime, but it seems like there should be a way to make it send RA messages the clients will accept.
I don't see why the LL address is changing after every reboot. It is derived from the mac of the interface.
Yeah me neither. I couldn't figure out why it didn't seem to correspond to any of the configured interfaces, when it occurred to me that I hadn't set a MAC for the SDMZ bridge. Once I set that, it works every time. Thanks!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.