DDP input: reject packets with unsupported data type or non-display destination by Copilot · Pull Request #5390 · wled/WLED

Copilot · 2026-02-21T04:39:31Z

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: >

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.

… data type Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

DedeHai · 2026-02-21T08:28:22Z

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

Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

Copilot · 2026-02-21T08:32:53Z

@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.

_codeql_detected_source_root

…nd add to .gitignore Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

softhack007 · 2026-02-21T13:07:47Z

wled00/e131.cpp

  int lastPushSeq = e131LastSequenceNumber[0];

+  // reject unsupported data types (only RGB and RGBW are supported)
+  if (p->dataType != DDP_TYPE_RGB24 && p->dataType != DDP_TYPE_RGBW32) return;


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

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

softhack007 · 2026-03-03T14:40:34Z

wled00/e131.cpp

+  // reject status and config packets (not implemented)
+  if (p->destination == DDP_ID_STATUS || p->destination == DDP_ID_CONFIG) return;
+
  //reject late packets belonging to previous frame (assuming 4 packets max. before push)


@DedeHai maybe also check if this assumption "max 4 packets per push" still makes sense.

Not sure how many LEDs fit into one packet - but considering maybe 4 packets * 512 LEDs as the absolute max content per frame doesn't sound right to me - we can support more than 2048 LEDs for example with HUB75.

needs investigation. I have pushed 64x64 over websocket no problem - not sure how big one WS packet is but code comments suggest its about 500 LEDs worth.

I've created an issue ticket so we can come back to this question later.

softhack007

Please check if addition legacy "datatypes" and "destination" should be allowed (see my comment below).

softhack007 · 2026-03-09T19:24:46Z

wled00/e131.cpp

  int lastPushSeq = e131LastSequenceNumber[0];

+  // reject unsupported data types (only RGB and RGBW are supported)
+  if (p->dataType != DDP_TYPE_RGB24 && p->dataType != DDP_TYPE_RGBW32) return;


If I read the DDP specs correctly, datatype can also be 0 = not used / undefined.
Similar for destination ID 255= all devices. I think we should allow these special values, too.

http://www.3waylabs.com/ddp/

Initial plan

635a9e0

Copilot AI assigned Copilot and DedeHai Feb 21, 2026

Copilot started work on behalf of DedeHai February 21, 2026 04:39 View session

Fix: reject invalid DDP packets with wrong destination or unsupported…

f884deb

… data type Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix issue of all LEDs switching off on invalid DDP messages~~ DDP input: reject packets with unsupported data type or non-display destination Feb 21, 2026

Copilot AI requested a review from DedeHai February 21, 2026 04:45

Copilot finished work on behalf of DedeHai February 21, 2026 04:45

Copilot started work on behalf of DedeHai February 21, 2026 08:28 View session

Move remaining DDP defines from udp.cpp to ESPAsyncE131.h

b1757c3

Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

Copilot finished work on behalf of DedeHai February 21, 2026 08:33

DedeHai reviewed Feb 21, 2026

View reviewed changes

_codeql_detected_source_root Outdated Show resolved Hide resolved

Copilot started work on behalf of DedeHai February 21, 2026 09:17 View session

Remove accidentally committed _codeql_detected_source_root artifact a…

d2df7a4

…nd add to .gitignore Co-authored-by: DedeHai <6280424+DedeHai@users.noreply.github.com>

Copilot AI requested a review from DedeHai February 21, 2026 09:18

Copilot finished work on behalf of DedeHai February 21, 2026 09:18

cleanup AI slop

079dbec

DedeHai marked this pull request as ready for review February 21, 2026 09:30

missed a spot

e02c126

DedeHai approved these changes Feb 21, 2026

View reviewed changes

softhack007 reviewed Feb 21, 2026

View reviewed changes

softhack007 reviewed Mar 3, 2026

View reviewed changes

softhack007 modified the milestone: 16.0.0 beta Mar 9, 2026

softhack007 mentioned this pull request Mar 9, 2026

DDP "skip out-of sequence packets" assumes that 5 packets are enough for a complete frame #5412

Open

softhack007 requested changes Mar 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

DDP input: reject packets with unsupported data type or non-display destination#5390
Copilot wants to merge 6 commits intomainfrom
copilot/fix-leds-for-invalid-ddp

Copilot AI commented Feb 21, 2026 •

edited

Loading

Uh oh!

DedeHai commented Feb 21, 2026

Uh oh!

Copilot AI commented Feb 21, 2026

Uh oh!

Uh oh!

softhack007 Feb 21, 2026

Uh oh!

DedeHai Feb 21, 2026

Uh oh!

softhack007 Mar 3, 2026

Uh oh!

DedeHai Mar 3, 2026

Uh oh!

softhack007 Mar 9, 2026

Uh oh!

softhack007 left a comment •

edited

Loading

Uh oh!

softhack007 Mar 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Copilot AI commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

To Reproduce Bug

Expected Behavior

Install Method

What version of WLED?

Which microcontroller/board are you seeing the problem on?

Relevant log/trace output

Anything else?

Code of Conduct

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

Uh oh!

DedeHai commented Feb 21, 2026

Uh oh!

Copilot AI commented Feb 21, 2026

Uh oh!

Uh oh!

softhack007 Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

DedeHai Feb 21, 2026

Choose a reason for hiding this comment

Uh oh!

softhack007 Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

DedeHai Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

softhack007 Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

softhack007 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

softhack007 Mar 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Feb 21, 2026 •

edited

Loading

softhack007 left a comment •

edited

Loading