messageClass documentation and Dissector data types

[twistedddx]

Would this be slightly more clear in the docs than is currently there?
I wasn't sure if 65 and 66 appear anywhere after the initial setup. I haven't seen them elsewhere.

Message class
The message class determines the length of the header. The following classes and header lengths are known.
0x6514: "legacy" client initialize request (20 bytes)
0x6614: "modern" device initialize reply (20 bytes)
0x6414: "modern" client request (24 bytes)
0x0000: "modern" device reply (24 bytes)

Unrelated I also noticed wireshark showing a message handle with negative numbers.
I think most all those data types make more sense as unsigned. eg message handle should be uint8.
From what I see every one of the dissectors types could be changed to unsigned. Things like size etc makes no sense as a negative.
It is the UDP area I wasn't certain of but I think all the ID's etc also makes more sense as only positive numbers.

[QuantumEntangledAndy]

In the UDP I think the connection id should remain as signed because of what the reolink servers expect.

Recently when getting UDP to work I had to connect to the reolink servers and upload an XML which contained the connection id. Then later on I would retrieve that same uploaded data and find that it had been converted to signed. (XML is text so there print seems to be as signed). This caused my program to crash as our deserialiser expected unsigned.

P.s. reolink servers are just sending UDP packets no extra encryption or anything....

[twistedddx]

Yea I had a vague memory of reading something you wrote about negative ID numbers for UDP.
So besides the ID's the rest could be unsigned?

[twistedddx]

There hasn't been new firmware since the AES encryption was worked out.
Reolink had been really excited about the release of AES. Promoting it in forum posts.

I wonder if everyone got fired or if they are back to the drawing board.

[QuantumEntangledAndy]

Well even their AES key is just noonce and password md5 hashed together.

Given that the noonce is in bcencrypt (might as well be plain text) during the hand shake and the password is transmissted MD5 hashed with the noonce prior to the Aes part the password is just as easy to break as it was before.

The only difference is you now need to break the md5 hash first were before you didn't even need to bother.

Anyways maybe one day they'll do it right.

[QuantumEntangledAndy]

Yeah everything else is better represented as a unsigned I think.

If you are going to change the dissector can you change the UDP one I just made in my udp_proto branch. I just made some changes so that it will pass luacheck and added an action for it in the github actions.