Repository navigation
Conversation
parsePacket located the frame end with buffer.indexOf('0000AA55'), then
'00009966', searched from byte 0. A sequence number of 0x0000AA55, or
0x00009966 on protocol 3.5, holds those bytes at offset 4 or 6, so the
search returns the sequence field, the buffer is cut to 8 or 10 bytes,
and the next readUInt32BE throws ERR_OUT_OF_RANGE ("must be >= 0 and
<= 6. Received 8" on 3.5). Every device whose counter passes those
values drops that frame.
The frame length now comes from the header: 16 + length for 55AA
frames, 22 + length for 6699 frames, matching what the encoders write.
Bytes past it go to leftover as before; a buffer shorter than it throws
"Packet missing payload".
Tests cover 3.1, 3.3, 3.4 and 3.5 with both sequence numbers, two
packets back to back. Five of the eight fail on master.
Claude-Session: https://claude.ai/code/session_01Mi7yrmdxpownpnTsMGLHJW
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
parsePacketsearched for the suffix from byte 0. The sequence field sits inside that range, so a sequence number of0x0000AA55, or0x00009966on 3.5, produces a match there. The buffer is cut to 8 or 10 bytes, and the nextreadUInt32BEthrowsERR_OUT_OF_RANGE. Every device whose counter reaches those values drops that frame.The lengths match what
_encodePre34,_encode34and_encode35write.Evidence
Found on a 3.5 light,
Version: 3.5:New tests in
test/parser.js: for protocols 3.1, 3.3, 3.4 and 3.5 and sequence numbers0xaa55and0x9966, two packets back to back parse as 2 packets, each with its sequence number, command and payload.ERR_OUT_OF_RANGE:0xaa55on all four protocols, and0x9966on 3.5.After:
npm teston Node 22.23.2: 47 tests passed.npm run lint: 0 errors, the same 2 warnings as master; theparsePacketcomplexity warning moves from 31 to 32.The patched build has run on a Homey Pro with 3.3 and 3.5 devices, and the light reports its state as before.
Merge Danger
Door: two-way
Blast Radius: parsing
Every received frame now goes through the length field. A device whose length field disagrees with its actual frame size used to parse when the suffix sat at the end. With this change it throws "Packet missing payload", or its trailing bytes go to
leftover. The encoders and the existing payload-size checks already depend on that field.https://claude.ai/code/session_01Mi7yrmdxpownpnTsMGLHJW