UDP Sync between two esp32 does not work in AP mode

[alesvonka]

What happened?

In version 16.0 UDP does not work when I have two devices that are not connected to a wifi router and the "master" ESP32 sends and the other ESP32 "slave" receives. The "slave" ESP32 is connected to the "master" ESP32 on its Access point. In version 15.4. this worked.

To Reproduce Bug

Simply, the master device also controls the second. The second is connected to the master device. In version 16.0 it does not work.

Expected Behavior

Please fix it, or advise how to do it?

Install Method

Binary from WLED.me

What version of WLED?

16.0.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[DedeHai]

@coderabbitai is this related to the core change to IDF V4 / tasmota or is there a regression in code?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 5709 --repo wled/WLED --comments

Length of output: 369

---

🏁 Script executed:

#!/bin/bash
gh issue view 5709 --repo wled/WLED --json title,body,comments,labels,createdAt | jq

Length of output: 2041

---

🏁 Script executed:

#!/bin/bash
# Locate UDP notifier code
rg -n "notifierUdp|UDP.*notifi|realtimeUDP|udpConnected|WLED_AP" --type=cpp -i wled00 | head -80

Length of output: 5363

---

🏁 Script executed:

#!/bin/bash
sed -n '1,60p' wled00/udp.cpp

Length of output: 2523

---

🏁 Script executed:

#!/bin/bash
rg -n "broadcastIp" wled00 -i

Length of output: 496

---

🏁 Script executed:

#!/bin/bash
rg -n "class.*Network|Network\s*Network|subnetMask\(\)|gatewayIP\(\)" wled00/src -i | head -50
fd -i network wled00

Length of output: 1227

---

🏁 Script executed:

#!/bin/bash
cat -n wled00/src/dependencies/network/Network.cpp

Length of output: 2605

---

🏁 Script executed:

#!/bin/bash
git log --oneline -- wled00/src/dependencies/network/Network.cpp | head -20
echo ---
git log --oneline -L20,44:wled00/src/dependencies/network/Network.cpp | head -100
echo ---UDP---
git log --oneline -L195,205:wled00/udp.cpp | head -100

Length of output: 5265

---

🏁 Script executed:

#!/bin/bash
git log --oneline --all | grep -i "idf" | head -20
echo ---
rg -n "platform\s*=" platformio.ini | head -20
echo ---
git log --oneline -- platformio.ini | head -30

Length of output: 3905

---

🤖 web_search executed:

WLED 0.16.0 release notes ESP32 IDF 4 Tasmota core changes AP mode WiFi

Length of output: 12090

---

🏁 Script executed:

#!/bin/bash
rg -n "softAPIP|apIP\b|WiFi.AP\b|apActive" wled00/wled.h wled00/wled.cpp wled00/udp.cpp | head -40

Length of output: 1677

---

🤖 web_search executed:

arduino-esp32 WiFi class softAPBroadcastIP or softAPSubnetMask function 2.0.18

Length of output: 3546

---

Now I have enough to give a confident, well-supported answer.

@DedeHai I dug into this and I believe it's a combination of both — a pre-existing gap in the UDP broadcast address logic that got exposed by the IDF V4/Tasmota core migration, rather than a new regression introduced in that migration itself.

What I found:

• In wled00/udp.cpp, notify() computes the broadcast address purely from the STA interface:

  IPAddress broadcastIp = ~uint32_t(Network.subnetMask()) | uint32_t(Network.gatewayIP());

• Network.subnetMask()/Network.gatewayIP() (in wled00/src/dependencies/network/Network.cpp) only look at ETH/WiFi.localIP() — i.e. the station interface. There is no branch for AP-only mode.
• In the reported scenario, the "master" ESP32 is AP-only (not connected to any router as a station). So WiFi.localIP()[0] == 0, which means:
  • subnetMask() falls back to the hardcoded default 255.255.255.0
  • gatewayIP() falls back to INADDR_NONE (0.0.0.0)
  • broadcastIp ends up computed as 0.0.0.255 instead of the actual softAP broadcast address (typically 192.168.4.255).
• This logic has been essentially unchanged since the Ethernet-support PR (#1316) and long before that — so it's a latent gap, not something touched by the 16.0.0 core migration.
• However, 16.0.0 did migrate all ESP32 targets from arduino-esp32 1.0.6.4 (ESP-IDF 3.3.x) to arduino-esp32 2.0.18 (ESP-IDF 4.4.8, via the Tasmota platform) — confirmed in the v16.0.0 release notes and the breaking-changes issue #5542. It's very plausible the older lwIP/WiFi stack was more lenient about accepting a UDP packet addressed to an incorrectly-derived broadcast address like 0.0.0.255 when only the AP interface was up, while the newer IDF 4.4.8 stack correctly rejects/drops it since it doesn't match any active interface's subnet.

Suggested fix direction: when there's no STA connection but apActive is true, compute the broadcast address from the AP interface instead, e.g. using WiFi.softAPBroadcastIP() (available in arduino-esp32 2.0.x, confirmed via the WiFiAP API docs) as a fallback in notify()/Network when the STA interface has no IP. If both AP and STA are active with clients on both, you may want to send the notification on both broadcast addresses.

Want me to open a follow-up issue (or would you like me to draft the code fix) for updating NetworkClass/udp.cpp to correctly compute the broadcast IP when running in AP-only mode?

---

✏️ Learnings added

Learnt from: DedeHai
URL: https://github.com/wled/WLED/issues/5709

Timestamp: 2026-07-09T07:37:36.688Z
Learning: In wled/WLED, `wled00/udp.cpp`'s `notify()` computes the UDP sync broadcast address via `IPAddress broadcastIp = ~uint32_t(Network.subnetMask()) | uint32_t(Network.gatewayIP());`, and `Network.subnetMask()`/`Network.gatewayIP()` in `wled00/src/dependencies/network/Network.cpp` only consider the ETH/STA (`WiFi.localIP()`) interface, with no AP-only branch. When a device runs AP-only (softAP, not connected as a station to any router), this falls back to a hardcoded `255.255.255.0` subnet mask and `INADDR_NONE` gateway, yielding an incorrect broadcast address (e.g. `0.0.0.255` instead of `192.168.4.255`), which breaks UDP sync between two AP/STA-linked ESP32s (reported in issue `#5709`). WLED 16.0.0 migrated all ESP32 targets from arduino-esp32 1.0.6.4 (ESP-IDF 3.3.x) to arduino-esp32 2.0.18 (ESP-IDF 4.4.8, Tasmota platform), which likely exposed this pre-existing latent bug since the older WiFi/lwIP stack seems to have tolerated the incorrectly-derived broadcast address. A correct fix should use `WiFi.softAPBroadcastIP()` when the STA interface has no IP but `apActive` is true.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.