Hardware: WDR-3600 using OpenWRT Barrier Breaker 14.07

I want to provide the last 64 bits of the IPv6 address to my host using DHCPv6 using odhcpd.
Have referred to: https://miceliux.com/apuntesderoot/2014/09/07/static-dhcpv6-leases-in-openwrt/

The "/etc/config/dhcp" file contains:

config host                      
    option name 'hostname'
    option mac '00:xx:xx:xx:98:03'
    option ip '10.159.93.40'      
    option duid '000100011b68071900xxxxxx9803'                                       
    option hostid 'b3e6c2dba12bdf02'

Note that the hostid is 8 octets long, i.e:

b3e6:c2db:a12b:df02

as it can be. However, this fails and odhcpd provides my host a random IPv6 address:

odhcpd[10534]: DHCPV6 SOLICIT IA_NA from 000100011b68071900xxxxxx9803 on br-lan: ok 2001:xxxx:e383:938::9e1/128 fd00:db80:0:938::9e1/128 
odhcpd[10534]: DHCPV6 REQUEST IA_NA from 000100011b68071900xxxxxx9803 on br-lan: ok 2001:xxxx:e383:938::9e1/128 fd00:db80:0:938::9e1/12

A similar case happens in the following case (9x4 = 36 bits longs):

  option hostid 'b3e6c2dbf'          

which should actually be interpreted as:
0000:000b:3e6c:2dbf
but is not!

However, the following works:

 option hostid 'b3e6c2db' 

and I get:

odhcpd[10153]: DHCPV6 SOLICIT IA_NA from 000100011b68071900xxxxxx9803 on br-lan: ok 2001:xxxx:e383:938::b3e6:c2db/128 fd00:db80:0:938::b3e6:c2db/128 
odhcpd[10153]: DHCPV6 SOLICIT IA_NA from 000100011b68071900xxxxxx9803 on br-lan: ok 2001:xxxx:e383:938::b3e6:c2db/128 fd00:db80:0:938::b3e6:c2db/128 
odhcpd[10153]: DHCPV6 REQUEST IA_NA from 000100011b68071900xxxxxx9803 on br-lan: ok 2001:xxxx:e383:938::b3e6:c2db/128 fd00:db80:0:938::b3e6:c2db/128

which is being interpreted correctly as:
0000:0000:3e6c:2dbf

I wonder how is this handled? I have a /48 from he.net and I am routing a /64 from that.

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
option ignore '1'

config dhcp 'wan'
option interface 'wan'
option ignore '1'

config odhcpd 'odhcpd'
option maindhcp '1'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'

According to documentation if there is ignore=1 on an interface odhcpd should ignore that interface.
But it doesn't happen. In the configuration like above IP addresses are issued to clients on lan interface.

Hi, i used to use ur software named "6relayd" before the openwrt(14.07), and i also can get the public ipv6 addr in downstream devices , and i am successful to go the web of ipv6. but today ,i cant use 6relayd because of http://wiki.openwrt.org/doc/uci/6relayd ,so i had compiled it in my router ,and start the odhcpd in os ,but i cant get a useful ipv6 addr on br-lan ,i am failed .Thus, i would like to know the more settings about odhcpd, i guess many people have the same problem, so please say more ,and i try it later. u can sent a email to me if its possible ,or, u can write it in the README of source ,i hope u can do some examples to help us solve it.
thank u very much!!!

by the way, my network environment is native ipv6 ,and use odhcp6c ,the router can get a public ipv6 addr, and my openwrt version is Chaos Calmer trunk

my email: [email protected]

im waiting for ur reply, thank u!

RFC3315 section 20:

The relay agent MAY be configured to use a list of destination
addresses, which MAY include unicast addresses, the All_DHCP_Servers
multicast address, or other addresses selected by the network
administrator.

I guess we have to make a change here: https://github.com/sbyx/odhcpd/blob/master/src/dhcpv6.c#L533

Hi again,

In proxy-ND mode, the host routes installed through the slave interfaces never disappear. Even stopping odhcpd has no effect.

Please add an example configuration how the relay and/or hybrid mode(s) are supposed to work.

As I understand it, relay mode should supply publicly routable IPv6 adresses, if a foreign DHCP on the WAN interface does not delegate an IPv6 prefix. Hybrid mode should be 'static' with a fallback to 'relay' when ??.

I tried to set this up, but everything I can find configuration-wise either doesn't work (or I'm doing something wrong) or is built around the deprecated 6relayd.
Running OpenWrt Barrier Breaker on a 1043ND v1 (if that matters somehow).

I have a router with 4 IPv6 links/providers and as such my LAN is seeing RAs from odhcpd with 4 prefixes, all with the autonomous flag set. I would like to be able to enable/disable that autonomous flag so that I can set the policy of which upstream links my LAN hosts should be using at the router.

Is this possible currently?

My router has set up a 6in4 isatap tunnel to get a public ipv6 address. The hosts behind the router can visit internet by nat in ip6tables with static ULA ipv6 address.

I have found that radvd can dynamic config ipv6 address and advertise gateway for hosts. But radvd has been deprecated, and instead by odhcpd. Although I found some tech references in odhcpd in openwrt.org, I can't understand how to config it.

Can you help me ?

I want to config it like this:

br-lan interface in router: fc00: a: b: c::1,
address pool: fc00: a: b: c::/64
gateway: fc00: a: b: c::1

Thank you!

I'm running odhcpd in relay mode, but pc in LAN fail to ping ipv6.google.com

Using tcpdump, I found that NA is sent without O flag, while other host(not behind a router)'s NA has O flag.

Would it be possible that the upstream router's cache is not updated due to the lack of O flag in NA? If so, is there a way to work it around?

I'm running the 2014-08-23-24452e1e3e9adfd9d8e183db1aa589f77727f5a7 version of odhcpd.

IPv6 on the router is working ok.

I have been trying to use static DHCPv6 assignment using odhcpd (git: 73a7133) and a 6in4 tunnel.

The goal is to have the client receive 2001:470:1f12:1103::2/64. On the WAN side, a 6in4 tunnel is created. From the router, I can ping6 ipv6.google.com.

On the LAN side however the client receive 2001:470:1f12:1103::2/128. This Wireshark capture shows that the DHCP server offers the expected IPv6 address but does not include any prefix information (like DHCPV6_OPT_IA_PREFIX) option in its answer which leads the client (Ubuntu 14.04) to interpret the address as "/128".

eth0      Link encap:Ethernet  HWaddr 54:a0:50:7a:fc:df  
          inet addr:192.168.77.2  Bcast:192.168.77.255  Mask:255.255.255.0
          inet6 addr: 2001:470:1f13:1103::2/128 Scope:Global
          inet6 addr: fe80::56a0:50ff:fe7a:fcdf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:723851 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:933141282 (933.1 MB)  TX bytes:43979869 (43.9 MB)

The network configuration file looks like this:

[...]

config interface 'lan'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ifname 'eth0.1'
    option ipaddr '192.168.77.1'
    option ip6gw '2001:470:1f13:1103::1'
    option ip6assign '64'
    option ip6hint '0'

[...]

config interface 'wan6'
    option _orig_ifname '@wan'
    option _orig_bridge 'false'
    option proto '6in4'
    option peeraddr '216.66.84.42'
    option ip6addr '2001:470:1f12:1103::2/64'
    option ip6prefix '2001:470:1f13:1103::/64'
    option ip6assign '64'
[...]
    option delegate '1'

And the DHCP configuration looks like this.

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'

config dhcp 'wan'
    option interface 'wan'
    option ignore '1'

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option dhcpv6 'server'
    option ra 'server'
    option ra_management '1'

config odhcpd 'odhcpd'
    option maindhcp '0'
    option leasefile '/tmp/hosts/odhcpd'
    option leasetrigger '/usr/sbin/odhcpd-update'

config host
    option name 'desktop'
    option mac '54:a0:50:7a:fc:df'
    option duid '0004eef4c651095f7f8f9139168091a4aa4c'
    option ip '192.168.77.2'
    option hostid '2'

The system seams to understand that the prefix from wan6 should be delegated to lan:

ifstatus wan6
{
    "up": true,
    "pending": false,
    "available": true,
    "autostart": true,
    "uptime": 171,
    "l3_device": "6in4-wan6",
    "proto": "6in4",
    "updated": [
        "addresses",
        "routes",
        "prefixes"
    ],
    "metric": 0,
    "delegation": true,
    "ipv4-address": [

    ],
    "ipv6-address": [
        {
            "address": "2001:470:1f12:1103::2",
            "mask": 64
        }
    ],
    "ipv6-prefix": [
        {
            "address": "2001:470:1f13:1103::",
            "mask": 64,
            "class": "wan6",
            "assigned": {
                "lan": {
                    "address": "2001:470:1f13:1103::",
                    "mask": 64
                }
            }
        }
    ],
    "ipv6-prefix-assignment": [

    ],
    "route": [
        {
            "target": "::",
            "mask": 0,
            "nexthop": "::",
            "source": "2001:470:1f12:1103::2\/64"
        },
        {
            "target": "::",
            "mask": 0,
            "nexthop": "::",
            "source": "2001:470:1f13:1103::\/64"
        },
        {
            "target": "::",
            "mask": 0,
            "nexthop": "::",
            "source": "::\/128"
        }
    ],
    "dns-server": [

    ],
    "dns-search": [

    ],
    "inactive": {
        "ipv4-address": [

        ],
        "ipv6-address": [

        ],
        "route": [

        ],
        "dns-server": [

        ],
        "dns-search": [

        ]
    },
    "data": {

    }
}

And the LAN interface seam to receive the prefix assignment properly (both address and mask):

 ifstatus lan
{
    "up": true,
    "pending": false,
    "available": true,
    "autostart": true,
    "uptime": 38,
    "l3_device": "br-lan",
    "proto": "static",
    "device": "br-lan",
    "updated": [
        "addresses"
    ],
    "metric": 0,
    "delegation": true,
    "ipv4-address": [
        {
            "address": "192.168.77.1",
            "mask": 24
        }
    ],
    "ipv6-address": [

    ],
    "ipv6-prefix": [

    ],
    "ipv6-prefix-assignment": [
        {
            "address": "2001:470:1f13:1103::",
            "mask": 64
        }
    ],
    "route": [

    ],
    "dns-server": [

    ],
    "dns-search": [

    ],
    "inactive": {
        "ipv4-address": [

        ],
        "ipv6-address": [

        ],
        "route": [

        ],
        "dns-server": [

        ],
        "dns-search": [

        ]
    },
    "data": {

    }
}

Running odhcpd manually over SSH gives the following:

root@OpenWrt:/tmp# ./odhcpd
odhcpd[13117]: DHCPV6 CONFIRM IA_NA from 0004eef4c651095f7f8f9139168091a4aa4c on br-lan: not on-link 2001:470:1f13:1103::2/128 
odhcpd[13117]: DHCPV6 SOLICIT IA_NA from 0004eef4c651095f7f8f9139168091a4aa4c on br-lan: ok 2001:470:1f13:1103::2/128 
odhcpd[13117]: DHCPV6 REQUEST IA_NA from 0004eef4c651095f7f8f9139168091a4aa4c on br-lan: ok 2001:470:1f13:1103::2/128 

I have not been able to figure out how the prefix is propagated in "dhcpv6-ia.c". Is the device improperly configured or is this case untested?

I have deleted all previous submissions to make it crystal clear with a wireshark packet capture in clear text of an RA.
No. Time Source Destination Protocol Length Info
980 60.676184 router link local client link local ICMPv6 262 Router Advertisement from router mac

Frame 980: 262 bytes on wire (2096 bits), 262 bytes captured (2096 bits) on interface 0
Ethernet II, Src: (mac), Dst: (client mac)
Internet Protocol Version 6, Src: link local router, Dst: link local client
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xec03 [correct]
Cur hop limit: 64
Flags: 0xc8
1... .... = Managed address configuration: Set
.1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
...0 1... = Prf (Default Router Preference): High (1)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : mac)
ICMPv6 Option (MTU : 1480)
ICMPv6 Option (Prefix information : 2001:XXXX:eb3e::/64)
ICMPv6 Option (Prefix information : 2001:XXXX:b2d1::/64)
ICMPv6 Option (Route Information : High 2001:XXXX:eb3e::/48)
ICMPv6 Option (Route Information : High 2001:XXXX:b2d1::/48)
ICMPv6 Option (Recursive DNS Server 2001:XXXX:eb3e::10)
ICMPv6 Option (DNS Search List Option dom.tld)
ICMPv6 Option (Advertisement Interval : 1800000)
So wheres the problem? Due to the single link local address assignment by openwrt by default a single RA compresses all potential addresses assignments to a single default gateway. While this seems right in theory as a single device should equal a single gateway, without NAT to process traffic in a traditional sense it leaves (public IP) source address selection up to the OS as both public prefixes share the same gateway. I'd suggest the following. Create additional link local addresses (lan side) for each public prefix (continues to allow for simple prefix changes, utilizing some sort of +1 mech for the link local so that each wan can be tracked and if one changes it can be decommissioned easily) and submit RA's for each prefix using the configured metric values on the ipv6 wan interfaces to determine high medium or low default router (not route) preference bits. From what I've seen this will take quite a significant overhaul of the way this program works, but I am going to start picking at it as it would better reflect needs of any multi wan user.

PS- also having individual ra's would allow mtu's to be calculated properly for different wan types, such as the 1480 for he.net tunnels or 1492 for dsl pppoe links, etc etc

When the router has both a private (ULA) and a public prefix, setting ra_management = 1 results in only the private prefix being given with DHCPv6.

I've set up a test network which reliably demonstrates this with the following prefixes:

• ULA prefix: fd18:b74d:c58e::
• WAN prefix: fd14:4ffd:f08f:4::

I've uploaded the configuration:

• /etc/config/dhcp
• /etc/config/network
• ifstatus wan6

With ra_management = 2, the test computer receives the following IPs: (capture)

inet6 fd14:4ffd:f08f:4::be8/64 scope global tentative 
inet6 fd18:b74d:c58e::be8/64 scope global tentative

With ra_management = 1, the test computer has the following IPs: (capture)

inet6 fd18:b74d:c58e::be8/64 scope global 
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 
inet6 fd18:b74d:c58e:0:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 

The expected result is that ra_management = 1 results in:

inet6 fd18:b74d:c58e::be8/64 scope global
inet6 fd14:4ffd:f08f:4::be8/64 scope global
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic 
inet6 fd18:b74d:c58e:0:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic

Removing the ULA from the config does result in the public prefix being given:

inet6 fd14:4ffd:f08f:4::be8/64 scope global 
inet6 fd14:4ffd:f08f:4:a00:27ff:fe0c:6862/64 scope global mngtmpaddr dynamic

My 14.07 OpenWRT router is not my DNS server but rather another machine in my network is. But I cannot seem to get odhcpd to announce that other server (or announce nothing). It keeps announcing itself as the DNS server. I have tried any number of "dns" options in:

config odhcpd 'odhcpd'

but I cannot get it to change behaviour. I have tried:
option dns ''

option dns 'fd31:aeb1:48df:0:21f:c6ff:fec4:926a'

list dns 'fd31:aeb1:48df:0:21f:c6ff:fec4:926a'

But I still keep getting the OpenWRT router in the RA.

Any ideas?

Per default OpenWrt networking and system configurations, odhcpd cannot relay NDP "out of the box" in SLAAC or DHCPv6 (not -PD) configurations. Because the target address in NS (say 2001::abcd) is unreachable according to the routing table (actuallly there is no entries for any addresses other than link-local ones for the slave interface), the ping6 (ndp.c:210) fails with EACCES.
NDP works after I manually added the route to 2001::/64 (on-link) via slave interfaces.

Happy to have native IPv6 again, now that proxy-ND works.

The one issue I've noticed is that now I have an inconsistent DNS configuration. DHCPv4 points at the OpenWRT box:

$ cat /var/run/resolvconf/interface/wlan0.dhcp 
nameserver 192.168.2.1

while RAs point at the ISP's name servers:

$ cat /var/run/resolvconf/interface/wlan0.ra 
nameserver 2a01:e00::2
nameserver 2a01:e00::1

This, of course, causes the .lan domain to behave erratically.

I think the solution would be to act a little more as an RA client and server, i.e. to run distinct instances of the RA protocol on the master and slave sides. I'm not sure if doing that would cause any issues.

odhcpd on an OpenWrt image with IPv6 removed gives the following errors:

Fri Jan  2 00:40:23 2015 daemon.err odhcpd[1054]: Failed to open routing table: No such file or directory
Fri Jan  2 00:40:23 2015 daemon.err odhcpd[1054]: Unable to open raw socket: Address family not supported by protocol

Is this expected? Seems like the code assumes IPv6 support is always present.

(I'm also losing connectivity, but I'm not sure if that's odhcp related.)

Hi,
This should be notice instead of warning I think .
https://github.com/sbyx/odhcpd/blob/master/src/dhcpv6-ia.c#L927

The commit sbyx@5b12eeb changed the behavior to default to advertising link-local addresses. I'm not sure telling clients to use a link-local DNS resolver is more robust / better / etc. than giving them a wider scoped address. What was the rationale for the change originally? At least an config option would be ideal -- tell me if that's reasonable and I'll write the patch. Right now I'm hard-coding in the ULA address of the bridge interface and it's a little awkward...

Hi, there.

Currently odhpcd supports relay mode for ndp, offering the feature for proxying NS packets from external interface of the router to the internal interface, making outside ipv6 packets possible to be routed to internal hosts which has a global ipv6 address.

This works like a charm when a whole subnet has been delegated to the router by ISP router, but the ISP router did not have routing rules to route to subnet hosts, like this:

In this case, packets from PC A or from the internet could be routed, hopping on ISP router, then by proxyed NS and NA packets, being transmitted (not actually routed, right?) to router, and then to PC B and PC C. On the other hand, hopping on router, packets from internal subnet (PC B and PC C) could also be routed to PC A or to the internet.

However, my network use case is quite different from this scene, and thus reqires more features on odhcpd. Our school network does not even delegate 64-bit prefixes to our hosts, it delegates addresses using SLAAC in the 64-bit prefixed subnet. The network structure works like this:

So running a router to extend my local link actually forms a network in such a way that one same 64-bit prefixed subnet owns 2 separated links, my internal one that connects my devices with my router ,and the external one that connects my router with the school router. I do not have any control over the school router, so I can't change this.

Running odhcpd in relay mode does help a lot in this case, Let me analyze the situation

• My internal link hosts could send packets to each other and to my router without any problem. (Of course)
  • AAAA::4, AAAA::5, AAAA:::3 could ping each other
• My router could send packets to external link hosts through external interface without any problem (Of course)
  • AAAA::3, AAAA::2, AAAA::1 could ping each other
• My internal link hosts takes my router as default routing target, and my router takes school router as default, so packets from interal link (PC B and C) to internet targets (eg. ipv6.google.com, targets outside the AAAA::/64 subnet) could be routed right.
• NS packets from external link would be proxyed to the internal link by odhcpd, so packets routed from the internet through school router and packets from other external link hosts (PC A) could be successfully sent to my router and then routed to the correct target host.
  • AAAA::4 and ipv6.google.com could ping each other
• But NS packets from internal link would not be proxyed to the external link, and default routing rules promoted to internal link hosts do not have a router for AAAA::/64 subnet, so packets from interal link hosts (PC B and C) to external link hosts (PC A) could not be tranmitted right.
  • ping from AAAA::4 to AAAA::2 yeild destination unreachable (icmp-echo-request packets could not be sent)
  • ping from ``AAAA::2toAAAA::4` could not receive response (`icmp-echo-request` packets are sent and received, but `icmp-echo-reply` could not be sent back)

So in this use case, the most elegant way working out of this would be providing odhcpd the feature to proxy ndp packets from interal interface back to external interface, that's why I'm here firing a feature request, would you consider about it?

Cheers,
Chaserhkj

Attachment:

my odhcpd configuration

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option ndp 'relay'
        option ra 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ndp 'relay'
        option ra 'relay'
        option master '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'

It is somewhat unexpected that with

option dhcpv6 'disabled'
option ra 'server'

odhcpd still sends the “Managed” flag. It took me quite some time to figure out what was going on. It seems to be better to have the default value for option ra_management derived from option dhcpv6, i.e. if and only if DHCPv6 is enabled, ra_management should be 1 by default.

I have a cherry-picked IPv6 address from my sixxs subnet that I want to delegate to a client. For that to work I simply added a host configuration with hostid and duid to /etc/config/dhcp.

Now after a reboot of the router I get the ULA with the hostid but not the global IP. I need to disconnect the client (either with ifconfig down or by pulling out the LAN cable) an reconnect before odhcpd assigns the IP to the client.

More information: https://forum.openwrt.org/viewtopic.php?id=63635

My general IPv6 configuration

WAN bridge:

• WAN interface (PPPoe, IPv4 only)

          inet addr:83.191.117.55  P-t-P:62.218.4.126  Mask:255.255.255.255

• WAN6 interface (6to4)
  6to4 working correctly, IPv6 addresses assigned:

          inet6 addr: ::83.191.117.55/128 Scope:Compat
          inet6 addr: 2002:53bf:7537::1/16 Scope:Global

LAN bridge:

• LAN interface
• WiFi interface
• IPv6 assignment length: 64 from public 6to4 address seems to work correctly:

          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: 2002:53bf:7537::1/64 Scope:Global
          inet6 addr: fe80::c03f:eff:fe7c:186a/64 Scope:Link

Other details:

• OpenWrt Barrier Breaker 14.07 / LuCI Trunk (0.12+svn-r10530)
• Second PC connected via Ethernet for testing
• Additional WiFi interface GUEST (no IPv6)

My problem:

When I set "IPv6 Settings / Router Advertisement Service" to "server mode" in LuCI,
it causes this odhcpd setup (/etc/dhcp):

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option ra 'server'

which seems to be OK. However, as soon as it's up, it sends

1. a correct Router Advertisement (advertising the prefix 2002:53bf:7537::)
2. a correct Neighbor Solicitation for target 2002:53bf:7537:0:1e6f:65ff:fe86:102b
3. an invalid Neighbour Solicitiation for target 2002:53bf:752d::eb6
   Note the prefix 2002:53bf:75_2d_ which is different from the correct 2002:53bf:75_37_ (last two digits).

This causes the other PC to add both those IPv6 addresses:

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.11  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2002:53bf:7537:0:1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x0<global>
        inet6 2002:53bf:752d::eb6  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x20<link>

And of course, 2002:53bf:752d::eb6 won't work (100% packet loss). When I remove
2002:53bf:752d::eb6 manually, it works:

$ sudo ifconfig enp2s0 del 2002:53bf:752d::eb6
$ ping6 -v www.google.com
PING www.google.com(fra07s31-in-x12.1e100.net) 56 data bytes
64 bytes from fra07s31-in-x12.1e100.net: icmp_seq=1 ttl=58 time=65.8 ms
64 bytes from fra07s31-in-x12.1e100.net: icmp_seq=2 ttl=58 time=63.8 ms

I can't find the invalid address 2002:53bf:752d::eb6 or its invalid prefix
2002:53bf:752d ANYWHERE on the router (not in interface info and not in the
routes) so I guess this prefix may be calculated and advertised incorrectly
by ohdcpd.

Workaround

Disable odhcpd completely and use radvd. Only the correct IPv6 address
(2002:53bf:7537:0:1e6f:65ff:fe86:102b) is sent via Neighbor Solicitation and will be used
by the other PC.

I think it's an odhcpd-related issue because it works fine with radvd.

I get my v6 prefix via dhcp from my upstream provider (comcast.) I've noticed that after 2 or 3 days, odhcpd stops handing out the upstream prefix and doing router advertisements for it, resulting in the other network clients being unable to route to the internet. Restarting odhcpd remedies the problem.

I'm not sure the cause, I'm not even sure how to start tracking down the cause. I'd love to provide more info if there any suggestions for things to look at?

This behaviors has happened since I upgraded OpenWRT to 15.05, but I'm hand maintaining odhcpd. I'm currently running off commit aa3a136

I use openwrt to deliver IPv6 addresses to my network. As i understand Android devices donot use DHCPv6, only SLAAC. But i donot want to give all my Android devices a IPv6 connectivity. So i need to exclude some devices from SLAAC. What options do we have ore need to implement?

Shouldn't ra_management default to 0 when the prefix length is 64, and 2 otherwise?

The relay mode does not work on my OpenWRT router. Devices on LAN can get inet6 addr but are unable to ping any public ipv6 address. By Googling odhcpcd and ipv6 relay, I find many similar problems but no one of them are solved. Therefore I think they are due to the bug of odhcpd rather than the configuration problem.

I think issue 15 and 25 are about the same problem but it is closed without actually solving it. I am glad to provide packet capture and other debug information if the developer is still interesting in solving this problem.

I want to use odhcpd for SLAAC on an internal interface. If I change the prefix on this interface I expect odhcpd to invalidate the outdated prefix (lifetime=0) and to start announcing the new one. Am I right that invalidation of prefixes is missing? What would be the best way to implement it?

Trying to debug my proxy-NDP problems (see #15), it looks like odhcpd is failing to populate the neighbour cache:

setsockopt(11, SOL_SOCKET, SO_BINDTODEVICE, "wlan1\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
sendmsg(11, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "2a01:e34:ec22:84a0:7973:8fc4:ac31:994d", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\0\0\0\0", 8}], msg_controllen=0, msg_flags=0}, MSG_DONTWAIT) = -1 EACCES (Permission denied)

Sending on the "master" interface succeeds, but all the other interfaces fail with EACCES.

In observing the daemon, and in reading the code, it looks like currently the lease file can only be written to at this time, it doesn't looks like there is any ability to read from it. Since I upgraded to OpenWRT 14.07 over the weekend and was tweaking things, it was a minor annoyance each time I tweaked something and restarted the daemon to lose all existing IPv6 leases as I experimented getting my setup right.

As a contrast, I have the dnsmasq and miniupnpd lease file on a USB disk so that my leases will persist across deamon AND OpenWRT reboots. I'd love my IPv6 leases to go that way too.

I suspect this is already on the todo list, but I'd love to see it implemented and wouldn't mind assisting where I could.

Hi,

I'm now using some custom dnsmasq options in OpenWRT to issue static routes, alternate default gateway and DNS servers. However these options does not exist in odhcpd.

Would be nice if these could be supported in order to completely replace the DHCP functions in dnsmasq in OpenWRT.

so it can be a replacement for ISC-*

I'm running odcpd (version 2014-06-18-82f3096351911d8c4f3b38e7a5bbeaf75938b6b8) on an OpenWRT box with three interfaces in the lan network (unbridged). Since my ISP only gives me a /64, I'm using relay mode:

config dhcp wan6
    option dhcpv6 relay
    option ra relay
    option ndp relay
    option master 1

config dhcp 'lan'
        [...]
        option dhcpv6 'relay'                    
        option ra 'relay'                        
        option ndp relay

This usually works, but after there has been no IPv6 traffic, I'm getting timeouts on the order of a dozen of seconds or so. It's difficult to reproduce, but the one packet capture that I managed to get seemed to indicate that the OpenWRT box was sending neighbour solicitations over the wan interface rather than the wifi0 one.

I'll provide more info if I can manage to capture a better dump.

--jch

client gets ip address, then i set a static lease for it

client asks for it's old address again (192.168.1.107), server says ACK, but sends the packet to it's new address (.207) instead saying NACK to the old address

17:51:28.249991 IP (tos 0x0, ttl 128, id 9538, offset 0, flags [none], proto UDP (17), length 328)
192.168.1.107.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 7c:xx:xx:xx:xx:b0, length 300, xid 0x2e4f8501, Flags [none]
Client-IP 192.168.1.107
Client-Ethernet-Address 7c:xx:xx:xx:xx:b0
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 7c:xx:xx:xx:xx:b0
Hostname Option 12, length 7: "clientname"
FQDN Option 81, length 10: "clientname"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 13:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
Vendor-Option
17:51:28.252400 IP (tos 0xc0, ttl 64, id 811, offset 0, flags [none], proto UDP (17), length 576)
192.168.1.1.67 > 192.168.1.207.68: BOOTP/DHCP, Reply, length 548, xid 0x2e4f8501, Flags [none]
Your-IP 192.168.1.207
Server-IP 192.168.1.1
Client-Ethernet-Address 7c:xx:xx:xx:xx:b0
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 192.168.1.1
Lease-Time Option 51, length 4: 7200
RN Option 58, length 4: 3600
RB Option 59, length 4: 6300
Subnet-Mask Option 1, length 4: 255.255.255.0
Hostname Option 12, length 7: "clientname"
BR Option 28, length 4: 192.168.1.255
MTU Option 26, length 2: 1500
T119 Option 119, length 8: 108224877,1630745088
Default-Gateway Option 3, length 4: 192.168.1.1
Domain-Name-Server Option 6, length 4: 192.168.1.1

in src/dhcpv6-ia.c, send_reconf the md5 hmac hashing is wrong

I added this test segment into the function, using the 1st test from RFC2202

        const uint8_t text[] = "Hi There";
        uint8_t key[16];
        uint8_t digest[16];

        for (size_t i = 0; i < 16; i++)
                key[i] = 0x0b;

        memcpy(secretbytes, key, sizeof(secretbytes));

        for (size_t i = 0; i < sizeof(secretbytes); ++i)
                secretbytes[i] ^= 0x36;

        md5_begin(&md5);
        md5_hash(secretbytes, sizeof(secretbytes), &md5);
        md5_hash(text, 8, &md5);
        md5_end(digest, &md5);

        for (size_t i = 0; i < sizeof(secretbytes); ++i) {
                secretbytes[i] ^= 0x36;
                secretbytes[i] ^= 0x5c;
        }

        md5_begin(&md5);
        md5_hash(secretbytes, sizeof(secretbytes), &md5);
        md5_hash(digest, 16, &md5);
        md5_end(digest, &md5);

        printf ("test digest: ");
        for(size_t i = 0; i < 16; i++)
                printf("%.2x", digest[i]);
        printf ("\n");
        printf ("expected   : 9294727a3638bb1c13f48ef8158bfc9d\n");

I got this digest instead:
da401ca2fffa2fcecc52f0a6027d56a1

A quick fix was to add md5.c, md5.c and hmac_md5 from dhcpcd source tree and use them instead.

Please ensure your hashing passes RFC2202 and add test suites.
Otherwise the reconfigure function work well with the latest dhcpcd fossil code available from here:
http://roy.marples.name/projects/dhcpcd/timeline

It sends back a status code of 04 for the IAID which causes dhcpcd to SOLICIT for a new address. odhcpd then sends the address we were trying to confirm back to dhcpcd.

Tested using the latest dhcpcd code from fossil, found here:
http://roy.marples.name/projects/dhcpcd/timeline

Setting leasetime to infinite causes odhcpd to fail (only tested IPv6)
uci set dhcp.lan.leasetime='infinite'

It probably can be fixed by adding a conditional statement for IFACE_ATTR_LEASETIME
https://github.com/sbyx/odhcpd/blob/master/src/config.c#L332

dnsmasq currently supports infinite lease time
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

Infinite lease time is represented by a time value of 0xffffffff (uint32) according to RFC
DHCPv4: https://tools.ietf.org/html/rfc2131#section-3.3
DHCPv6: https://tools.ietf.org/html/rfc3315#section-5.6

I use the openwrt trunk r45001. I got a ipv6 address on wan, and i can ping ipv6.google.com. But i can not got a ipv6 address on my PC with win7 64bit. I tried all the models of the odhcpd, but it seems not to work.
I use the commond "ifstatus wan6" , and i got this
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"uptime": 76,
"l3_device": "eth0.2",
"proto": "dhcpv6",
"device": "eth0.2",
"updated": [
"addresses",
"routes",
"data"
],
"metric": 0,
"delegation": true,
"ipv4-address": [

],
"ipv6-address": [
    {
        "address": "2001:250:5004:200b::5a92",
        "mask": 128,
        "preferred": 172724,
        "valid": 259124
    }
],
"ipv6-prefix": [

],
"ipv6-prefix-assignment": [

],
"route": [
    {
        "target": "::",
        "mask": 0,
        "nexthop": "fe80::3600:a3ff:fedd:eb59",
        "metric": 1024,
        "valid": 1724,
        "source": "::/128"
    },
    {
        "target": "::",
        "mask": 0,
        "nexthop": "fe80::3600:a3ff:fedd:eb59",
        "metric": 1024,
        "valid": 1724,
        "source": "2001:250:5004:200b::5a92/128"
    }
],
"dns-server": [
    "2001:da8:1003:1::10"
],
"dns-search": [

],
"inactive": {
    "ipv4-address": [

    ],
    "ipv6-address": [

    ],
    "route": [

    ],
    "dns-server": [

    ],
    "dns-search": [

    ]
},
"data": {
    "passthru": "0017001020010da8100300010000000000000010"
}

}

How to configure the odhcpd to make sure i can use the ipv6 on lan?
Thank you very much! I'm sorry, my English is not good.

Currently I have two clients running, one of them has this as IPv6-Suffix: "0bad0a55". Here are all IPs the client has gotten from odhcpd:

192.168.2.5
fd50:db2f:f4ff:[CENSORED]/64
fd50:db2f:f4ff::bad:a55/128
2001:[CENSORED]::bad:a55/128
2001:[CENSORED]:[CENSORED]/64

and here's what the DNS of odhcpd tells for that client:

test has address 192.168.2.5
test has IPv6 address fd50:db2f:f4ff::bad:a55
test has IPv6 address 2001:[CENSORED]::bad:a55

The other client doesn't has a IPv6-Suffix configured in LuCI and it's even worse. IPs the router gave it:

192.168.2.139
fd50:db2f:f4ff:[CENSORED]/64
2001:a60:f09c:[CENSORED]/64
fd50:db2f:f4ff:[CENSORED]/64
2001:a60:f09c:[CENSORED]/64

but DNS only shows:

test2 has address 192.168.2.139

The commands to get the data where "ifconfig" and "host", both tools where used on the clients.

Hi,

We are developing a cellular router based on Openwrt Barrier Breaker r44550.
Our cellular WAN interface gets an IPv6 global prefix using RA packet automatically.
This is done after our telephony software configures a static Ipv6 local link address which is received by the cellular operator (for the wan interface).
Then we perform "ifup wan" and "ifup wan6" and we get the RA packet that configures the wan with global Ipv6 prefix.

The issue in our case is that our lan interface does not get the Ipv6 prefix automatically.
If we set manually "option ip6prefix" to the wan then it works but we think this should be done automatically by odhcpd, are we missing something here?
We think it does not make sense that our SW will poll the wan interface for the global prefix and will configure ip6prefix since this is what odhcpd should do and we just don't know how to configure it...

Thanks in advance for your assistance.

Our configuration is as follow:

etc/config/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 usbnet0
option type bridge
option proto static
option ipaddr 192.168.1.1
option netmask 255.255.255.0
option ip6assign 64

config interface wan
option ifname ccinet0
option proto static
option ip6addr 'fe80::84e9:3fd7:e533:cb6f/64'

config interface wan6
option ifname ccinet0
option proto dhcpv6

etc/config/dhcp

config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 disabled
option ra server

config dhcp wan6
option dhcpv6 disabled
option ra server
option master 1

config dhcp 'wan'
option interface 'wan'
option ignore '1'

Today's update to odhcpd seems deadly: odhcpd crashes immediately at boot and the same happens if tried to start manually. It seems to crash in libc.o, so it might be some conversion function from today's changes.

Mon Sep  7 16:21:36 2015 kern.info kernel: [  827.241405] do_page_fault(): sending SIGSEGV to odhcpd for invalid read access from 00000000
Mon Sep  7 16:21:36 2015 kern.info kernel: [  827.249939] epc = 771954d8 in libc.so[77122000+95000]
Mon Sep  7 16:21:36 2015 kern.info kernel: [  827.255007] ra  = 004064f5 in odhcpd[400000+b000]
Mon Sep  7 16:21:36 2015 kern.info kernel: [  827.259771]
Mon Sep  7 16:21:36 2015 daemon.info procd: Instance odhcpd::instance1 s in a crash loop 6 crashes, 0 seconds since last crash

The previous build 2 days ago worked ok.

ar71xx / WNDR3700 / trunk with default musl etc.
native ipv6

Basically I want to be able to replace this radvd configuration snippet:

interface br-lan
{
        AdvSendAdvert on;
        AdvManagedFlag off;
        AdvOtherConfigFlag off;

        route fc00::/8
        {
                AdvRoutePreference medium;
        };
};

It statically advertises a route for the fc00::/8 address space on all LAN interfaces, nothing else; no assigning addresses, no extra subnet routes, just handing out that single route. This this possible with odhcpd right now? Is it hard to implement?

After having assigned an IA_PD lease to a node on a local interface, odhcpd starts believing multiple local interfaces do not have any public prefixes, including interfaces on which it has never received any IA_PD request. This causes it to send RAs with a router lifetime of 0, breaking connectivity for the hosts. As shown in logread:

DHCPV6 SOLICIT IA_PD from 000100011e9b70e9525400bc653e on eth0.5: ok 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
DHCPV6 REQUEST IA_PD from 000100011e9b70e9525400bc653e on eth0.5: no prefix available 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
DHCPV6 SOLICIT IA_PD from 000100011e9b70e9525400bc653e on eth0.5: ok 2a02:fe0:c420:57ea::/64 fd65:557c:6f31:5c::/62
A default route is present but there is no public prefix on wlan1 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.2 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.3 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.4 thus we don't announce a default route!
A default route is present but there is no public prefix on eth0.5 thus we don't announce a default route!

The claim that there is no public prefix on the interfaces in question is easily disproved with ifstatus <if> and/or ip -6 address show scope global dev <dev>.

The second line also claims that there is no prefix available. That also seems bogus and a symptom of the bug. There's just no way the entire ULA /48 has been assigned, and the public /64 has only been assigned to that particular IA_PD client.

As mentioned, the bug only appears after having received an IA_PD request. It seems that the number of interfaces impacted varies a bit, however if I send several IA_PD requests (e.g., by restarting the DHCPv6 client a couple of time), every single interface on the box will be impacted.

Restarting odhcpd gets me back to a functional state, but only until the next IA_PD request shows up.

I bisected the issue, and it appears to have been introduced in commit 10fc566. Up until commit 8348741 the default route is present but there is no public prefix on and the no prefix available errors simply do not appear, even if I continuously restart the DHCPv6 client on the node.

Again another dnsmasq feature that odhcpd doesn't have that I'd like to report.

When dnsmasq is used as the DHCP server, it allows resolving of LAN machines that it has assigned IP address (not a surprise, as it is running within the same program), even for IPv6. It means that if I do a "ping6 machine.lan" it can properly resolve to a IPv6 address.

However, since there is no communication between odhcpd and dnsmasq, it doesn't work. One way to fix this is probably to generate a host file in /var/run directory and configure dnsmasq to read it. (Perhaps if dnsmasq can read lease file format that odhcpd generates it can also work now with a simple configuration change).

I'm having an issue with my Samsung Galaxy S6 where the IPv6 preferred lifetime drops to zero while the device is asleep, because it apparently never see the RA to refresh it. I found old bug reports on both Android and Samsung -- this seems to be a long-standing and ignored issue. I can even confirm that ping6 drops as soon as the device sleeps.

So, in the Android report I read that dnsmasq added a --force-fast-ra option here which keeps spamming RAs every 10 seconds. That way the device will get an RA not too long after waking up. Crude, but effective.

Could odhcpd get a similar configuration option? Perhaps as a custom override of MaxRtrAdvInterval?

When sending DHCPv6 relay-foward messages (dhcpv6.c:535), the used socket is bound to the slave interface (dhcpv6.c:63), while it is required to be sent through the master interface; thus the `sendmsg' system call returns EINVAL.
It seems that a UDP socket is also required on the master interface (dhcpv6.c:54), and the relay-forw message should be send through that socket. This solution works for me.

It must be possible to define what address you want to use in the RA. My understanding is that right now, the RA takes the link-local address automatically created with the Interface ID.

However in many other platforms, is possible to decide if you want to use the Interface ID or something different, for example, I want to use FE80::1.

Right now it seems not possible.

Using list ip6addr 'fe80::1/64', in the given interface, will work for now if you manually configure FE80::1 as the default GW in client machines, but the RA still uses the Interface ID.

Especially since openwrt chaos calmer (15.04) appears to have dropped dhcrelay, it would be good if a feature could be added to relay dhcpv4 requests to dhcp servers on other interfaces. (Preferably a list of servers, and could be different per interface).

The commit sbyx@5b12eeb breaks IPv6 DNS with Linux systems. If the system is configured to use IPv6 only, DNS lookups fail. For dig, the error is "connection timed out; no servers could be reached". I can reproduce this issue on Ubuntu 16.04 with NetworkManager.

I am building from trunk and requesting a /60 via either ip6assign or reqprefix...

Not getting one. I used to get one. I will check to see if I get one from an older box on the same link.

Have a horde of other dhcp issues...