19 minutes ago, Espressomatic said:

Does your ISP assign you an IPv6 range?

 

My IPv6 is all link-local as my ISP doesn't support IPv6 at all, and I have it turned off at my pfSense router. Unraid hosting HAOS VM is also set to IPv4 only.

 

If ISP doesn't give out a static IPv6 range, there's no point (and can't) set IPv6 static address for the router. If router doesn't have static IPv6, you can't run a local IPv6 DHCP. If there's no IPv6DHCP, there's no point/need to turn on IPv6 on a host. None of this seems to stop or block Matter servers/devices from using link-local addresses and communicating.

 

Matter and Thread working in HA with the single end-device I have at the moment, Aqara Hub feeding U100 lock. Every border router can also be communicated with, 3x Eero and 5x Apple devices (Homepod and AppleTV)

 

 

in pfsense due to ipv6 implementation you would still have a empty ipv6 dhcp wan that will never get a Ip[ address and use a manul prefix such as 48 / 64... this whay dhcp ipv6 can use a prefix delegation and use a ipv6 to ipv4 tunnel route at the wan lever for connectivity. If your ISP done't have a ipv6 dhcp server running you want to make sure of any ipv6 slac ieee standards to and to generate the iv4 tunnel tap to use a ipv6 dhcp server.

https://ieeexplore.ieee.org/document/10145649

https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6.html

In your case you just want the ipv6 dhcp on your local netwrok for either other device sharing(windwos will default to use ipv6 for netwrok sharing) and in this case, ipv6 comunication for matter. (as matter uses ipv6 prefix for aditional data and transit.

1 hour ago, Espressomatic said:

Does your ISP assign you an IPv6 range?

 

My IPv6 is all link-local as my ISP doesn't support IPv6 at all, and I have it turned off at my pfSense router. Unraid hosting HAOS VM is also set to IPv4 only.

 

If ISP doesn't give out a static IPv6 range, there's no point (and can't) set IPv6 static address for the router. If router doesn't have static IPv6, you can't run a local IPv6 DHCP. If there's no IPv6DHCP, there's no point/need to turn on IPv6 on a host. None of this seems to stop or block Matter servers/devices from using link-local addresses and communicating.

 

Matter and Thread working in HA with the single end-device I have at the moment, Aqara Hub feeding U100 lock. Every border router can also be communicated with, 3x Eero and 5x Apple devices (Homepod and AppleTV)

 

 

 

My ISP assign me an IPv6 and my router has DHCPv6 on, every device - including Unraid itself - has an IPv6. Everything runs fine on Unraid 6 so this issue has been introduced with the beta 7. 

3 hours ago, bmartino1 said:

to use a ipv6 dhcp server

 

I keep the DHCP server turned off as well.  I don't need it to assign addresses internally & Matter seems to work fine as it uses mdns anyway.

 

2 hours ago, heyelly said:

this issue has been introduced with the beta 7. 

 

As mentioned in the reddit thread you linked, this was supposed to be addressed in beta3. Weird it wasn't on your system.

Beta 3 release notes:

 

Docker: Add IPV6_FORWARD to rc.docker and set it to ACCEPT instead of DROP

 

In the rc.docker file on Beta3 and Beta4:

 

 # create IPv6 forward accept rule
  if [[ $IPV6_FORWARD == accept ]]; then
    log "creating forward accept rule for IPv6 network"
    ip6tables -P FORWARD ACCEPT
  fi
  log "Network started."

 

The $IPV6_FORWARD variable is set to "accept" earlier in the file.

 

 

Edited November 2, 20241 yr by Espressomatic

15 hours ago, Espressomatic said:

 

 

As mentioned in the reddit thread you linked, this was supposed to be addressed in beta3. Weird it wasn't on your system.

Beta 3 release notes:

 

Docker: Add IPV6_FORWARD to rc.docker and set it to ACCEPT instead of DROP

 

In the rc.docker file on Beta3 and Beta4:

 

 # create IPv6 forward accept rule
  if [[ $IPV6_FORWARD == accept ]]; then
    log "creating forward accept rule for IPv6 network"
    ip6tables -P FORWARD ACCEPT
  fi
  log "Network started."

 

The $IPV6_FORWARD variable is set to "accept" earlier in the file.

 

 

I don’t know but from what I understand I am not the only one

I see what happened now. I have the plugin tips and tweaks instaled which edited the varable for that option.



not sure if autotweaker does simlar:


Otherwise a quick check of system wide settings:
 

sysctl -p

 

The main sysctl Configuration File....

/etc/sysctl.conf

As this is the sysctl config and tips and tweaks touches that to make some changes... (why i didn't experience this with HA currently and in the past...)

you can check your unriad system with similar bash commands to check your settings...

sysctl net.ipv6.conf.all.forwarding

A value of 1 means IPv6 forwarding is enabled, while 0 means it is disabled.

Alternatively, you can check the value directly from the /proc filesystem:
 

cat /proc/sys/net/ipv6/conf/all/forwarding

 

Check iptables Rules for IPv6 (ip6tables)

Since you are modifying ip6tables rules, you can verify if the FORWARD chain policy is set to ACCEPT by running:

ip6tables -L FORWARD -v -n

This command lists the current rules for the FORWARD chain. The policy should show ACCEPT if the script executed properly.

 

Check IPv4 Forwarding Status (if needed)

If you also want to check IPv4 forwarding, you can do so with:
 

sysctl net.ipv4.ip_forward

 

cat /proc/sys/net/ipv4/ip_forward

Thank you for the redit post and the potential fix to offer others putting it here for code convince:

 

  if [[ $IPV6_FORWARD == accept ]]; then
    log "creating forward accept rule for IPv6 network"
    ip6tables -P FORWARD ACCEPT
  fi
  log "Network started."

 

Just want to say that HA does NOT recommend Multiprotocol due to it being a buggy mess and not really compatible with the hardware.

 

Link

1 hour ago, MowMdown said:

Just want to say that HA does NOT recommend Multiprotocol due to it being a buggy mess and not really compatible with the hardware.

 

Link

Those not relate this post, we talking about IPv6 communicate to VM ( Matter ) issue.

 

The link post is about 2.4G radio ( USB radio stick ), if running Thread and Zigbee in same time then will unstable. Pls note BLE / WiFi / Zigbee / Thread all in same 2.4G, so those radio controller can support different protocol once with suitable firmware.

 

An example for easy understand, when IoT device in initial state, it will run in BLE first, after commissioning then it will switch to WiFi mode ( or Thread ).

Edited November 4, 20241 yr by Vr2Io

@Vr2Io,

 

As I mentioned in my previous comment, it was just something I wanted to share with OP as a precaution. Related or not.

 

I know what 2.4GHz is and what devices utilize it. The explanation was unnecessary. I own several running my own custom firmware.

3 hours ago, MowMdown said:

As I mentioned in my previous comment, it was just something I wanted to share with OP as a precaution. Related or not.

 

Your posted link was very specifically about Nabu Casa's own ZBT-1.

 

Sonoff have their own multi-protocol firmware and by all accounts use a different SiLabs chip. But if you read any of the thread it's clear this has nothing to do with the radio but IPv6 specifically, so your comment was kind of sideways here and out of place.

 

 

 

 

Edited November 4, 20241 yr by Espressomatic

7 minutes ago, Espressomatic said:

 

Your posted link was very specifically about Nabu Casa's own ZBT-1. The multi-protocol issue with Nabu Casa's stick has no bearing to other radios and their firmware - definitely nothing to do with OP's Sonoff radio stick.

 

 

It applies to the SONOFF Dongle E as well as it uses the same hardware. These are the only two radios compatible with Multiprotocol firmware. (or any coordinators which use the Silicon Labs  EFR32MG21 radio)

 

Any further discussion I would prefer to take to private messages to not take away from the OP.

Edited November 4, 20241 yr by MowMdown

1 minute ago, MowMdown said:

It applies to the SONOFF Dongle E as well as it uses the same hardware. These are the only two radios compatible with Multiprotocol firmware.

 

You made the reply as I was still editing, sorry.  The Sonoff stick seems to work with multiprotocol from what I've seen, and the SoC is designed for that ability.  But still nothing to do with IPv6 specifically.

 

I'd suggest anyone using USB stick move to PoE radios anyway - configuration and ability to deploy physically anywhere are game-changers. Both for Zigbee or Thread.

Just to make things 100% clear, I am NOT using the multi protocol firmware on my dongle

Quick update on my issue. It was still there with a brand new Unraid 7 beta 4 install.

Added a script with 

ip6tables -A FORWARD -i br0 -o br0 -j ACCEPT

at startup and everything is fixed now.

 

Thanks anyway for your help

On 11/23/2024 at 12:28 AM, heyelly said:

Quick update on my issue. It was still there with a brand new Unraid 7 beta 4 install.

Added a script with 

ip6tables -A FORWARD -i br0 -o br0 -j ACCEPT

at startup and everything is fixed now.

 

Thanks anyway for your help

 

this issue came up while I moved my Home Assistant OS VM from Proxmox to a brand new Unraid 7-rc1 install. My matter devices were all unavailable. This command was the fix.

I've updated to Unraid 7 and i've this issue too, after using this command HA and Matter are OK

ip6tables -A FORWARD -i br0 -o br0 -j ACCEPT

 

But is it a temporary fix or Unraid Team are aware of this issue and give us a fix on the next release ?

I am so glad I found this. I upgraded to 7.0.0 GA from 6.12.14 and the next day I discovered all of my matter devices were broken. I've spent the past few days trying to figure it out, and this post is the fix. My setup is not using br0 because I am using vlan tagging, but putting the appropriate bridge in for that command fixed it. My HA VM immediately showed the appropriate IPV6 address, and I was able to attach a matter device.

 

I hope this gets fixed in the next patch.

On 11/22/2024 at 9:28 PM, heyelly said:

Quick update on my issue. It was still there with a brand new Unraid 7 beta 4 install.

Added a script with 

ip6tables -A FORWARD -i br0 -o br0 -j ACCEPT

at startup and everything is fixed now.

 

Thanks anyway for your help

Thanks just moved from proxmox to unraid for the ease of use and banging my head on a wall wondering why thread wouldnt work i enabled ipv6 and ipv4 on unraid hoping that was the fix but wasnt then found this thanks.

 

hope the unraid team fix it properly. How have you set the script to run at start up ive used user script plugin and set on array start is that ok?