Hi Gert,
well thanks for testing.
answers are inline.
Hi,
thanks for your help so far. (Side question: if people feel this is getting
off-topic for openwrt-devel, I'll take it offline. For now I keep the CC:
because I think other people might end up running into this, and google
might find the solutions, then :-) )
Should be fine.
What does "forceprefix 1" do?
Normal dhcpv6 handler also succeeds without PD for simple clinets.
If I do "proto dhcp" and no "forceprefix", the wan interface gets an
IPv6 address from the RAs received (plus default route).
Right now, I have neither an IPv6 default route nor an address, so it
very much looks like it's ignoring my RAs.
Strange as RA handling is done independently but OK.
[..]
- what's the recommended config on the upstream side to make it work?
Remove the "O"-Bit? (I have that because I cannot send RFC6106 info
from IOS, so RA+stateless DHCP is what we currently use to get IPv6
addresses + DNS addresses into the client devices)
I'll try to confirm / fix a bug tomorrow or on monday.
Thanks for testing against ISC DHCP (other mail). I'm not sure what
is different here - maybe ISC is returning the prefix right away, while
IOS just tells the router "go away"?
Might be IOS weirdness of this specific version. We have tested against
other Cisco devices which works fine. Which version is it?
I could offer you
a workaround at the moment which is: Open /lib/netifd/proto/hnet.sh and
search for json_add_string proto dhcpv6
Below that insert a line:
json_add_string reqaddress none
which should disable it asking for an IA_NA alltogether.
Done...
May 3 14:47:47: IPv6 DHCP: Received SOLICIT from FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Sending ADVERTISE to FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Received REQUEST from FE80::12FE:EDFF:FEE6:5F33 on
Vlan62
May 3 14:47:47: IPv6 DHCP: Option USER-CLASS(15) is not processed
May 3 14:47:47: IPv6 DHCP: Option RECONF-ACCEPT(20) is not processed
May 3 14:47:47: IPv6 DHCP: Option UNKNOWN(39) is not processed
May 3 14:47:47: IPv6 DHCP: Creating binding for FE80::12FE:EDFF:FEE6:5F33 in
pool NetmasterTEST
May 3 14:47:47: IPv6 DHCP: Allocating IA_PD 00000001 in binding for
FE80::12FE:EDFF:FEE6:5F33
May 3 14:47:47: IPv6 DHCP: Allocating prefix 2001:608:5::/56 in binding for
FE80::12FE:EDFF:FEE6:5F33, IAID 00000001
May 3 14:47:47: IPv6 DHCP: Sending REPLY to FE80::12FE:EDFF:FEE6:5F33 on Vlan62
... and things work :-) - I'm not posting the whole "ifstatus wan_6" now,
as it is 100+ lines long. The most important bits are these, though:
OK, hopefully there is an IPv6 default route in there somewhere.
Next question :-)
root@OpenWrt:~# ifstatus lan_6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"proto": "dhcpv6",
"device": "eth1",
"data": {
}
}
as per your definition, this is "not working", right?.
Not necessarily. The _6 interfaces are only showing information acquired
from DHCPv6-servers/RAs so this only matters if its an uplink. "ifstatus
lan" without _6 shows the data from homenet / hnetd such as IP address,
firewall zone.
OTOH, "ip -6 addr" confirms that it indeed selected a subnet from the
delegated prefix (2001:608:5::/56), assigned it to the lan=eth1 (only
a single LAN interface here)
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:608:5:b5:12fe:edff:fee6:5f32/64 scope global dynamic
valid_lft 3448sec preferred_lft 1648sec
inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic
valid_lft 2591971sec preferred_lft 604771sec
inet6 fe80::12fe:edff:fee6:5f32/64 scope link
valid_lft forever preferred_lft forever
$ ip -6 route
2001:608:5:b5::/64 dev eth1 proto static metric 1024
So it looks good to me.
Though... "ip -6 route" actually brings up the next "huh, what?" question:
root@OpenWrt:~# ip -6 route
default from :: via fe80::214:1cff:fed2:30c0 dev eth0 proto static metric 1024
default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0 proto
static metric 1024
default from 2001:608:5::/56 via fe80::214:1cff:fed2:30c0 dev eth0 proto
static metric 1024
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec
2001:608:5:b5::/64 dev eth1 proto static metric 1024
unreachable 2001:608:5::/56 dev lo proto static metric 1000000000 error -128
unreachable 2001:608:5::/56 dev lo proto static metric 2147483647 error -128
unreachable fd83:af19:9ef::/48 dev lo proto static metric 2147483647 error
-128
I understand the defaults (eth0=wan, source dependent, could be multiple
routers, but there is only one, so all the same), and the unreachables.
I do not understand this one:
2001:608:0:62::/64 dev eth1 proto kernel metric 256 expires 2591907sec
I wonder where that comes from. Could you check if its in ifstatus lan?
Don't know where this comes from though. Doesn't really make sense. Are
there spurious RAs on eth1 with that address?
this network is connected to the *WAN* side of things (eth0), and announced
by RA from the Cisco to the WRT. The address from that /64 is visible on
both eth0 + eth1, which I find a bit surprising but "otherwise harmless",
but the route shouldn't point to eth1 - my belly says "this would make
the box unable to reach other devices on the :0:62:: LAN".
Yeah wonder why it happens. Is it in ifstatus lan or iftstaus lan_6 or
do you ahve kernel RA handling enabled?
Incidentially, when I ping6 the GUA address of the router, it *does* work:
root@OpenWrt:~# ping6 2001:608:0:62::ffff
PING 2001:608:0:62::ffff (2001:608:0:62::ffff): 56 data bytes
64 bytes from 2001:608:0:62::ffff: seq=0 ttl=64 time=0.810 ms
64 bytes from 2001:608:0:62::ffff: seq=1 ttl=64 time=0.658 ms
"whut"?
Anyway. Short summary: with the change to hnet.sh, it seems to be working
and I get all the addresses and prefixes I expect to see. There is just
confusion in "what should the output of some commands look like".
OK I'll export this workaround as option in interface-config as well.
thanks,
gert
Cheers,
Steven
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
