Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a device (GPS localizer) that is sending TCP (I think so) packets to my server on given IP address and through given port. Since I have only SSH access to that server, I opened up two sessions and run tcpdump (with proper parameters) in one of them and my own listener (written in PHP) in second one.

When I connect with that IP and port from any of my browsers, I clearly see traffic captured by both tcpdump and my own listener. So, I assume that everything works fine.

However, when I force my localizer to send data to that IP/port, only tcpdump responds, showing, that he has captured something, while my own listener's output remains empty.

I'm a newbie in networking and TCP, so maybe I mistakenly assumed, that this is TCP connection. Can someone, with more experience confirm that, by looking at what tcpdump has captured:

10:43:37.028958 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [S], seq 1457768261, win 5120, options [mss 1360,nop,wscale 0,nop,nop,TS[|tcp]>
10:43:37.029564 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [S.], seq 1118512962, ack 1457768262, win 5792, options [mss 1460,nop,nop,TS[|tcp]>
10:43:37.526145 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 1, win 5200, options [nop,nop,TS val 79 ecr 35113125], length 0
10:43:37.526934 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [P.], ack 1, win 362, options [nop,nop,TS val 35113175 ecr 79], length 152
10:43:38.225678 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 153, win 5048, options [nop,nop,TS val 80 ecr 35113175], length 0
10:43:43.765708 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [P.], ack 153, win 5200, options [nop,nop,TS val 89 ecr 35113175], length 119
10:43:43.765768 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [.], ack 120, win 362, options [nop,nop,TS val 35113799 ecr 89], length 0
10:43:44.445757 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [P.], ack 153, win 5200, options [nop,nop,TS val 91 ecr 35113175], length 119
10:43:44.446014 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [.], ack 120, win 362, options [nop,nop,TS val 35113867 ecr 91], length 0
10:47:38.675424 IP 192.168.1.2.7777 > 87.111.103.7.2020: Flags [F.], seq 153, ack 120, win 362, options [nop,nop,TS val 35137290 ecr 91], length 0
10:47:41.636064 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [.], ack 154, win 5200, options [nop,nop,TS val 568 ecr 35137290], length 0
10:47:41.655520 IP 87.111.103.7.2020 > 192.168.1.2.7777: Flags [R.], seq 120, ack 154, win 5200, length 0

Is this really a TCP connection (packet type)? If yes, then can anyone have any idea, why my listener is not reponding, while it responds correctly on TCP connection from a browser? If this is not a TCP connection, then what it is? What should my listener listen to, to capture this kind of traffic?

EDIT: What bothers me the most here, is that every connection from my localizer is marked by tcpdump with length 0 (while response back always has some length). But I noticed, that browser connections are also marked with length 0, so maybe this isn't a real problem.

share|improve this question
    
Clarification: When you say listener, do you mean network sniffer, or do you mean a service (the passive end of the connection) that has called {socket, bind, listen}? –  richard Sep 14 '12 at 13:15
    
@richard: You're talking to a newbiew in networking! :] My listener is (should) insert any (correctly formatted) data, it receive to a DB and do not pass it anywhere else. So I think, it is more a passive end than a sniffer. Data sent by my localizer is 100% addressed to my listener and nowhere else. –  trejder Sep 16 '12 at 6:14
    
OK I, the confusion was that tcpdump is a sniffer, wireshark is another that can listen to a wire, using a 3rd computer. But you are talking about the passive end (the listener, not to be confused with the reader. As both ends can read ( the connection is symmetric once the connection is established.)) –  richard Sep 17 '12 at 7:42

2 Answers 2

Your dump looks good. Your device (I assume it's the 192.168.1.2) sends packets of length larger than 0 and your server acknowledges the receipt via 0-byte ACK packets. It will certainly be helpful for you to include -XX in your tcpdump command line.

tcpdump -XX port 2020
share|improve this answer
    
Sure, it will be helpful. But there is no problem with tcpdump only with my PHP listener -- as written in above comment. I'm trying to figure out, why my listener remains deaf for connections form localizer (tcpdump captures it), while it works fine for connections from a web browsers for example? –  trejder Sep 16 '12 at 6:22
    
Well I mean helpful in the sense that it will show you which data your listener should receive. For example, if the device is only sending NUL bytes, then your listener's output will most likely not show. –  Stefan Seidel Sep 16 '12 at 19:52
    
Thanks! I've included -xx in command and did extra info. No, the question is, how can I manually decode, what it has captured -- i.e.: 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? Is this just a hex notation of real data being sent by my localizer? –  trejder Sep 17 '12 at 5:37
    
With -XX (capital X) you'll have the ASCII notation as well. If the data you gave is all you've got, then it looks a bit like your localizer sends emtpy data packets. You may need to check the documentation of the device. Yet another option is this: you stop your PHP listener and instead you run a command line listener like this: nc -l 7777 | hexdump -C (note the capital C). –  Stefan Seidel Sep 17 '12 at 7:11
    
Well, here is a pastebin for everything, tcpdump receives usually from this localizer. I was pretty sure, that the fact, that it sends garbage is the reason, why PHP listener is unable to capture this traffic. No, I'm using very limited Linux (NAS, not full server) and I don't have / can't install nc. And no - as far as I know, there is no docs, API or guide for developers / power users of this localizer (cheap China TK102). Only some basics for newbies, how to configure it. –  trejder Sep 17 '12 at 17:17

just to answer the last bit (you say this is the most worrying)

This is what I see: all data has a length, all without data (syn,ack,fin,rst) have length 0. It looks OK.

87.111.103.7 port 2020      --      192.168.1.2 port 7777
                        syn ->
                        <- syn ack
                        ack ->

                        <-data
                        ack ->

                        data ->
                        <- ack 

                        data ->
                        <- ack 

                        <- fin

                        fin ->
                        rst ->
share|improve this answer
    
Thank you for your reply. But what about my real question? Is this a correct TCP transmission? If yes, then do you have any idea, why my listener is not capturing it? I used a simple TCP listener form PHP.net Examples Page -- version updated for multi-client purpose and with a few my own corrections. It captures TCP connection from any browser perfectly, but remains deaf for anything that my localizer sents. –  trejder Sep 16 '12 at 6:20
    
Maybe show us the code, that you wrote. –  richard Sep 17 '12 at 7:43
    
The code is pretty long, and since it is nearly exactly the same as on PHP.net Sockets Example Page, I though, it will be better to forward you there. That's what I wrote in my previous comment. If you want to see the code, I'm using for my listener, please, follow to PHP.net Sockets Example Page and scroll down to user contributed notes (bottom of page, javier's example). Thanks! –  trejder Sep 17 '12 at 16:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.