GT06 device sends large 0x22 GPS batches and connection resets — GPS distance/position handling issue

Hi Traccar team,

We are having a GPS tracking/distance calculation issue with a tracker that is connecting to our Traccar server using the GT06 protocol.

Device ID / IMEI:
867010074702631

Server:
Traccar
Protocol detected:
gt06

The device is able to connect successfully and Traccar responds to the initial packets. However, the device repeatedly connects, sends some initial packets, disconnects/resets the TCP connection, and then reconnects again.

Example:

17:06:53
[T4cabee8c] connected

Device sends:
78781101086701007470263180962121000035af0d0a

Traccar responds:
787805010000c8550d0a

The device then sends:
7878058a0001fc960d0a

and:
78780a13060604000200041ac40d0a

After that the connection is reset:
Connection reset - SocketException

The more interesting behavior happens on subsequent connections.

At 17:08:40 the device sends a very large series of 0x22 packets, for example:

787826221a09030c2b00c6014771b2088b11f003153b...

Traccar responds with multiple ACKs for protocol 0x22.

Traccar then successfully decodes many historical GPS positions from these packets, for example:

2026-09-03 09:56:55
lat: 11.92730
lon: 79.62937
speed: 20.0

2026-09-03 09:57:04
lat: 11.92808
lon: 79.62907
speed: 21.1

2026-09-03 09:57:13
lat: 11.92895
lon: 79.62908
speed: 20.0

...

2026-09-03 09:59:50
lat: 11.93982
lon: 79.63190
speed: 16.7

However, before these valid records are decoded, Traccar also reports:

time: 1980-01-06 01:00:00
lat: 0.00000
lon: 0.00000

This happens repeatedly after the device connects.

The device is also repeatedly reconnecting from different mobile-network public IP addresses.

We have already verified that:

1. The device can reach the Traccar server.
2. TCP communication is working.
3. Traccar is recognizing the device as GT06.
4. Traccar is sending ACK responses.
5. The device is sending actual GPS data.
6. Traccar is decoding the large 0x22 packets and extracting GPS positions.

The problem is that the tracker appears to be sending buffered/batched GPS records rather than normal continuous position updates, and we are seeing incorrect/stale/invalid positions and distance calculation discrepancies.

Could you please help us determine:

1. Is this 0x22 packet format fully supported by the current Traccar GT06 decoder?
2. Does Traccar expect these 0x22 packets to contain multiple buffered GPS records?
3. Is the 1980-01-06 / 0,0 position generated by the GT06 decoder because of the device's initial packet or because of invalid device time/GPS data?
4. Could the repeated TCP connection resets/reconnections cause the buffered records to be processed in a way that affects distance calculation?
5. Are there any Traccar configuration options that should be changed for this particular GT06 device?
6. Is this likely a device firmware/protocol variant that requires a specific GT06 decoder implementation?
7. Is there anything we should provide from the raw TCP capture that would help you identify the exact packet format?

We can provide the complete tracker-server.log and raw tcpdump/packet capture if required.

We would prefer to resolve this at the Traccar protocol/decoder level rather than continuing to change tracker configuration blindly.

Thanks.

Full Log: https://drive.google.com/file/d/10207GYrujTp_yrsrAtk2KyBysAes_auI/view?usp=sharing

Do you have the protocol documentation?

no we don't have anything but this device is concox v5 4g device, and also we have another one tracker which was chine clone (AW05 4G) i think but it too have same issues.

where we can get that documentation?

From your device vendor.

Okay we will get it, thanks.

Several comments about your situation:

1. "1980-01-06 01:00:00" is expected value when your device hasn't reported any location. It goes away once there is location.
2. There are a lot of "Connection reset - SocketException", which indicates some device or network issue.

No Anton, I don't think this is caused by the network or connectivity issue.
We are seeing a specific sequence where the device establishes the connection and sends the data correctly, but when Traccar sends the acknowledgement back to the device, the device immediately resets/closes the connection.

So the Connection reset - SocketException appears to be a consequence of the device resetting the socket after receiving the Traccar acknowledgement, rather than an independent network problem.

If needed, we can provide the raw device → Traccar packet and Traccar → device ACK sequence so you can compare them with the protocol specification.

and aslo i have found out one doumentation but i don't know is it was the correct one https://drive.google.com/file/d/1mN2P1FmTTQXz4YpTVdgDLtNrMV3LTQI4/view?usp=sharing.

another one https://drive.google.com/file/d/1JM9zBk0mbjoGgB_vQlHq_20vgr9pfaPY/view?usp=sharing

You can verify the confirmation against those docs.

okay i will try.

hi anton we haven't got anything from that docs but we got one thing from our vendor they used cmsv6 server and connected the device and from that i have got some details.

What are the details?

Hi Anton, we’ve now identified that the issue was caused by our ISP, Airtel. The connection was being terminated every few seconds, which was causing the problem. We confirmed this by switching to another network, where everything worked normally.