Sorry, but a share does not make sense. As soon as you delete that answer in your account, it is not accessible anymore.
It’s not deleted and MY experience is that I get strong blowback posting AI generated content in a forum like this. This way, if someone wants to NEVER read AI generated content then that snowflake is saved from the horror.
How do you know? This forum has posts from the last decade, do you exactly know what happens with your ai account in 10 years?
If people want to read ai generated content, they are fine to do that on their own. It is as easy as posting here …
Then the content will likely not be relevant.
The vitriol I have experienced makes me reluctant to post raw AI generated content.
If you want to continue this discussion, I suggest a DM
Nope, I won’t change my mind. It is not worth the effort.
I can see the answer in ChatGPT, but I could not solve the problem. I am sure, Im̀ doing something wrong. I need a step ba step help.
My issue with matter is related with the ipv6 configuration, but I am not able to solve the problem.
That interesting, not sure either. Just fyi, matter.js upstream has made several improvements to networking, especially around thread devices, i’ll have that updated once i’m back from my trip to Fosdem.
Can you show what ipconfig outputs in your docker container? You may need to run apt update && apt install -y net-tools to install ipconfig (you can also try using ip addr && ip route which may work out of the box).
also what does sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.default.accept_ra and sysctl net.ipv6.conf.eth0.accept_ra output ?
the output:
michael@feurlenas ~]$ sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.default.accept_ra
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.default.accept_ra = 0
with the command: docker exec -it openhab-nas cat /etc/hosts
output is:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.3.2 60f1ea0df121
192.168.20.30 60f1ea0df121
is this helpful?
The most important command i need was the first one i asked for, either ipconfig or ip addr && ip route , can you please re-read my post and try one of those?
Hi Dan!
Now I hope I found the right commands and output:
root@3b9ba4d556f7:/openhab# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.3.2 netmask 255.255.255.0 broadcast 10.0.3.255
ether 02:42:0a:00:03:02 txqueuelen 0 (Ethernet)
RX packets 45618 bytes 64664614 (61.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 22297 bytes 1705537 (1.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.20.30 netmask 255.255.255.0 broadcast 192.168.20.255
ether 02:42:65:f4:9f:b5 txqueuelen 1000 (Ethernet)
RX packets 81545 bytes 31272878 (29.8 MiB)
RX errors 0 dropped 605 overruns 0 frame 0
TX packets 34042 bytes 3467458 (3.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1205 bytes 124951 (122.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1205 bytes 124951 (122.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@3b9ba4d556f7:/openhab# ip addr && ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
186: eth0@if187: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:0a:00:03:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.3.2/24 brd 10.0.3.255 scope global eth0
valid_lft forever preferred_lft forever
188: eth1@if189: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:42:65:f4:9f:b5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.20.30/24 brd 192.168.20.255 scope global eth1
valid_lft forever preferred_lft forever
default via 10.0.3.1 dev eth0
10.0.3.0/24 dev eth0 proto kernel scope link src 10.0.3.2
192.168.20.0/24 dev eth1 proto kernel scope link src 192.168.20.30
root@3b9ba4d556f7:/openhab# sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.default.accept_ra
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.default.accept_ra = 1
root@3b9ba4d556f7:/openhab# sysctl net.ipv6.conf.eth0.accept_ra
net.ipv6.conf.eth0.accept_ra = 1
Thanks Michel, thats helpful. So your docker container does not have a IPv6 address at all , not even a link local address (which is self assigned), so IPV6 is disabled in docker to start (and i’m not sure about the host). The only thing it has is a loopback address of inet6 ::1/128 scope host which is the equivalent of 127.0.0.1 in IPv4. I’m not familiar with Qnas, i see a bunch of network interfaces, is this docker running in HOST networking mode? There are instructions in the README about enabling IPV6 using sysctl that i would try first in the container, and if you can , i would suggest making sure your Qnap really has IPV6 enabled.
Also what do these commands run in the docker container output?
sysctl net.ipv6.conf.all.disable_ipv6
sysctl net.ipv6.conf.eth0.disable_ipv6
sysctl net.ipv6.conf.eth1.disable_ipv6
These commands changed nothing. I think, IPV6 in a docker container is not really possible, at the moment..
But no problem. I can manage my Ikea things over the Dirigera binding, and the Switchbot with the Echo Control binding. They are working in docker container.
Thank you for your support.
I was just wanting their output (it does not set anything), if they are set to 1 then ipv6 is disabled in docker itself.
The outupt is:
root@3b9ba4d556f7:/openhab# sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
root@3b9ba4d556f7:/openhab# sysctl net.ipv6.conf.eth0.disable_ipv6
net.ipv6.conf.eth0.disable_ipv6 = 1
root@3b9ba4d556f7:/openhab# sysctl net.ipv6.conf.eth1.disable_ipv6
net.ipv6.conf.eth1.disable_ipv6 = 1
root@3b9ba4d556f7:/openhab#
helpful?
Yes, that shows IPV6 is disabled in docker itself (the runtime), so there is likely a QNAS setting that needs to be enabled to turn on IPV6 in the docker runtime they are using ( this is going to be QNAS specific).
Actually, i just googled qnap docker enable ipv6 and besides enabling IPV6 in general on the QNAS, it looks like you have to ssh into it and modify /etc/docker/daemon.json to make sure it contains something like this
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}
where the 2001:... is the IPV6 network you want to use. Maybe give that a try ? (make sure to back this file up just in case something goes wrong).
In one of the earlier posts I read:
I have installed OTBR from this site: Native Installation | OpenThread on my Raspi 4b running openhabian with ipv6 enabled. From the log it seems to run an talk to the ConbeeII stick.
How can I pair the OTBR as a node from the Matter Controller in openHAB? Where can I find ts Node-ID?
Regards Christoph
Unfortunately the problem is back !
Maybe my remote is generally too far from my TBR ? But even if I move it near the TBR, it does not resolve the problem.
My other Thread devices seem to not encounter the same problem.
I will buy a Thread Ikea bulb to enhance the Thread mesh network with a new powered Thread device.
There has been a number of thread related improvements in the upstream library , I’ll update my pr when I have a chance soon, maybe that might help as well . I also read something about how ikea thread devices are a bit of a disaster for them , many tech reviewers have been unable to get them to work in simple setups using apple or google ….. but hopefully a firmware upgrade and maybe an update to our library will help .