In the course of working on Mobile Data systems, there are times when we need to figure out what is going to and from a particular handset or mobile device. The problem is that when the system you are trying to troubleshoot has tens of millions of devices connecting to it through proxy servers, its a lot like a needle-in-the-haystack kind of problem.

We had to narrow the potential number of packets that we would be capturing using tcpdump to something under a GB of disk space. If we just did a generic capture, we would only get about four seconds of traffic….which would not be very helpful for our troubleshooting efforts. So we needed a way to reduce the packets just down to the HTTP ‘GET’ packets, and the HTTP response codes.

After digging around the tcpdump man pages for awhile, I came up with the following parameters to just capture those packets:

tcpdump -i eth0 -n -s 1400 -W troubleshoot.cap host {localhost IP} and \( tcp[20:2] = 18245 or tcp[20:2] = 18516 \)

  • The “-i eth0″ tells it to capture off the eth0 network device.
  • “-n” tells it not to expand the IP addresses into domain name. (Optional)
  • “-s 1400″ captures 1400 bytes of each packet.
  • “-W troubleshoot.cap” is the capture file.
  • {localhost IP} would be where you substitute the IP address of the host you are capturing from.
  • Now the meat of the command: the “tcp[20:2]” tells tcpdump to look at the 20th byte of the TCP field and get two bytes from there. 18245 => 0×4745 => “GE” as in “GET”. My version of tcpdump only allows for 1,2 or 4 bytes to be compared, so I settled for two. 18516 => 0×4854 = “HT” as in “HTTP”.

This should significantly reduce the number of packets captured. But be aware — getting tcpdump to look inside the TCP field of the IP packets requires a lot of CPU cycles to process all the incoming packets.

Here’s a sample of a capture using the command above (and its only off my local office web server, so you won’t find any cellphone company secrets here):

21:02:58.807323 IP 192.168.22.27.55133 > 192.168.22.44.80: P 3493:4074(581) ack 1146 win 16138
0×0000: 4500 026d 7a60 4000 8006 d092 c0a8 161b E..mz`@………
0×0010: c0a8 162c d75d 0050 fe3a b4da 2337 2b65 …,.].P.:..#7+e
0×0020: 5018 3f0a 3e7c 0000 4745 5420 2f73 6d2f P.?.>|..GET./sm/
0×0030: 696d 6167 6573 2f70 6c75 732e 706e 6720 images/plus.png.
0×0040: 4854 5450 2f31 2e31 0d0a 486f 7374 3a20 HTTP/1.1..Host:.
0×0050: 3139 19
21:02:58.808107 IP 192.168.22.44.80 > 192.168.22.27.55133: P 1146:1337(191) ack 4074 win 3500
0×0000: 4500 00e7 5d80 4000 4006 2ef9 c0a8 162c E…].@.@……,
0×0010: c0a8 161b 0050 d75d 2337 2b65 fe3a b71f …..P.]#7+e.:..
0×0020: 5018 0dac 0c06 0000 4854 5450 2f31 2e31 P…….HTTP/1.1
0×0030: 2033 3034 204e 6f74 204d 6f64 6966 6965 .304.Not.Modifie
0×0040: 640d 0a44 6174 653a 2057 6564 2c20 3233 d..Date:.Wed,.23
0×0050: 204a .J

If you are counting out the packets by hand, the tcp[] option starts its counting at zero.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 | Posted by MobileDataGuy | Categories: Cellphones, HowTos, Radio Data |