Thread border router technical deep-dive (part 1)

This blog post series documents some deeper technical details on how Thread works, in particular border routers. Most of my insights are from real world findings while working on the OpenThread Border Router add-on for Home Assistant.

Thread is an IPv6-based, low-power mesh networking technology for Internet of things (IoT) products.” according to the Wikipedia article of the Thread protocol, and that really sums it up nicely. Thread is based on the same physical layer as Zigbee: IEEE 802.15.4. Unlike Zigbee, Thread provides IP connectivity. It does not specify the application level protocol, e.g. how to actually control a light bulb. This is where other protocols come in, like Matter. Similar to Zigbee, some Thread devices act as routers within the mesh. However, there is no single predefined coordinator like in Zigbee networks. There is a single Thread leader in every Thread partition which manages the Thread routers. The Thread leader is selected automatically. And there can be multiple border routers which allow communication with Thread devices. This redundancy avoids a single point of failure and can also improve connectivity with the mesh. In my opinion, the use of IP, and the fact that multiple border routers can provide connectivity to the main network are the biggest advantages of Thread and sets it really apart from existing mesh networks.

This article is mostly focusing on this Thread border routers. To learn more about Thread in general, the excellent Thread Primer on openthread.io is a very good resource and is probably a good read in case you are not that familiar with Thread yet. This first part focuses on describing what type of IPv6 network prefixes are in use in a Thread network.

Continue reading “Thread border router technical deep-dive (part 1)”

IPv6 renew issue with Fiber7 and OpenWrt

Since using Fiber7, I was having issues with IPv6 connectivity using OpenWrt. Debugging revealed that Init7’s IPv6 server sets the DHCPv6 Unicast option along with a unicast address, but does not respond when using unicast addressing to renew the lease 20 minutes later. The lease then expires and breaks IPv6 connectivity.

A DHCPv6 server can choose to announce the unicast option, but if announced, the server is supposed to reply to unicast requests. So this seems to be a misbehaving DHCPv6 server. Luckily, the DHCPv6 client shipped with OpenWrt 18.06 now comes with a workaround (odhcp6c: add noserverunicast config option for broken DHCPv6 servers). The option noserverunicast ignores any advertised server unicast addresses and continues using multicast. Init7’s DHCPv6 server seems to answer renew requests using multicast just fine, providing stable IPv6 connectivity.

To enable this workaround, add the following line to the IPv6 WAN interface:

config interface 'wan6'
        ...
        option noserverunicast '1'

Then restart your router. Continue reading “IPv6 renew issue with Fiber7 and OpenWrt”

iptable prevents nftables to be loaded

Since a while I am using nftables for my firewalling needs. My nftables.conf has some prerouting settings. After playing with docker, I had the issue that I was no longer able to reload my nftables:

/etc/nftables.conf:12:9-18: Error: Could not process rule: Device or resource busy
chain prerouting {
^^^^^^^^^^

Also disabling the Docker service did not help. It seems that the kernel module iptable_nat needs to be removed, but this is currently in use:

# rmmod iptable_nat
rmmod: ERROR: Module iptable_nat is in use

There are some iptable rules/chains active which prevent the module from unloading. By clearing the iptable configuration, especially the nat table, it is possible to remove iptable_nat and then using nftables again.

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

 

 

 

WireGuard, LEDE and some IPv6 fun

Today I upgrading my router to LEDE 17.01 and played a bit with IPv6 and WireGuard VPN tunnels. My Internet connection at home (connected via Cable to the Comcast network) has decent IPv6 support, which I wanted to enjoy also when on the road, using non-IPv6 networks. The first step is to setup a Wireguard tunnel, which I already did some months ago (Dan Lüdtke, author of the LEDE/OpenWrt web interface plugin for Wireguard has a good post on thatUpdate April: Dan has a new post which does not make use of the stacked approach. This is suitable for lots of regular setups. However, the IPv6 address setup with automatic network assignment described here is only supported by using stacked interfaces, hence this article keeps using that configuration). In my setup the Wireguard IPv4 network uses a network from the private range (192.168.2.0/24) to route IPv6 traffic. For IPv6 my goal was to assign a public subnet, so I can access the IPv6 network without any NAT directly through the tunnel. In IPv6 world, NAT is a technology which is not commonly used/considered deprecated anyway. Note that this how-to does not route the IPv4 traffic to the internet through the VPN tunnel, only IPv6 traffic.

First, a large enough IPv6 prefix needs to be available on the router in order to assign two independent IPv6 networks to my local LAN and the Wireguard VPN. One has to realize that in IPv6 world, subnets are by definition between /49 and /64. One cannot create a subnet /72 or similar since the last 64 bits are the host portion, reserved exclusively for host addresses. By default, LEDE requested a 64 bit IPv6-prefix from the provider, but this can be changed in the WAN6 network interface settings:


Continue reading “WireGuard, LEDE and some IPv6 fun”

Debug IPv6 issues on OpenWrt

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? Continue reading “Debug IPv6 issues on OpenWrt”