Dodgy Chinese tracker
It's GT06 protocol, port 5023 in Traccar.
Anton, you are likely sick of dumb newbie questions like mine, I sincerely appreciate your virtually instant response, thank you!
I have made a donation, please let me know if you don't get it.
Hi all,
i need some help please.
i can't figure out whitch protocol, it is a chines GT06 uses my Tracker.
bellow some logs:
2017-01-20 22:56:43 DEBUG: [7410BFE6: 5023 < 105.189.95.122] HEX: 283032373034343732343235304250303033353532323730343437323432353048534f31613829 2017-01-20 22:59:25 DEBUG: [7410BFE6: 5023 < 105.189.95.122] HEX: 28303237303434373234323530425a30302c7b3630342c302c343036302c35313135327d0a7b3630342c302c343036302c35303431327d0a7b3630342c302c343036302c35313135317d0a2c303030303030303029 2017-01-20 22:59:43 DEBUG: [7410BFE6: 5023 < 105.189.95.122] HEX: 283032373034343732343235304250303033353532323730343437323432353048534f31613829
thank you in advance.
@xenirox, your device is using TK103 protocol, so correct port is 5002. Unique id is 027044724250.
Hi Anton,
still can't see it, here is the new logs:
2017-01-20 23:15:06 INFO: [2F29A15C] disconnected 2017-01-20 23:15:14 INFO: [CE686F98] connected 2017-01-20 23:15:14 DEBUG: [CE686F98: 5002 < 41.92.105.137] HEX: 28303237303434373234323530425030353335353232373034343732343235302c2c303030303030303029 2017-01-20 23:15:14 DEBUG: [CE686F98: 5002 > 41.92.105.137] HEX: 283032373034343732343235304150303529 2017-01-20 23:15:14 DEBUG: [CE686F98: 5002 < 41.92.105.137] HEX: 28303237303434373234323530425a30302c2c303030303030303029
may be you can see a problem with timestamp or date?
It's not a timestamp problem. The problem is that your device doesn't send any GPS data. Possibly it doesn't have a GPS signal.
ok i'll try put it in somewehe else, and come back to you.
i walked and i worked. thank you very much.
Hi everyone,
I have a similar issue as the original poster. Based on the IMEI he provided it seems like we have the same device. My IMEI is 35288707***227* (Masked a few characters with *). My own research also tells me the device uses GT06 protocol (port 5023) as suggested by Anton.
After setting APN and restarting the device it connects and I get data and then at some random point it starts doing this. Obviously the device still tries to connect and send data, but it looks like there's a problem parsing it or it cannot process the response from Traccar. Any help will be much appreciated.
Looking up these device IMEI numbers returns
Model: GT003
Brand: DEAO (Deao International Group Limited)
IMEI: TAC: 352887 FAC: 07 SNR: ****** CD: *I was also wondering what protocol (TCP/UDP) these devices typically use? I currently have port forwarding setup on my home router to forward both TCP and UDP on port 5023 to my Traccar server port 5023.
SMS'ing check****** to my device returns (****** is password)
GSM: 100%
GPS: FIXED
GPRS: ON
BATTERY: 100%
APN: internet
Hostname: my-home.no-ip.com
IP: 197.245.**.***
PORT: 5023
imei:35288707***227*
VERSION:61M-GT06_V4.6_180925Another strange thing I've noticed is that if I set the APN to something other than internet, e.g. afrihost, it switches back to internet after a few days.
2019-04-27 15:18:16 INFO: [a20a6734: 5023 < 41.113.***.***] HEX: 78780d01035288707***227*004512880d0a
2019-04-27 15:18:16 INFO: [a20a6734: 5023 > 41.113.***.***] HEX: 787805010045ddfc0d0a
2019-04-27 15:18:47 WARN: [a20a6734] error - Connection reset by peer - IOException (...)
2019-04-27 15:18:47 INFO: [a20a6734] disconnected
2019-04-27 15:19:45 INFO: [c93af337] connected
2019-04-27 15:21:16 INFO: [177a7dee] connected
2019-04-27 15:23:19 INFO: [38d2b555] connected
2019-04-27 15:23:21 INFO: [38d2b555: 5023 < 41.113.***.***] HEX: 78780d01035288707***227*005beb770d0a
2019-04-27 15:23:21 INFO: [38d2b555: 5023 > 41.113.***.***] HEX: 78780501005b24030d0a
2019-04-27 15:23:36 WARN: [38d2b555] error - Connection reset by peer - IOException (...)
2019-04-27 15:23:36 INFO: [38d2b555] disconnectedI've found a document explaining the GT06 communication protocol with a data flow diagram. It's insightful. The packet in my example is a Login Message. The server seems to responds appropriately.
So why error - Connection reset by peer - IOException (...) and disconnected?
It seems that the server's response never actually reaches the tracker.
After 5 minutes of failing to receive a response from the server, the tracking tries to reconnect to the server by sending another Login Message. This explains why I only see these messages in the server log.
Why does the APN reset?
After 20 minutes of failing to receive a response from the server, the tracking unit reboots. I'm guessing this might be the cause for the APN to reset. I read somewhere that the tracker will try to automatically detect the APN, so this could be the reason.
Assuming there's data on the internet APN the tracker should continue working on internet, right?
The dynamic IP of my server is a potential point of failure. My router reboots weekly which may change the IP. I was hoping that a Dynamic DNS domain would resolve this. I would think that the tracker resolves the domain to IP upon every request (or if the domain is not reachable) but it is possible that it only does this once upon booting. This theory falls apart if you consider that the unit reboots after 20 minutes, which should then result in the domain resolving in the updated IP.
This still leaves us with why does the server response not reach the tracking unit?
I found that changing the APN to afrihost makes it work. So there might be something about the internet APN causing issues. ISP blocking requests on port? I dunno. I'll run some tests other ISP/SIM.
Hi guys,
I've looked through this forum and find many issues with trackers with unknown origin and I suspect I've made a mistake buying the ones I have!
The tracker box says it's a TK103B but the output from the device is not consistent with normal output from any device at https://raw.githubusercontent.com/tananaev/traccar/master/tools/test-integration.py
The output from the log file:
The devices imei number is 352887073042271 and this appears in the HEX: output above sandwiched between 78780d010 which doesn't change and 0008baf30d0a which changes. Because the iemi is in decimal, decoding the whole thing produces unexpected results.
Has anyone had any experience with this kind of output? Any suggestions?
The device does respond to a call with accurate GPS location and responds to commands but apart from that, not much else.