#so on the iOS app there is a detail view
1 messages Β· Page 1 of 1 (latest)
Let's take this to a thread, I think
https://cloud.lynxcore.org/index.php/s/txCCyxKLxqR4sPa can't upload an image in a thread, it seems
ok good
this device is on your network, it has an ipv6 address that looks like a typical thread ULA
sf is 1 which means it should be pairable
eh... does thread need IPv6?
yes
because I might have disabled that π let me check
HAOS IPv4 is static, HAOS IPv6 is DHCP, but I don't know if my firewall advertises v6 correctly
gimme a moment
the router is what's advertising the v6 address to the HAOS VM via DHCP, though?
no
thats why its important we have a single L2 segment - the border router sends ICMP6 packets telling everyone they are a router
"DHCP" is a bit of a bug in HAOS IMO, having it set to DHCP lets it process these ICMP6 packets
ah
do you see a _meshcop._udp?
ok
so the new stuff in the beta likely won't be able to understand the nanoleaf BR
we'll have to go old school
do you have SSH access to HAOS - and is it the "real" ssh on port 22222 or is it the web addon thing.
it's whatever came out of the box with the VM image
I also have a docker container with the same version/config, but that one is a bit iffy on the network side
i need you to run through this and get working ssh access: https://developers.home-assistant.io/docs/operating-system/debugging/
from there, i'll be able to guide you through some ip checks to check HA and the BR can see each other.
k. gimme a bit, I have a meeting in parallel π I'll get back to you in about an hour or so
π
alright, I'm connected. Hit me when you're ready π
okie okie
so docker ps and try and find the main home assistant container
then docker exec -it ITSID sh to get a shell in it
if you got the right one, then which hass should return a path
/usr/local/bin/hass
/config # ip -6 route
::1 dev lo metric 256
anycast fe80:: dev docker0 metric 0
anycast fe80:: dev hassio metric 0
anycast fe80:: dev veth6d98284 metric 0
anycast fe80:: dev veth60e9d53 metric 0
anycast fe80:: dev vetha76ba9d metric 0
anycast fe80:: dev veth9ab214f metric 0
anycast fe80:: dev veth170e699 metric 0
anycast fe80:: dev vethe4f85c6 metric 0
fe80::/64 dev enp0s3 metric 100
fe80::/64 dev docker0 metric 256
fe80::/64 dev hassio metric 256
fe80::/64 dev veth6d98284 metric 256
fe80::/64 dev veth60e9d53 metric 256
fe80::/64 dev vetha76ba9d metric 256
fe80::/64 dev veth9ab214f metric 256
fe80::/64 dev veth170e699 metric 256
fe80::/64 dev vethe4f85c6 metric 256
multicast ff00::/8 dev docker0 metric 256
multicast ff00::/8 dev hassio metric 256
multicast ff00::/8 dev veth6d98284 metric 256
multicast ff00::/8 dev veth60e9d53 metric 256
multicast ff00::/8 dev vetha76ba9d metric 256
multicast ff00::/8 dev veth9ab214f metric 256
multicast ff00::/8 dev veth170e699 metric 256
multicast ff00::/8 dev vethe4f85c6 metric 256
multicast ff00::/8 dev enp0s3 metric 256
great
theres no route from your BR there
apk --no-cache add tcpdump
tcpdump -evvv -ni enp0s3 icmp6
wait about 5 and then show me what you see
5 minutes, I guess. 5 seconds shows me nothing so far
yeah sorry haha, 5 mins
π
for reference, we are looking for something like this:
hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0ms, retrans timer 0ms
source link-address option (1), length 8 (1): a8:51:ab:90:6e:d0
0x0000: a851 ab90 6ed0
prefix info option (3), length 32 (4): fdbe:e98b:173f:4f12::/64, Flags [onlink, auto], valid time 1800s, pref. time 1800s
0x0000: 40c0 0000 0708 0000 0708 0000 0000 fdbe
0x0010: e98b 173f 4f12 0000 0000 0000 0000
route info option (24), length 16 (2): fdcd:7fc0:8284::/64, pref=medium, lifetime=1800s
0x0000: 4000 0000 0708 fdcd 7fc0 8284 0000
route info option (24), length 16 (2): fd21:1896:ac15::/64, pref=medium, lifetime=1800s
0x0000: 4000 0000 0708 fd21 1896 ac15 0000```
and we are seeing precisely nothing
tcpdump: listening on enp0s3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
what do you see in ip -6 a s enp0s3?
/config # ip -6 a s enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::a96:668f:29be:97b4/64 scope link noprefixroute
valid_lft forever preferred_lft forever
if this was working you'd get an extra ip on that interface from the BR
ok
can you repeat these steps on your other linux machines and ideally on your VM host
my desktop:
2: enp9s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet6 fd08:ad6:8b18:1:a849:2057:ac1c:a11f/64 scope global dynamic noprefixroute
valid_lft 1625sec preferred_lft 1625sec
inet6 fe80::1d27:ad68:1d59:6a76/64 scope link noprefixroute
valid_lft forever preferred_lft forever
VM host returns nothing on the interface in question. I am running Macvtap for the networking
fd08:ad6:8b18::/64 via fe80::828a:f7ff:fe07:546d dev enp9s0 proto ra metric 100 pref medium
fd08:ad6:8b18:1::/64 dev enp9s0 proto ra metric 100 pref medium
fe80::/64 dev kube0 proto kernel metric 256 pref medium
fe80::/64 dev enp9s0 proto kernel metric 1024 pref medium
ehm. I just realized that I have disabled the whole IPv6 stack on the VM host
so of course nothing gets forwarded to the VM
my bad
if it was in bridge mode (like a switch) i'd kinda of expect it to work anyway
but definitely should start there
in that case thanks for the help. The VM host is running my firewall, and I can't reboot that for the next few hours. Afterwards I'll debug a bit myself and I hope I won't have to hit you up again π
I think I'll just set up a fresh VM on my desktop for diffs and see how that goes.
Just to let you know - rebooted the VM host with v6 enabled, thread works like a charm. So the problem was DECIDEDLY in front of the keyboard.
Thanks for the help π
let me check
nope
and semi-related, I've stumbled upon an unhandled exception in homekit_controller:
Pairing attempt failed with an unhandled exception
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 491, in async_step_pair
self.finish_pairing = await discovery.async_start_pairing(self.hkid)
AttributeError: 'NoneType' object has no attribute 'async_start_pairing'
I don't know if that's your coding style and thus intentional, but if it isn't, now you know π
no thats definitely a bug
What I did:
Factory Reset the strip (Hold PWR and + for 5+ seconds, wait for it to flash white three times, then enter the pairing code from the back of the controller in both XXXXXXXX and XXXX-XXXX formats) and that's what I got
at the same time, I got the following additional errors in the log:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohomekit/zeroconf.py", line 312, in async_find
if discovery := await waiter:
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohomekit/zeroconf.py", line 311, in async_find
async with async_timeout.timeout(timeout):
File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 129, in __aexit__
self._do_exit(exc_type)
File "/usr/local/lib/python3.10/site-packages/async_timeout/__init__.py", line 212, in _do_exit
raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/aiohomekit/zeroconf.py", line 315, in async_find
raise AccessoryNotFoundError(
aiohomekit.exceptions.AccessoryNotFoundError: Accessory with device id 8c:d7:69:04:2c:cd not found
Want me to raise a github issue somewhere?
And more info: This happens even before I enter the code, during the setup wizard
ok
so if you factory reset the strip you are going to hit all sorts
it probably was on the thread network, but when you factory reset it, it will have dropped off
like, just vanished
but the "discovery" would have remained visible in HA
so the "pairing" attempt was against a device that no longer exists
ok. so, currently, I have the strip paired to my nanoleaf android app and showing as a thread device in there. It's my understanding that I need to unpair/reset it for the homekit_controller pairing to succeed.
If that's wrong i can try pairing it again without dropping it from the app and/or resetting it
you need to unpair it from ios, but in your case it is not paired to ios in the first place
if you look at the zeroconf record and it says "sf=1" you are good to go
ok, now it's getting weird again. I now see 2 strips in bonjour browser, both sf=1
Nanoleaf-Strip-5LKF.local.
Nanoleaf-Strip-5LKF\0321.local.
ok, something went WEIRD in my setup here. I now shut off the strip, dropped it from the app, rebooted HA. Now only one device shows up, and that one paired successfully.
So, I'm glad it works now, and VERY thankful for your help, but I need to understand the whole Thread ecosystem way more, I think.