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 :-) )
On Sat, May 03, 2014 at 07:59:03AM +0200, Steven Barth wrote:
> >Oh well. First thing is "I should have looked at 'ifstatus wan_6'" which
> >indeed tells me "WAN is working":
> >
> >root@OpenWrt:/etc/config# ifstatus wan_6
> >{
> > "up": false,
> > "pending": true,
> > "available": true,
> > "autostart": true,
> > "proto": "dhcpv6",
> > "device": "eth0",
> > "data": {
> >
> > }
> >}
> doesn't really look like working.
Well, it's not succeeding, but at least it's doing something :-) - while
"ifstatus wan" got me all confused, with all protocols set to "false".
> >Questions :-)
> >
> > - is hnetd intentionally ignoring the A-Bit in RA?
> hnetd doesn't reimplement the dhcpv6-client it uses OpenWrt's internal
> dhcpv6-protocol-handler.
> So it behaves the same as if you had an interface with proto=dhcpv6 and
> option forceprefix 1. If it works with that you should be good to go
> (unless there is a bug somewhere sigh)
What does "forceprefix 1" do?
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.
> And normally the dhcpv6 handler ignores O/M-bits and just asks for IA_NA
> + IA_PD first in a solicit and when that fails (server returns with
> NoAddrsAvail) tries with IA_PD-only which should succeed in your case
> (don't know why it didn't though).
Yeah, given the not-exactly-clear specification of O/M-Bits, this sounds
like a "fail-save" approach in the general case.
[..]
> > - 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"?
> 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:
"ipv6-address": [
{
"address": "2001:608:0:62:12fe:edff:fee6:5f33",
"mask": 64,
"preferred": 604752,
"valid": 2591952
}
],
"ipv6-prefix": [
{
"address": "2001:608:5::",
"mask": 56,
"preferred": 1751,
"valid": 3551,
"class": "wan_6",
"assigned": {
}
}
],
"good!".
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?.
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
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".
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".
thanks,
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpejeKsv4_9z.pgp
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
