Using tcpdump for capturing data sent by TK102 GPS tracker
Xexun TK102 GPS Tracker and most of its clones can send localization data either via SMS messages (some models offers just a pure data, that you have to analyze yourself, some sends it out along with Google Maps link) or via GPRS protocol, directly to specified server. Which then can analyze and visualize that data. SMS sending works just great in most cases, while getting GPS data via GPRS can be a real pain in the ass. This post is written with hope to help you a little bit, if you’re facing the same problem.
Note: though, I’m experienced developer, I’m lame-Windows-user in the same time, so my Linux knowledge is very limited. Since, I’m using Linux examples in this post, you my find some information obvious to you, if you’re more experenced Linux maniac. Just don’t laugh, OK? :]
Introduction
If you just want to visualize location of your tracker and you’re not interested in programming issues (writing own solution for receiving data from your localizers) then this article is not for you. It aims developers mostly.
Regular users should consider services like GPS-Trace instead of coding from scratch. Don’t invent the wheel.
Example SMS reply
If you’re using SMS-sending mode and want to program your solution basing on analysing SMS replies, here you have an example SMS reply from TK102 tracker:
lat: 50.247646 long: 019.039873 speed: 000.0 20/09/12 15:33 bat:F signal:F imei:355689015535918
Getting Xexun TK102 GPS Tracker and most of its clones to send location via SMS is by far more easier than doing the same via GPRS, but it is far less configurable. And reply message format differs among devices and clones, so you should take into consideration, that basing your solution on SMS-reply can also be a real pain in the ass. It will be much easier to receive such data, but far much harder to analyze and visualize it.
Example GPRS reply
Most TK102 clones are sending data via UDP protocol! So, you need to setup your server to listen in this protocol. Which may not be that easy, as many server’s admins doesn’t allow to listen this kind of data. Only few of them can be forced to send data via normal HTTP protocol, which listening is by far easier (as it is used by web browsers, so nearly every server will allow to listen to such data).
I wasn’t able to receive correct data via GPRS with this device so far (). Most likely, because I have a clone that requires a proper reply from the server. If it does not receive this one, it will break connection and won’t send any more data.
Some TK102 clones will broadcast localization data to any server (when configured or forced to do so) and will ignore server reply (in any), so these ones are fairly easier to listen to. I wasn’t that lucky, so all I manage to do so far, was to capture some binary garbage, which seems to be a welcome message.
Since I’m lack of any API or technical documentation for TK102 right now, I don’t know, what kind of reply my server should send via UDP back to localizer to keep connection alive and receive actual GPS data. This is the point, where my current story ends.
tcpdump
I used tcpdump on my server to listen to UDP packets coming to it. I was lucky to get a fixed IP address for my SIM card, which isn’t to common practice among mobile carriers. So I was able to limit traffic, tcpdump listens to and logs to only packets sent directly from my localizer. If you’re not lucky enough, you’ll have to listen to all the traffic sent in UDP protocol and find out manually, among all other garbage, packets sent from your localizer. Hopefully, there isn’t much UDP traffic on most servers.
Since, I knew IP address from which my packets will orginate from, I used this command:
tcpdump -i eth0 -n host 83.220.106.3
I was able to get basic packet information with it. Example packet sent from my TK-102 (this probably-welcome-binary-garbage), caputred by tcpdump was:
22:51:20.962524 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [S], seq 1449434550, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]>
For more verbose packet information, I used command (above, with -vv switch):
tcpdump -i eth0 -n src 83.220.106.3 -vv
And packet data logged by tcpdump was extended to:
22:53:05.300457 IP (tos 0x0, ttl 7, id 47150, offset 0, flags [DF], proto TCP (6), length 68) 83.220.106.3.2020 > 192.168.1.2.7777: Flags [S], seq 1449539294, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]>
Finally, I tried listening with very detailed HEX encoded packet information (with -xx switch):
tcpdump -i eth0 -n src 83.220.106.3 -xx
Captured packed information for each packet was really large. Here is example:
07:34:23.959920 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [S], seq 1504570664, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]> 0x0000: 0008 9bc0 2fb6 74ea 3ae4 64aa 0800 4500 0x0010: 0044 b847 4000 0706 3be3 53dc 6a03 c0a8 0x0020: 0102 07e4 1e61 59ad ed28 0000 0000 c002 0x0030: 1400 1b76 0000 0204 0550 0103 0300 0101 0x0040: 080a 0000 07:34:23.960730 IP 192.168.1.2.7777 > 83.220.106.3.2020: Flags [S.], seq 639321676, ack 1504570665, win 5792, options [mss 1460,nop,nop,TS[|tcp]> 0x0000: 74ea 3ae4 64aa 0008 9bc0 2fb6 0800 4500 0x0010: 003c 0000 4000 4006 bb32 c0a8 0102 53dc 0x0020: 6a03 1e61 07e4 261b 464c 59ad ed29 a012 0x0030: 16a0 e200 0000 0204 05b4 0101 080a 0391 0x0040: f37c 0000 07:34:24.460142 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [.], ack 1, win 5200, options [nop,nop,TS val 568 ecr 59896700], length 0 0x0000: 0008 9bc0 2fb6 74ea 3ae4 64aa 0800 4500 0x0010: 0034 b848 4000 0706 3bf2 53dc 6a03 c0a8 0x0020: 0102 07e4 1e61 59ad ed29 261b 464d 8010 0x0030: 1450 1019 0000 0101 080a 0000 0238 0391 0x0040: f37c 07:34:24.460828 IP 192.168.1.2.7777 > 83.220.106.3.2020: Flags [P.], ack 1, win 362, options [nop,nop,TS val 59896750 ecr 568], length 152 0x0000: 74ea 3ae4 64aa 0008 9bc0 2fb6 0800 4500 0x0010: 00cc b5e3 4000 4006 04bf c0a8 0102 53dc 0x0020: 6a03 1e61 07e4 261b 464d 59ad ed29 8018 0x0030: 016a 8048 0000 0101 080a 0391 f3ae 0000 0x0040: 0238 0a57 07:34:25.384602 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [.], ack 153, win 5048, options [nop,nop,TS val 569 ecr 59896750], length 0 0x0000: 0008 9bc0 2fb6 74ea 3ae4 64aa 0800 4500 0x0010: 0034 b849 4000 0706 3bf1 53dc 6a03 c0a8 0x0020: 0102 07e4 1e61 59ad ed29 261b 46e5 8010 0x0030: 13b8 0fe6 0000 0101 080a 0000 0239 0391 0x0040: f3ae 07:34:27.400375 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [P.], ack 153, win 5200, options [nop,nop,TS val 573 ecr 59896750], length 118 0x0000: 0008 9bc0 2fb6 74ea 3ae4 64aa 0800 4500 0x0010: 00aa b84a 4000 0706 3b7a 53dc 6a03 c0a8 0x0020: 0102 07e4 1e61 59ad ed29 261b 46e5 8018 0x0030: 1450 e513 0000 0101 080a 0000 023d 0391 0x0040: f3ae 3132 07:34:27.400436 IP 192.168.1.2.7777 > 83.220.106.3.2020: Flags [.], ack 119, win 362, options [nop,nop,TS val 59897044 ecr 573], length 0 0x0000: 74ea 3ae4 64aa 0008 9bc0 2fb6 0800 4500 0x0010: 0034 b5e4 4000 4006 0556 c0a8 0102 53dc 0x0020: 6a03 1e61 07e4 261b 46e5 59ad ed9f 8010 0x0030: 016a 2094 0000 0101 080a 0391 f4d4 0000 0x0040: 023d
I have also tried the same with ASCII encoded packet information (with -XX switch):
tcpdump -i eth0 -n src 83.220.106.3 -XX
This time, I’ve received:
10:09:32.860705 IP 83.220.106.3.2020 > 192.168.1.2.7777: Flags [S], seq 1449434838, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]> 0x0000: 0008 9bc0 2fb6 74ea 3ae4 64aa 0800 4500 ..../.t.:.d...E. 0x0010: 0044 b82d 4000 0706 3bfd 53dc 6a03 c0a8 .D.-@...;.S.j... 0x0020: 0102 07e4 1e61 5664 9ed6 0000 0000 c002 .....aVd........ 0x0030: 1400 6f4f 0000 0204 0550 0103 0300 0101 ..oO.....P...... 0x0040: 080a 0000
In tcpdump documentation, I’ve read, that instead of displaying captured data directly to the screen, I can dump it into the file, with -w /path/to/file.log command switch. But it failed on my server — file was created, but no packet was ever dumped / captured]. So I reverted back to on-screen capture after that.
If your localizer doesn’t have fixed IP address or you don’t know this, try to limit amount of traffic, that tcpdump capture, by limiting it into TCP protocol (or UDP, if your localizer uses it) and particular port, you’ve set in localizer configuration.
For example:
tcpdump -i eth0 tcp port 6881
Summary
As I wrote in the beginning, this is as far I got until now. You need to continue for your own from this point.