Tracker GPS chinois : identifier le protocole par sniff hex

Un tracker GPS 4G acheté sur AliExpress, étiqueté famille <vendeur> clairement reconnaissable. Je configure le serveur Traccar sur le port officiel de ce protocole <vendeur>. Le tracker se connecte (vérifié par netstat ESTABLISHED), envoie un paquet, puis Traccar ferme la connexion immédiatement sans rien logger.

Pas un seul log d’erreur. Le tracker boucle en se reconnectant. Le device est bien déclaré dans Traccar admin avec son IMEI. Aucun message d’erreur côté serveur.

Symptôme

$ docker exec traccar netstat -tn | grep :5174
tcp  0  0  10.0.0.5:5174  78.x.x.x:24287  TIME_WAIT

TIME_WAIT = Traccar a fermé. À chaque cycle (~30s), même séquence : SYN+ACK, le tracker envoie ~60 octets, Traccar ack puis FIN.

Aucune trace dans docker logs traccar. Aucun « Unknown device », aucune erreur de parsing.

Cause

Le tracker, malgré son nom commercial appartenant à une famille protocolaire identifiée, parle un autre protocole au niveau wire. Les noms de produits trackers chinois (familles MiCODUS, Concox, Eelink…) sont des labels marketing, pas des spécifications protocolaires. Beaucoup utilisent en réalité du JT808 (le standard chinois national pour véhicules GPS).

Le serveur reçoit le paquet, ne trouve pas la signature du protocole qu’il écoute sur ce port, ne sait pas répondre, ferme proprement (RFC-compliant) — d’où le silence en log.

Solution — décoder le 1er paquet à la main

sudo tcpdump -nn -i any -xx 'tcp port 5174 and src host <ip-tracker> and tcp[tcpflags] & tcp-push != 0' | head -30

Le payload commence après l’en-tête TCP. Premier octet du payload = signature protocolaire :

Avec un paquet JT808, structure typique :

7e 01 00 00 2d 01 91 76 77 59 99 00 2c ...
 │  └─┘ └─┘ └────────────┘
 │   │   │   └── device ID BCD (6 octets = 12 digits)
 │   │   └──── body length
 │   └────── message ID (0x0100 = registration terminal)
 └── delimiter de trame

Une fois le vrai protocole identifié, configurer Traccar pour écouter ce protocole sur le port utilisé par le tracker (cf [[73-traccar-forcer-protocole-sur-port-precis]]).

Lessons learned

• Le nom commercial d’un tracker chinois ≠ son protocole wire — un device « branded MiCODUS » peut parler JT808, un « Concox » peut parler GT06 ou JT808, etc.
• Traccar ferme TCP sans log quand le protocole sur le port ne reconnaît pas la signature — pas d’erreur, juste close (RFC propre, debug enfer)
• tcpdump -xx sur le premier paquet PSH suffit à identifier la famille protocolaire en ~30 secondes, sans avoir à fouiller la datasheet du firmware
• Signature protocolaire = 1-4 premiers octets du payload : c’est plus rapide à reconnaître qu’à chercher dans la doc du fabricant (souvent introuvable ou en chinois)
• Lire la notice de commandes SMS ne t’apprend pas le protocole — la notice décrit l’interface utilisateur du firmware, pas son protocole serveur. C’est deux couches distinctes.

#gps #traccar #iot #troubleshooting #networking #tcpdump #devops #reverse-engineering