Unknown protocol

[ofabric-io]

Hi everyone,

It seems like it’s been a while since there was activity here.

I have a couple of ZX303 PCBs and I’m considering forking this project. Unfortunately, I’m running into some issues with unknown protocols.

The login process works fine, and status updates are coming through correctly. However, occasionally, the device sends packets with protocol 1A or 1B. Here’s an example of one such packet:

7878031a241018104445e848b8f9597428dcd9ae4a33f94c743c188703b9560302d4020000b2990000797f3c0000b2990000797e3c0000b2990000797d50000d0a

It happens intermittently with both devices. Once it starts, it seems to get stuck in a loop, sending these packets repeatedly. Eventually, it resets on its own and sends the login packet again.

Has anyone encountered something similar or have any insights into what these protocols might represent?

To investigate further, I set up a TCP sniffing service to capture these packets and forwarded them to 365gps.net, hoping to observe how the official server would respond. Unfortunately, even the default server doesn't seem to respond to these protocols.
conversation_log.json

Thanks in advance for your help!

[tobadia]

Hey,

Apologies for the very late response. You'll have guessed that I'm not actively developping that anymore, although it still sits "somewhere" on a to-do list of things I'd like to do "someday"...
I have lost that tracker I was using a coupls months ago and can't test that code anymore. You're pointing out issues of undescribed/unidentified packets. I also observed that, and it was extremely hard sourcing proper protocol documentation. Some of the troubleshooting I did was using traccar source code but again, I guess for those chinese devices we are referring to, it's a hit or miss.

I mostly observed these "loop" issues when the server answer was not what the tracker was expecting (e.g. see commit ef03a6a). Maybe check the last package that was sent before you got stuck and see if the answer could be an unexpected one ?