Aftter assigning IA_PD, odhcp starts believing local interfaces lack public prefixes

[openwrt]

Aftter assigning IA_PD, odhcp starts believing local interfaces lack public prefixes

[toreanderson]

For what it's worth, this bug appearst to have been included in the 15.05.1 point release of OpenWrt Chaos Calmer.

[timcoote]

Is it likely that this bug will surface if I merely reset a downstream router, which then solicits and IA_PD. odhcpd then will not respond and logs:

Sun Aug  7 09:46:26 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_NA from 0003000108002742210c on br-lan: no addresses available 
Sun Aug  7 09:46:26 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_PD from 0003000108002742210c on br-lan: no prefix available 
Sun Aug  7 09:46:27 2016 daemon.warn odhcpd[971]: A default route is present but there is no public prefix on br-lan thus we don't announce a default route!
Sun Aug  7 09:46:27 2016 daemon.warn odhcpd[971]: DHCPV6 SOLICIT IA_PD from 0003000108002742210c on br-lan: no prefix available 

meanwhile on the same, upstream, router:

root@OpenWrt:~# ip -6 address show scope global dev br-lan
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
    inet6 2a02:c7d:1d31:a600::1/56 scope global noprefixroute dynamic 
       valid_lft 5494sec preferred_lft 1894sec

[toreanderson]

Your ip -6 address show output indicates that the address has been configured with a 56-bit prefix length. That's invalid and indicates there's another bug involved. I've never seen this one before. Did you manually configure your br-lan interface? Is it set up with option proto 'hnet' or something else?

[timcoote]

I thought that I'd taken and used the stock image (http://bit.ly/2aEyKqd), so that the ipv4 address was fixed. I did move that address. I also had to faff a bit to get the router to get the subnet delegation from Sky. It looks like I also added hnet control to the lan interface: and this could be the wrong thing to do. The relevant uci stanzas look like this:

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

config interface 'lan'
    option ifname 'eth1'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ipaddr '192.168.1.254'
    option ip6assign '56'

I do want a downstream router to get a subnet from this router. Should I have configured that differently?

[toreanderson]

I think your problem is option ip6assign '56'. I think that tells OpenWrt to assign a /56 directly onto eth1, which probably is the entire prefix you got delegated from your ISP. Thus it makes sense perfect sense for odhcpd to say that there's no prefix available, because you've assigned all of your 256 available /64s to eth1.

So I think you'll want to change that to say option ip6assign '64' instead.

Another thing that seems a little bit strange to me is to have both option proto 'static' and option proto 'hnet' on the same interface. hnetd will take care of assigning IPv4 addresses to links, there's no need to do it statically. It might be that doing both works without issue, but if I were you I'd try collapsing the two interface definitions into one, something à la:

config interface 'hnet-lan'
    option ifname 'eth1'
    option force_link '1'
    option type 'bridge'
    option proto 'hnet'
    option mode 'auto'
    option ip6assign '64'
    option ip4assign '24'

This would be more similar to what I have on my routers. I'm not using any bridges though, so no guarantees it works without modifications.

[dtaht]

This appears to be the same bug as #388. I can reproduce it easily now.

https://bugs.lede-project.org/index.php?do=details&task_id=388

In my case, I am allocating out of 61. 3 dhcp pd attempts, and boom

[OopsPwnedUAgain]

In my experience this problem happens if there's a lan interface which has dhcpv6 enabled but no ipv6 blocks assigned. Unfortunately this causes other lan interfaces to have their routes revoked.

I suppose one could say that having dhcpv6 enabled on an interface without a public address available is an incorrect configuration, but it can happen without users intentionally configuring.