My new provider IPv6 connectivity, however after connecting my OpenWrt based WNDR4300 (using Chaos Calmer 15.05-rc3) things unfortunately did not “just work”… This post summarize some hints how to debug IPv6 on OpenWrt.
First, make sure that the upstream (WAN) interface is configured according to the documentation in the OpenWrt Wiki. Using LuCI, you have to create a new interface (WAN6) which should c
If your ISP provides IPv6 support, it should “just work” at this point. However, what to do if not?
There are different ways how addresses can be assigned, two methods are stateless address autoconfiguration (SLAAC) and stateful address assignment using DHCPv6 and prefix delegation. My goal is to use DHCPv6 along with prefix delegation.
In my case, the WAN interface got an IPv6 address assigned and could ping a IPv6 address in the internet just fine. However, the LAN interface nor the hosts on the LAN received an IPv6 address. I had the “
# ip addr show dev eth0.2 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether aa:ca:fb:11:f0:39 brd ff:ff:ff:ff:ff:ff inet 123.123.123.123/22 brd 123.123.123.255 scope global eth0.2 valid_lft forever preferred_lft forever inet6 2001:db8:9ff:2000:aaca:fbff:fe11:f039/64 scope global noprefixroute dynamic valid_lft 2591967sec preferred_lft 604767sec inet6 fe80::ecca:fbff:fe11:f039/64 scope link valid_lft forever preferred_lft forever
Normally, the system log should contain the output of daemons, however, I did not get any hint what could go wrong from the system log. To increase the verbosity of odhcp6c I disabled DHCPv6 by configuring WAN6 as unmanaged and invoked the DHCPv6 client manually from the OpenWrt routers shell (odhcp6c):
# odhcp6c -s /lib/netifd/dhcpv6.script -Ntry -P0 -t120 eth0.2 -e -v odhcp6c[22466]: (re)starting transaction on eth0.2 Command failed: Not found odhcp6c[22466]: Starting SOLICIT transaction (timeout 4294967295s, max rc 0) odhcp6c[22466]: Got a valid reply after 5ms odhcp6c[22466]: Got a valid reply after 7ms Command failed: Not found odhcp6c[22466]: Starting REQUEST transaction (timeout 4294967295s, max rc 10) odhcp6c[22466]: Send REQUEST message (elapsed 0ms, rc 0) odhcp6c[22466]: Send REQUEST message (elapsed 955ms, rc 1) odhcp6c[22466]: Send REQUEST message (elapsed 2835ms, rc 2) odhcp6c[22466]: Send REQUEST message (elapsed 6665ms, rc 3) odhcp6c[22466]: Send REQUEST message (elapsed 14675ms, rc 4) odhcp6c[22466]: Send REQUEST message (elapsed 30705ms, rc 5) Command failed: Not found Command failed: Not found odhcp6c[22466]: Send REQUEST message (elapsed 62635ms, rc 6) Command failed: Not found Command failed: Not found odhcp6c[22466]: Send REQUEST message (elapsed 92515ms, rc 7) Command failed: Not found Command failed: Not found odhcp6c[22466]: Send REQUEST message (elapsed 124761ms, rc 8) Command failed: Not found Command failed: Not found odhcp6c[22466]: Send REQUEST message (elapsed 154545ms, rc 9) Command failed: Not found Command failed: Not found odhcp6c[22466]: (re)starting transaction on eth0.2
This looks like the request messages get not answered properly.
Normally, the DHCPv6 client requests an IPv6 non-temporary address (Identity Association for Non-temporary Addresses, IA_NA) for the WAN interface as well as a prefix delegation (Identity Association for Prefix Delegation, IA_PD). The first can be seen as plain old DHCPv4 address assignment, while the latter is more than that: The router receives a whole subnet (network prefix) which is globally valid and will be routed to your router. This allows the router to assign globally valid IPv6 addresses to the devices in your network. Typically, a DHCPv6 session should look something along these lines:
OpenWrt ISP DHCPv6 Server
fe80::aaca:68ff:fe11:62cd fe80::ce4e:24ff:fe1c:3333
| |
| (link-scoped multicast address) |
| ff02::1:2 |
| | |
| | |
| Solicit Trans-ID: 0x28d6 | |
|---------------------------------------->| |
| | |
| | |
| Advertise Trans-ID: 0x28d6 | |
| IA_NA: 2001:db8:77b5::8758:1493 | |
| IA_PD: 2001:db8:2003:4e00::/56 | |
|<-------------------------------------------------------------|
| | |
| | |
| Request Trans-ID: 0x35a2 | |
| IA_NA: 2001:db8:77b5::8758:1493 | |
| IA_PD: 2001:db8:2003:4e00::/56 | |
| --------------------------------------->| |
| | |
| | |
| Reply Trans-ID: 0x35a2 | |
| IA_NA: 2001:db8:77b5::8758:1493 | |
| IA_PD: 2001:db8:2003:4e00::/56 | |
|<-------------------------------------------------------------|
In my case it seems like the last request/reply messages somehow do not work as expected. Either the request doesn’t find its way to the provider, or the reply doesn’t make it back to the DHCPv6 server. Another possibility would be that the DHCPv6 server discards the reply message for some reason. The best way to further debug this is to actually look at the traffic using Wireshark.
Capturing remotely OpenWrt WAN traffic using Wireshark
First, install tcpdump on the firewall using opkg or the web interface.
# opkg update # opkg install tcpdump ...
Then, on your host, create a FIFO using mkfifo and connect to the OpenWrt router using SSH. Make sure to choose the WAN interface. To avoid a password prompt which gets redirected to /tmp/openwrt_capture, I had to use Public Key Authentication.
$ mkfifo /tmp/openwrt_capture $ ssh root@192.168.1.1 "tcpdump -s 0 -U -n -w - -i eth0.2 not port 22" > /tmp/openwrt_capture [login]
At that point all WAN traffic will be captured and forwarded to the local FIFO. You can now use Wireshark to see the packet flow in real-time:
$ wireshark -k -i /tmp/openwrt_capture
(see also Niels Horn’s Blog for details)
If you are interested in seeing the DHCPv6 packets I captured, you can find a pcap file in the issue I opened on the Github issue tracker of odhcp6c. The DHCPv6 traffic showed that the reply message was actually reaching the OpenWrt router. However, the source address of the reply message was not a link-local address, but a global address. It turned out that the OpenWrt’s default firewall configuration only allows DHCPv6 traffic from the link-local address… The solution to my problem was rather easy: Adding another firewall rule which allows the traffic of the global address the DHCPv6 packets are sent from. After activating this rule and reenabling the DHCPv6 client on the WAN interface, IPv6 worked as expected: The LAN interface got a prefix allocated, the interface had a global address configured automatically and the hosts connected to my LAN network received an address from this pool too.
Hi there, so your post and I have the same problem, can you tell me how you got this to work?
Feel free to email me directly,
Thank your!
Hi, sorry for the late reply. The solution to my problem is documented in the post. If you have exactly the same problem as I had, just adding the additional firewall rules should help.
—
Stefan
I just want to thank you for this post, since it helped me get my IPv6 working too!