DDP input: reject packets with unsupported data type or non-display destination

[Copilot]

• Understand the DDP packet handling code in e131.cpp and udp.cpp
• Move all DDP defines to ESPAsyncE131.h (including DDP_ID_*, DDP_FLAGS1_*, DDP_HEADER_LEN, DDP_SYNCPACKET_LEN, DDP_CHANNELS_PER_PACKET)
• Remove all DDP #defines from udp.cpp
• Add destination validation in handleDDPPacket: reject DDP_ID_STATUS and DDP_ID_CONFIG packets
• Add data type validation in handleDDPPacket: reject packets not of type DDP_TYPE_RGB24 or DDP_TYPE_RGBW32
• Remove accidentally committed _codeql_detected_source_root artifact file and add to .gitignore
• All 16 tests pass (npm test)
• Hardware build succeeds (pio run -e esp32dev)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>when certain invalid DDP messages are received, all LEDs switched off</issue_title>
<issue_description>### What happened?

Not very critical, but I noticed that WLED is sensitive for invalid/corrupted DDP packets.

To Reproduce Bug

e.g.:

21:03:53.226765 IP (tos 0x0, ttl 255, id 293, offset 0, flags [none], proto UDP (17), length 124)
    10.208.2.7.4048 > 10.208.3.255.4048: UDP, length 96
    0x0000:  4500 007c 0125 0000 ff11 9ea6 0ad0 0207  E..|.%..........
    0x0010:  0ad0 03ff 0fd0 0fd0 0068 1133 4108 0bfb  .........h.3A...
    0x0020:  0000 0000 0056 7b22 7374 6174 7573 223a  .....V{"status":
    0x0030:  207b 2022 6d61 6e22 3a20 2277 7777 2e6b  .{."man":."www.k
    0x0040:  6f6d 7075 7469 6c6f 2e6e 6c22 2c20 226d  omputilo.nl",."m
    0x0050:  6f64 223a 2022 4c69 6768 7462 6f78 2044  od":."Lightbox.D
    0x0060:  4450 2073 6572 7665 7222 2c20 2276 6572  DP.server",."ver
    0x0070:  223a 2022 302e 3122 207d 207d            ":."0.1".}.}

test.pcap.zip

Expected Behavior

Ignore invalid packets

Install Method

Binary from WLED.me

What version of WLED?

any version

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

I tried running a `WLED_DEBUG` version but that doesn't give extra output in the console.

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct</issue_description>

<agent_instructions>DDP incoming packets should be checked for:

packet format (RGB or RGBW) -> reject anything else
destination: reject DDP_ID_STATUS and DDP_ID_CONFIG as not implemented, these two defines already exist in code.
implement only these improvements, make no other changes to code.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@DedeHai @coderabbitai please elaborate if this is a bug or a feature @DedeHai @coderabbitai there is a binary code example given. please trace through the code what happens if such a data packet is received through UDP, state function calls and meaning of the data bytes and how it arrives at turning off LEDs @softhack007 > **Wrong Destination**: Packet has `destination = 0xFB` (STATUS), not `0x01` (DISPLAY) > > * **No validation** - code doesn't check destination field > * Status packets should contain configuration/metadata, not LED data

@coderabbitai: I'm not sure about the DDP specification:

• is the "destination" field part of each DDP packet?
• Does our WLED "Network output" DDP format properly set data type and destination?

@netmindz > [@coderabbitai](https://github.com/coderabbitai) here's my thought: >

3. there is nothing in the header structure that defines it a DDP header (you can't attach any bit pattern to a meaningful data as WLED ignores (intentionally) most of the data, i.e. you can't use DDP_ID_DISPLAY to validate if the packet is destined for display as WLED doesn't support distinguishing displays)

I do not agree with this logic. DDP had a packet format that includes a header. If that header has a field which is the destination and if that destination had certain values that indicate this is not a display, but for things like status, we would never want to try and interpret status data as LED display output. So we need to respect that destination, even though WLED only supports a single display (we don't try and map display to segment)

Please correct your learning @coderabbitai</comment_new>
<comment_new>@DedeHai
so to sum up:
DDP incoming packets should be checked for:

• packet format (RGB or RGBW) -> reject anything else
• destination: reject DDP_ID_STATUS and DDP_ID_CONFIG as not implemented, these two defines already exist in code.</comment_new>
  <comment_new>@softhack007

so to sum up: DDP incoming packets should be checked for:

• packet format (RGB or RGBW) -> reject anything else
• destination: reject DDP_ID_STATUS and DDP_ID_CONFIG as not implemented, these two defines already exist in code.

Yep, I agree, too.
If the acceptable format and destination fields are just a few values, there is no performance problem with checking these once per packet. Especially if we can filter out any non-LEDs junk with a few lines of code.</comment_new>

• Fixes when certain invalid DDP messages are received, all LEDs switched off #5380

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[DedeHai]

@copilot move all DDP defines into ESPAsyncE131.h so all of them are in one place, even the ones still in udp.cpp

[Copilot]

@copilot move all DDP defines into ESPAsyncE131.h so all of them are in one place, even the ones still in udp.cpp

Done in b1757c3. All remaining DDP defines (DDP_HEADER_LEN, DDP_SYNCPACKET_LEN, DDP_FLAGS1_VER*, DDP_FLAGS1_PUSH/QUERY/REPLY/STORAGE/TIME, DDP_CHANNELS_PER_PACKET) have been moved from udp.cpp to ESPAsyncE131.h, so all DDP defines are now in one place.

[DedeHai]

@copilot remove this artifact file

[Copilot]

Removed in d2df7a4. The symlink has been deleted and _codeql_detected_source_root added to .gitignore to prevent it from reappearing.

[softhack007]

@DedeHai this is the core change, right?
Maybe its worth to make a backport to 0.15.4 with just this sanity check

[DedeHai]

that plus the next line, the rest was just moving the defines (and renaming)