v07 UnicodeDecodeError invalid continuation byte

[pbjfarm]

My JPP docker setup stopped working a couple weeks ago. It seems to be related to a character in the JuiceBox ID that the box is sending...although I haven't changed anything.

This appears to be different than the other issue mentioning UnicodeDecodeError - as that issue was using what appeared to be an encrypted version of the protocol...mine is still v07.

juicepassproxy  | 2024-11-09 18:58:10  DEBUG     [juicebox_mitm] Starting JuiceboxMITM Loop
juicepassproxy  | 2024-11-09 18:58:22  DEBUG     [juicebox_mqtthandler] From JuiceBox: b'0\xc300081509281447541218021146:v07,s0,u6623,V2479,L20710648,S1,T25,M24,m32,t30,i50,e0,f6002,X0,Y0!UF0:\n'
juicepassproxy  | 2024-11-09 18:58:22  ERROR     [__main__] A JuicePass Proxy task failed: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in position 1: invalid continuation byte
juicepassproxy  | 2024-11-09 18:58:30  DEBUG     [__main__] jpp_task_list: [<Task finished name='mqtt_handler' coro=<JuiceboxMQTTHandler.start() done, defined at /juicepassproxy/juicebox_mqtthandler.py:320> result=None>, <Task finished name='mitm_handler' coro=<JuiceboxMITM.start() done, defined at /juicepassproxy/juicebox_mitm.py:49> exception=UnicodeDecodeError('utf-8', b'0\xc300081509281447541218021146:v07,s0,u6623,V2479,L20710648,S1,T25,M24,m32,t30,i50,e0,f6002,X0,Y0!UF0:\n', 1, 2, 'invalid continuation byte')>]

Startup just loops until finally erroring out.

[ivanfmartinez]

@pbjfarm I think that with my branch the container will not stop, can you test ?

https://github.com/JuiceRescue/juicepassproxy/pull/69

If is just sometimes that it send wrong messages we can just skip, but if your device keeps sending that, maybe we need to get a way to ignore that unexpected character

[pbjfarm]

@ivanfmartinez I have your branch running now. It's producing the same error, but is continuing with the Starting JuiceboxMITM Loop...and it did finally exit with:

juicepassproxy  | 2024-11-10 21:33:21  ERROR     [aiorun] Unhandled exception; stopping loop: 'Task exception was never retrieved'

The weird thing is that the problem ID in the message doesn't quite match my JuiceBox ID.

Sent:  b'0\xc300081509281447541218021146
Mine:       0100081509281447541218021146

I'm not sure if it's gotten corrupted on the JuiceBox, or what? I'm not really sure how to change it either...

[ivanfmartinez]

@pbjfarm its TCP/IP which does have checkings, the value will not be corrupted on TCP/IP part, it should be corrupted before going out juicebox device.

It appear to me something hardware related.

Even if I change the \xc3 to 1 on the message you sent on first comment of the issue, the checksum still does not match. Appear that something else on the message are wrong.

To try to understand if there is also another exception that I can catch probably I need a complete log to check. If you dont want to send log here you can send to my email (my github username at gmail) or telegram with same username .

All messages are corrupted or some are correct ?

[pbjfarm]

@ivanfmartinez I thought this was UDP...but it does seem like my messages (or at least the ID) are corrupted somehow.

I've now managed to brick my box somehow (it's not showing the local WiFi SSID on reboot), so I won't be able to provide logs until I can figure out what's going on.

[ivanfmartinez]

@pbjfarm JB used UDP and UDP is part of TCP/IP.

If the ids are broken in all messages, them is something on the device.

Maybe FalconFour can help with more ideas or maybe someone else on Discord check main page for link https://github.com/JuiceRescue

[carrel-gr]

Hi. Not trying to be critical at all. But I'd like to clarify about TCP and UDP. UDP isn't part of TCP/IP. IP is a layer 3 protocol. Both UDP and TCP are layer 4 protocols that run on top of IP. You use one OR the other. TCP establishes a stateful connection to a remote peer and provides reliable stream transport so that higher layer protocols can send data without worrying about issues such as resending data if packets are lost. TCP takes care of that. UDP is a best effort datagram protocol. It is connectionless. It sends a packet and it's done. When using UDP, the higher layer protocol must handle issues such as resending lost packets/data.

While UDP doesn't guarantee packet delivery, it does support a checksum to try to detect any packet corruption. However, this checksum is optional and the implementation can set it to zero to disable it.

UDP seems a logical choice for the JB as it sends a complete message in a single datagram, and even if a packet is lost, the JB is going to resend another soon anyway. TCP would add unnecessary overhead, especially on a busy server. As for the UDP checksum, I have no idea if the JB uses it or not. We could tell from a packet capture. Since the Enel X protocol provides its own checksum, there is a good chance they are not using the UDP checksum.