Your NAS has bad kernel build options. You need CONFIG_IPV6_ROUTER_PREF and CONFIG_IPV6_ROUTE_INFO to be able to process the information from your border router, which your NAS doesn’t have (accept_ra_rt_info_max_plen becomes available when the kernel is compiled correctly).
Okay so then we can not use this on a Synology NAS, am I correct? Because I think we can not change the kernel 
No worries, I certainly appreciate the help.
You are correct in that when I add the route manually, everything works fine. The route is never discovered (at least with the settings I’ve attempted so far) from inside of the container.
My docker container is setup using a macvlan network
I am setting net.ipv6.conf.eth0.accept_ra=2 and net.ipv6.conf.all.accept_ra_rt_info_max_plen=64 from the docker-compose.yml. From inside the container, I’ve looked at the sysctl output and verified they are reflected successfully there. I did max_plen on “all” versus on the interface itself. I didn’t think to try the interface, actually.
Yeah I don’t think all works for that one.
And it can take 10-20 minutes for it to work. A HomePod should send a route advertisement every 3 minutes but the lifetime is 30 minutes.
So try setting it on the interface. And give it some time to kick in.
If it still doesn’t work, install tcpdump in the container and do “tcpdump -evvv -ni eth0 icmp6” and wait 10 minutes. And post the output.
1 Like
Yes and no.
What you are doing now will not work.
If you can run a VM in your NAS that could work. If you get the networking right, it would have to be bridged or whatever your device calls that.
It might be there is software that can process the RAs from the border routers. For example, HAOS actually uses NetworkManager instead of the kernel (though that is buggy so even id symbology could run it you really don’t want to).
Alternatively you could run a SkyConnect connected to the NAS. You aren’t running HAOS so you would have to quite a bit of manual work but OTBR running locally doesn’t depend on RAs so it would get past that problem.
You’re correct, again. I changed my docker-compose line to specify the interface, and the RA appears to have worked. The route I was manually creating was created automatically. So just to be clear for anybody else who gets to this point, I am:
- Running HA in a docker container
- Using a macvlan docker network (in my case the interface is eth0 inside of the container).
- Used the following addition to my HA container config in docker-compose.yml:
sysctls:
- net.ipv6.conf.eth0.accept_ra=2
- net.ipv6.conf.eth0.accept_ra_rt_info_max_plen=64
Of course, be mindful of spacing for YAML.
@Jc2k thank you again for your diligence and suggestions. I do eventually plan to setup my SkyConnect once I get it flashed for multiprotocol (there’s another thread going on where it seems like somebody was able to pull it off). However, I’ve also read grumblings about issues with multiple (Apple?) border routers causing problems, so I’m glad I can call this “working” until more information comes out there.
1 Like
Yes, if if you don’t use skyconnect you likely face some challenges.
Right now the most understood issues only hurt HAOS users. The issue is what I call ghost routes. Every time your HomePod gets a new route, haos has no ability to expire the old route (because of bugs in HAOS).
HAOS 10 won’t suffer from this bug, but has a new bug where you can only have one route at a time. This means if you have 3 HomePods you’ll
See a route table flap once a minute.
If don’t use HAOS it can still take 30 minutes for Linux to notice a route is no longer valid.
Then even if the router is there, there is no guarantees it works. We are seeing cases where BR is online but can’t see all the devices in mesh. Removing route can help it choose a better BR. This is especially common with appletv.
(OTBR can do something called TREL where it uses your WiFi or Ethernet to compensate for blindspots in your thread network. Apple doesn’t seem to support this yet).
I assume this is fixable at some point?
@Jc2k Thanks again for all your work here. Have you had anyone come across issues with the Wemo Stage Controller? A few weeks ago, I was able to successfully add and then provision two different Stage Controllers to my Thread Network (Home Assistant Yellow’s OTBR), and things were working great. I setup automations that responded to each button type. Then, things stopped working. It’s hard to document, but basically if I did a full reboot of the HA Yellow followed by another restart of HA Core, I could sometimes get the automations to run. Now, it seems like I can’t get it at all. Furthermore, when I go into the automations I no longer can select the Button as a Trigger. Clicking Identify does, however, light up the Stage Controller.
Happy to provide more details or logging if you haven’t seen this before.
I have one of those and sometimes it stops working and a restart of HA fixes it. I haven’t had time to investigate why. It controls the garden lights do fairly high on my list should I get some spare time!
Honestly no idea. It’s not a small piece of work, and it involves a third party upstream. The best bet for the near term is to ditch NetworkManager which in itself is a substantial piece of work.
Ok cool, thanks. When I removed the Stage Controller and re-added it, it did once again show the Button options in the Automation. My remaining (unremoved stage controller) still doesn’t.
Doesn’t that mean that Thread on HAOS is basically going to be broken (or at least not work reliably) for almost any real-world scenario (i.e., want to use their Apple Devices, Google Devices, Echoes, etc as BRs?)
In theory? For multi-br, pretty much. In practice? I don’t know how reliable a good mesh will be in the face of route churn. If the route replacement code in NetworkManager is atomic, then HAOS 10 will be usable for most people. If it’s not, I’d expect blips. But I think the blips would have to be blippy enough to cause packet loss to notice the disruption. It could be fine most of the time in practice and recover quickly if it does cause a problem. For a lot of people it might be fine. Where I expect issues is where you have a BR that doesn’t implement the TREL extension (like Apple). If you have a HomePod that is the primary router and it’s in room with poor mesh connectivity, then you will not have access to the mesh. TREL will let the mesh use your WiFi and Ethernet to help avoid mesh splits, avoiding this issue.
1 BR with HAOS 10 will be fine. SkyConnect should be fine.
I do have some of this running on my main HA (because I “eat my own dog food”. But I’d generally encourage anyone that wants bullet proof HA to avoid thread and matter for the time being.
Yeah… however, I’m a dive in kinda guy. 
My main motivator for wanting thread is I have Level Lock Bolts on my three exterior doors. Right now they are bluetooth with thread activation “coming soon”. The ESP BT Proxy works (I use two to reach my locks), but it’s 1-30s to activate the lock - which makes me not so popular with the family. My house is like an Apple Store so I have 7 BRs throughout and so almost any Thread device I have would be in the same room as a BR.
Also, those locks would be my only thread devices (well, I do have one wemo outlet I bought to play with), so I wouldn’t have a great (any) mesh at first.
Who knows, maybe by the time Level releases the Thread firmware update, this issue will be solved on the HAOS side.
When is HAOS 10?
Quick Google shows they’re on rc3 which means it’ll likely be out soon, don’t think they have an actual release schedule though I could be wrong.
On the topic of nanoleaf, I picked up a 3 pack of the matter enabled essentials bulbs and getting them to work was pretty painless.
Pairing through the HA app didn’t work for whatever reason, but once I linked it to nanoleaf app, I could go into bulb settings, press connect matter, and it gave me a choice of apps I had installed including HA. Once I hit HA it took a minute then when it was done it showed up in HA under the matter integration and automatically connected to the HA thread network, which I was even able to verify in the nanoleaf app.
Apparently the elements I’m using for the old essentials apparently needs firmware 7.5 (coming soon) to support the matter bulbs over thread, but I may switch all my bulbs over to the HA thread network.
But in any case, it’s nice to see that as long as you have a thread radio you should be able to get the new bulbs into HA without needing a home kit specific thread router or the amazing hackery of this entire thread.
The new bulbs are also maybe about 20% lighter too interestingly enough.
In any case, thanks for all the hard work in being able to make the old bulbs as usable as they are, saved me a ton of buyers remorse 
1 Like
So my current setup with with the following BRs:
- HomePod
- Google Nest Hub Max
is not going to be great. The HomePod is by far the closest BR to my nanoleafs (nanoleaves?) and so it would be the primary. Therefore even with HAOS 10, I’ll still end up losing connectivity (which I feel I’ve actually seen more frequently since upgrading to HAOS 10 - although I seem to think in the past I had to reboot, whereas now I just restart).
Not sure what you mean.
If your apple BR is close to the nanoleaves is probably good for the mesh health.
To clarify, the currently active BR is not a function of proximity, it’s somewhat random. It can change on a whim. So you can’t predict which will be the main one at any given time.
Also I’ve not seen a hybrid apple and google setup before, I’d be surprised if you didn’t have 2 separate thread networks.
HAOS10 solves ghost routes and fixes neighbour unreachability detection. But there are still other issues to track down, some of which were probably masked by network manager bugs in the previous version.
I think I misunderstood the TREL feature - but I get it now. And yeah, I should have been a little more clear wrt to the BRs - yes, I do have 2 separate thread networks.
So with HAOS 10 the merry-go-round starts again! I guess that’s the joy of new tech - squashing one set of bugs often reveals that there are more hidden deeper in the cupboard. Fair enough - time for me to start collecting logs and searching bugs for other similar reports.