UDP Sound sync receive stops after 260 seconds (TP-Link Deco router)

[TechFreak93]

What happened?

The UDP Sound sync receive stop after 260 seconds with a TP-Link Deco Router.
ESP32

To Reproduce Bug

The Sound Receive stop after 260 seconds with a TP-Link Deco Router.
When in the Info Box turn off and on the Sound Reaktive it works again for 260 seconds

Expected Behavior

Pleas Fix it

Install Method

Binary from WLED.me

What version of WLED?

All

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

what versions did you try? if it happens on any version, this may be a router setting issue. any debug output info on this?
also: using HA? if yes, does it work if you disable it?

[TechFreak93]

i'm test Vesion v0.14.4 and v0.15.0.

Yes at my Network running HomeAssistant, but in a clean new Network only for WLED is the same problem.
The TP-Link Deco series have not a lot af Settings :( , NAT forwarding does not solve the problem.
It works great with Fritzbox or Netgear, but on TP-Link Deco works only for 260 seconds!
Where can I get debug output?

[DedeHai]

for debug output you need to upload a debug build and monitor the serial output.
you can also check the "Free heap" in the info to see if it shrinks. WLED (or rather the ESP core wifi library) does not like it if something in the network sends too many requests, it will stop working. if your router does some kind of polling, that may be it.

[TechFreak93]

Is there a guide for this?
The free heap is always at 160‐170kb see Screenshots

[softhack007]

@TechFreak93 it might be that your router does not handle multicast groups well. I used to have a german Telekom "speedport" router and always had connections cut very quickly, together with router log messages like "intercepted a udp syn flood attack".

We never found out how to solve this - from WLED point of view we simply open the multicast channel, and somehow no more multicast packages are arriving (sound sync idle).

There is some technical info here https://github.com/atuline/WLED/wiki/UDP-Sound-Sync#what-else-

But unfortunately I can only say "sound sync does not work with all routers". In fact a workaround could be to use DDP to tranmit the led effect to other esp32 boards, instead of sharing the audio data. Esp32 has enough power to run several effects in parallel (use segments) and send led data to a handful of "clients".

[netmindz]

Yeah as mentioned already, we can't fix an issue with broken UDP multicast support, you need to get assistance from the maker or support community of that hardware.

I have an experimental branch of WLED that uses ESP-NOW rather than multicast, but as it didn't deliver any significantly lower latency I didn't continue this into a full feature, but if you are familiar with building from source please feel free to try that branch and get back to me with your feedback.

Otherwise you just need to fix your WiFi. It's not about needing ports to be opened or forwarded, just proper implementation of multicast and no firewall feature that is trying to limit usage of multicast.

[TechFreak93]

I found this for the TP-Link 260 seconds problem, but i cant fix this on the Roter, i have no Settings for this.

[TechFreak93]

curl -X POST "http://10.0.0.122/json/state" -d '{"AudioReactive":{"enabled":false}' -H "Content-Type: application/json"

curl -X POST "http://10.0.0.122/json/state" -d '{"AudioReactive":{"enabled":true}}' -H "Content-Type: application/json"

Now i'm send this command every 259 sec from Home Assistant to restore the timer, so it work's but this is not a good solution.

Maybe you could add a restore timer to the firmware in the future versions to avoid such problems.
Best regards.

[netmindz]

That snippet is for ipv6 and we are using ipv4, but I'm guessing they might also have very aggressive cleanup of multicast groups for v4 as well

[netmindz]

https://stackoverflow.com/questions/76867834/how-to-avoid-multicast-timeout-due-to-igmp-snooping

[softhack007]

https://stackoverflow.com/questions/76867834/how-to-avoid-multicast-timeout-due-to-igmp-snooping
The router needs to periodically send IGMP query messages. Having a device that joins the group for a while, then drops out, is exactly the behavior you get when there is no device sending the query messages. Devices send an initial membership message when they join the group, so everything works for a while, but then get expired out of the group because they never send another one, at which point they appear to stop working. Not all routers implement IGMP queriers, and it might be a feature you have to explicitly enable.

I guess the best way to go if I wanted to keep multicast would have been to make the device send free membership message without waiting for queries.
Yes. That's what linux appears to be doing too.

So it looks like something with IGMP queries ... Unfortunately, igmp is not exposed on the WiFiUDP class interface; we only have beginMulticast() and beginMulticastPacket(). Everything else is inside the framework (=not under WLED control) 🤷 .

[softhack007]

Maybe you could add a restore timer to the firmware in the future versions to avoid such problems.

This will periodically switch the usermod OFF and back ON. I think its not a general solution because each off/on will reset the audio processing task (mic sampling and FFT) -> Local effects will switch to simulated sound while AR is off --> leads to randomly flashing colors because AR and soundSim are not synchronized (and not designed to work "in sync").