Hi,

On Sat, May 03, 2014 at 04:44:49PM +0200, Steven Barth wrote:
> >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.

Mmmh.  "Something is funny in that box" - the address from RA and the
default route appeared as soon as the DHCPv6-PD issue was resolved.

[..]
> >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?

This is a 6500 with 12.2(33)SXI3 - which can't do IA_NA at all.  More
recent versions (12.4T something) can do IA_NA for static assignments,
but as far as I could find, no IOS can do IA_NA from pools, the "traditional"
stateful DHCP thing.

I will add a box with some 12.4T release in the mix tomorrow, upstreaming
the second router.  We'll see what happens there...

> > # ifup lan_6
> > [ not showing any activity ]
> >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.

OK, understood.  So the "downstream" activity (assigning a LAN prefix,
HNCP neighbours, ...) will be in the syslog, or "ip -6 addr".

[..]
> >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?

Summarizing the discussion we had in parallel on IRC: this might have been
an artefact of me not renaming the "lan" and "wan" interfaces, so possibly
other bits of OpenWRT fiddled in parallel to hnetd.  One indication is that
the route has a lifetime, which hnetd never sets, so it came "from elsewhere".

I've now changed lan/wan interface names & config to:

config interface 'hlan'
        option ifname 'eth1'
        option proto 'hnet'

config interface 'hwan'               
        option ifname 'eth0'          
        option proto 'hnet'  

and everything that refers to interface/proto is gone (so no more "wan6"
either) and rebooted - and now the result is "what I would naively expect":

root@GreenISPRouter:~# ip -6 addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:608:0:62:12fe:edff:fee6:5f33/64 scope global dynamic 
       valid_lft 2591987sec preferred_lft 604787sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:608:5:5b:12fe:edff:fee6:5f32/64 scope global dynamic 
       valid_lft 3462sec preferred_lft 1662sec

root@GreenISPRouter:~# 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 eth0  proto static  metric 256 
2001:608:5:b1::/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


... though there still is weirdness in my box, just for the record :-)

- "ifdown hlan" makes hnetd go crazy (logging 50+ messages/second, not
  recovering until you do "network restart")

- "/etc/init.d/network restart" restarts, but after that, some of the 
  routes are gone - in one case, 2001:608:0:62::/64, in the other case,
  the 2001:608:5:b1::/64 one.  This (again, FTR) is due to hnetd not
  noticing that "network restart" has removed the routes, so if you do
  that, you need to also do "hnetd restart".  (Noted :)).


Anyway, thanks for helping me gettings this off the ground.  More questions
(and answers for the archive) to come :-)

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

Attachment: pgpExLCWy38iC.pgp
Description: PGP signature

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to