observed: unknown control bytes

[lawther]

My device saw the following (unknown) packet:

02 00 81 FF FF 00 00 13 0B 9F 03 

(shown in the screenshot in #44)

It checks out, but only if we allow the Control Bytes to be 00 00 instead of 08 00

• 02 = START
• 00 81 = VX 11S v3 Salt Chlorinator
• FF FF = Broadcast
• 00 00 = Control Bytes (0x00 0x00 instead of 0x80 0x00 )
• 13 = Command 0x13 (undocumented)
• 0B = Total packet length (11 bytes)
• 9F = Checksum ( 0x02 + 0x00 + 0x81 + 0xFF + 0xFF + 0x00 + 0x00 + 0x13 + 0x0B = 0x29F → 0x9F )
• 03 = END

Given the checksum checks out, it seems that this packet was deliberately constructed, and not noise. Timing wise, it was sent around the time my touch screen's timer turns the pump on - so this might be some sort of 'hello' ping upon power-on of the chlorinator?

I've only seen this packet once, but if I see it again, we might have to relax the 'control bytes = 80 00' rule in tcp_bridge.c.

[zagnuts]

Interesting. I am waiting for some spare time when I can actually look at contributing to the code - anyhow, my thought was to also review the decode_message function. I think it currently expects all packets to have the same structure, but this is an example where a packet is slightly different but is indeed not noise/corrupted. I'm seeing some packets that appear to be being re-broadcast by the gas heater but the whole packet is being classed as an error because it basically has an extra header. My thought was to use a sliding window to loop through the received buffer looking for 0x02, extract the expected length from byte 8 of that window, and then test if it forms a mathematically sound message.

[marklynch]

@lawther yep, if you see that again would be more than happy to relax that check, particularly if we can figure out what that message is.

[lawther]

Yep, I saw it again this morning, right around when the touch screen controller activated channel 1 (my filter/pump) from a timer.

I'll try and capture a trace of it happening so I can see the surrounding events.

[marklynch]

Cool the surrounding context will be helpful.

And I think we should only add 00 00 rather than opening it up wider at this point. Thinking behind this is I'd rather have it error for each new one until we understand exactly what the bytes mean.

[lawther]

And I think we should only add 00 00 rather than opening it up wider at this point. Thinking behind this is I'd rather have it error for each new one until we understand exactly what the bytes mean.

Totally agree.

[lawther]

So, I did some more digging. Turns out 00 00 control bytes are more common.

Chlorinator Repro

Firstly - I can easily repro the chlorinator packet by turning it off and on again. It sends it upon startup.

• 22:17:32.619 - I turned Filter Pump to Off (inactive) using MQTT
• 22:18:00.284 - I turned Filter Pump to Auto using MQTT
• 22:18:08.769 - First comms from Chlorinator: sends 00 00 control byte packet, cmd 0x13
• 22:18:08.775) - Chlorinator broadcasts status: 0x00
• 22:18:08.871 - Chlorinator broadcasts Firmware version - 5.2

More Examples

I went looking back through old log captures. If you look for "TCP_BRIDGE: Invalid control bytes: 00 00" I found a few more:

• W (02:55:10.588) TCP_BRIDGE: Invalid control bytes: 00 00 (expected 80 00), data: 02 00 74 FF FF 00 00 15 0B 94 03 02 00 74 FF , discarding start byte
• W (02:56:37.168) TCP_BRIDGE: Invalid control bytes: 00 00 (expected 80 00), data: 02 00 62 FF FF 00 00 15 0B 82 03 02 00 50 FF FF 80 00 14 0D F1 00 00 03 , discarding start byte
• W (02:56:37.958) TCP_BRIDGE: Invalid control bytes: 00 00 (expected 80 00), data: 02 00 50 00 7F 00 00 1A 0B F6 03 02 00 50 00 7F 80 00 41 0E A0 01 01 02 03 , discarding start byte

We can reconstruct these:

02 00 74 FF FF 00 00 15 0B 94 03 
      •  02  — Start byte
      •  00 74  — Source: ICI Gas Heater
      •  FF FF  — Destination: Broadcast
      •  00 00  — Control bytes (rejected)
      •  15  — Command
      •  0B  — Length (11)
      •  94  — Header Checksum (valid:  02+00+74+FF+FF+00+00+15+0B = 0x294 & 0xFF = 0x94 )
      •  03  — End byte

 02 00 62 FF FF 00 00 15 0B 82 03 
      •  02  — Start byte
      •  00 62  — Source: Connect 8/10
      •  FF FF  — Destination: Broadcast
      •  00 00  — Control bytes (rejected)
      •  15  — Command
      •  0B  — Length (11)
      •  82  — Header Checksum (valid:  02+00+62+FF+FF+00+00+15+0B = 0x282 & 0xFF = 0x82 )
      •  03  — End byte

 02 00 50 00 7F 00 00 1A 0B F6 03 
      •  02  — Start byte
      •  00 50  — Source: Touch Screen
      •  00 7F  — Destination: Internal Temp Module
      •  00 00  — Control bytes (rejected)
      •  1A  — Command
      •  0B  — Length (11)
      •  F6  — Header Checksum (valid:  02+00+50+00+7F+00+00+1A+0B = 0xF6 )
      •  03  — End byte

This little sequence was from around the time I was testing my heater and switching the pool into spa mode (there are some valve messages around that time).

Note that:

• These are all hitherto unseen CMDs.
• Length is always 11, no data payload

Other control bytes seen

I got a bit excited when I found

W (01:38:23.691) TCP_BRIDGE: Invalid control bytes: 00 A0 (expected 80 00), data: 02 00 A0 FF 02 00 A0 FF FF 80 00 3B 0E 69 04 65 69 03 , discarding start byte

I found some dozens of other 'invalid control bytes'. However in all of these cases, the frame was malformed.

Conclusion

00 00 is a valid control byte sequence.

As for what it means, my best guess is that 80 00 is 'data' and 00 00 is 'control'/'discovery'.

[marklynch]

Ok that's great you've found more and agree this looks like a "discovery/announcement" message given no data on it.

Will be nice to reduce the number of unknowns.