Non-status DYM responses are accepted without validating packet length or trailer

[Bjorkan]

TL;DR

Most mower responses are documented as complete 22-byte packets ending in 16 06 01, but the parser accepts much shorter packets. A partial or wrong packet can therefore be treated as a valid PIN, settings, multi-area, or schedule response.

Problem

Status response 0x80 is validated strictly: it must be exactly 22 bytes and contain the notification trailer. Other known DYM responses are parsed using only small minimum lengths and do not require the trailer.

Relevant code:

• Status is checked for exact length and trailer
• Auth/PIN is accepted at only 8 bytes
• PIN-change, multi-area, and mower-settings responses use incomplete minimum lengths
• Work-time responses are accepted at 19 bytes

The repository's protocol notes describe these inbound DYM responses as 22-byte notification packets with the 16 06 01 trailer.

Why it happens

The parser validates only enough bytes to access the fields it currently uses. That prevents an index error, but it does not validate that the notification is a complete protocol frame.

For example, this eight-byte value is currently accepted as a valid auth response even though it has no reserved bytes or trailer:

44 59 4d 8c 01 02 03 04

It is parsed as PIN 1234.

Similarly, a 12-byte 0x8d or 0x89 packet is accepted as complete multi-area or mower-settings data.

Current behavior

• Incomplete known response frames can be selected by _wait_for_response() because their cmd matches.
• Authentication can succeed from a packet that is not a complete captured DYM response.
• Settings values can be produced from malformed packets.
• Decimal distance chunks, percentages, booleans, time fields, and duration fields are not range-checked on input.
• An invalid known command is returned as a generic message rather than rejected.

Expected behavior

For every known DYM response format, validate the framing before decoding fields:

• exact expected packet length;
• DYM prefix;
• expected response command;
• 16 06 01 notification trailer;
• valid field ranges where the protocol has confirmed limits.

Malformed known packets should return None or a typed parse error, and they must not satisfy a request waiting for that command.

Unknown commands can still be exposed for raw reverse-engineering, but should be clearly marked as unknown/raw rather than partially treated as valid typed data.

Impact

This can cause false authentication, incorrect settings, or misleading verification results. It is particularly harmful when a request is already unstable because a matching malformed packet ends the wait early instead of allowing the complete response to arrive.

Suggested direction

Create a small frame validator shared by the known DYM response parsers. Keep raw packet observability separate from typed decoding, for example:

{
    "cmd": 0x8D,
    "raw_hex": "...",
    "valid_frame": False,
    "parse_error": "expected 22 bytes and trailer 160601",
}

Typed callers should only accept valid_frame=True.

Acceptance criteria

• Truncated 0x8c, 0x86, 0x8d, 0x89, 0x84, and 0x85 packets are rejected.
• A packet with the wrong trailer is rejected for typed parsing.
• Invalid hours, minutes, tenths, decimal chunks, percentages, and booleans are not silently decoded as valid settings.
• _wait_for_response() continues waiting after a malformed packet with the expected command byte.
• Full captured 22-byte test vectors continue to parse.