Friday, July 20, 2007

TCPdump: Understanding the Output

Tcpdump is definitely a TOOL for most of network engineers to debug or examine their network pcap data. However not many actually read it with full understanding, let's go back to basic and take a simple look at this tcpdump output -

2007-04-18 20:09:17.334010 IP 192.168.0.24.49971 > 210.171.226.46.21: P 49:54(5) ack 543 win 14
0x0000: 0016 b681 3b0e 000a e435 ea8e 0800 4500 ....;....5....E.
0x0010: 0039 9430 4000 4006 30f4 c0a8 0018 d2ab .9.0@.@.0.......
0x0020: e22e c333 0015 3ed0 d5bd 4304 5fb9 8018 ...3..>...C._...
0x0030: 000e 75c6 0000 0101 080a 0150 492e 6828 ..u........PI.h(
0x0040: 2f7c 5057 440d 0a /|PWD..

I have highlighted the hex number in the most left column, but how can we make use of them when examining the data? Here's the conversation I have with my friend and he said I should blog about it and I think that's not bad idea too since I haven't read anything about it online yet. Our conversation went like this -

(10:19:03) me: u need to make use of the left side hex number too
(10:19:11) me: 0x0000
(10:19:13) me: 0x0010
(10:19:15) me: 0x0020
(10:19:17) me: :)
(10:19:27) friend: and that represents for?
(10:19:38) me: it tells you exactly the start of the byte offset in that row
(10:19:49) me: 0x0000 = starts from 0 byte
(10:19:54) friend: ohhhhhhh
(10:19:58) me: 0x0010 = starts from 16 byte
(10:20:03) me: 16th byte
(10:20:06) me: hehe
(10:20:24) me: 0x0020 = starts from 32nd byte
(10:20:43) me: and that's for whole frame offset instead of per layer/header offset
(10:20:53) me: but it's good indication
(10:21:12) me: remember for all layer, it counts starting from 0 byte offset.
(10:21:20) me: i think i should blog about this
bla bla bla bla ...... truncated

This is definitely better than couting the byte manually especially useful when you have a large size packet, but keep in mind if you want to decode per layer/header, you will have to examine initial header length in IP header and offset/header length in TCP header which I highlighted in the output below -

2007-04-18 20:09:17.334010 IP 192.168.0.24.49971 > 210.171.226.46.21: P 49:54(5) ack 543 win 14
0x0000: 0016 b681 3b0e 000a e435 ea8e 0800 4500 ....;....5....E.
0x0010: 0039 9430 4000 4006 30f4 c0a8 0018 d2ab .9.0@.@.0.......
0x0020: e22e c333 0015 3ed0 d5bd 4304 5fb9 8018 ...3..>...C._...
0x0030: 000e 75c6 0000 0101 080a 0150 492e 6828 ..u........PI.h(
0x0040: 2f7c 5057 440d 0a /|PWD..

2 hex number = 1 byte, 5 x 4 = 20 bytes and here's your IP header -

2007-04-18 20:09:17.334010 IP 192.168.0.24.49971 > 210.171.226.46.21: P 49:54(5) ack 543 win 14
0x0000: 0016 b681 3b0e 000a e435 ea8e 0800 4500 ....;....5....E.
0x0010: 0039 9430 4000 4006 30f4 c0a8 0018 d2ab .9.0@.@.0.......
0x0020: e22e c333 0015 3ed0 d5bd 4304 5fb9 8018 ...3..>...C._...
0x0030: 000e 75c6 0000 0101 080a 0150 492e 6828 ..u........PI.h(
0x0040: 2f7c 5057 440d 0a /|PWD..

Following by the IP header should be your TCP header(Check the 9th byte offset and that's 06), just now you see I have highlighted 8 and that's the length of TCP header - 8 x 4 = 32 bytes

2007-04-18 20:09:17.334010 IP 192.168.0.24.49971 > 210.171.226.46.21: P 49:54(5) ack 543 win 14
0x0000: 0016 b681 3b0e 000a e435 ea8e 0800 4500 ....;....5....E.
0x0010: 0039 9430 4000 4006 30f4 c0a8 0018 d2ab .9.0@.@.0.......
0x0020: e22e c333 0015 3ed0 d5bd 4304 5fb9 8018 ...3..>...C._...
0x0030: 000e 75c6 0000 0101 080a 0150 492e 6828 ..u........PI.h(
0x0040: 2f7c 5057 440d 0a /|PWD..

You may notice I didn't highlight the ascii on the most right(3rd) column, because it is totally meaningless to examine the ascii data when reading the layer2, 3 and 4 header in most circumstances. What about the remaining 5 bytes - 5057 440d 0a?

2007-04-18 20:09:17.334010 IP 192.168.0.24.49971 > 210.171.226.46.21: P 49:54(5) ack 543 win 14
0x0000: 0016 b681 3b0e 000a e435 ea8e 0800 4500 ....;....5....E.
0x0010: 0039 9430 4000 4006 30f4 c0a8 0018 d2ab .9.0@.@.0.......
0x0020: e22e c333 0015 3ed0 d5bd 4304 5fb9 8018 ...3..>...C._...
0x0030: 000e 75c6 0000 0101 080a 0150 492e 6828 ..u........PI.h(
0x0040: 2f7c 5057 440d 0a /|PWD..

This is definitely FTP traffic(notice port 21 highlighted) for this case, and the reason why I highlight the ascii now is because it is the application data that you should examine, PWD is print working directory when you check the RFC here, 0d is carriage return and 0a is newline or usually be recognized as \r\n.

Hopefully here I have clear the myth of tcpdump output for some of newcomers who want to learn about reading tcpdump output, it's not so hard to decode them when you understand. I don't explain every single field in the header yet but maybe I will make it next time if I'm in mood. I know some of you prefer to use wireshark as it generates more human readable output by decoding every single field correctly but I would say it is meaningless if you generally have no idea about networking therefore it's always good to go back to basic.

Peace (;])

No comments: