Understanding the TCP/IP Protocol (Part 3)

If you would like to read the rest of the articles in this series please go to:

00:00:03.700720 > S [tcp sum ok] 365712315:365712315(0) win 32768 <mss 536> (ttl 63, id 59169, len 44)
0x0000   4500 002c e721 0000 3f06 4253 c0a8 0164        E..,.!..?.BS….
0x0010   c0a8 01c8 2eb3 0050 15cc 53bb 0000 0000        …1…P..S…..
0x0020   6002 8000 30e0 0000 0204 0218 0000             `…0………

00:00:03.715864 > S [tcp sum ok] 2093803204:2093803204(0) ack 365712316 win 5840 <mss 1460> (DF) (ttl 52, id 0, len 44)
0x0000   4500 002c 0000 4000 3406 f474 c0a8 01c8         E..,[email protected]…1
0x0010   c0a8 0164 0050 2eb3 7ccc e6c4 15cc 53bc           …..P..|…..S.
0x0020   6012 16d0 32d2 0000 0204 05b4 0000                  `…2………

Well seen above are the same two packets that we have been working our way through. In part two we left off at the win size metric. On that note lets pick it back up, and continue our analysis.

<mss 536>

What the above denotes in actuality is “maximum segment size” or mss as it is commonly referred to. Following that is the value of 536, which refers to the value of mss. All said and done this means that the source computer ie:

does not want to receive more then 536 bytes of data in any one given packet. This is a rather low value for an mss seen as the mtu (maximum transmission unit) for Ethernet is 1540. Though please note that often Internet Explorer will advertise a default mss of 536 as seen above. Also please remember that the mss value is only ever seen in a SYN segment. If for some reason the source did not send a mss value then the default value of 536 bytes is assumed.

(ttl 63, id 59169, len 44)

The first value of ttl 63 actually denotes the “time to live” that the packet has. What that means is that if this packet had gone through another 63 router hops then it would have been dropped. That in turn would of resulted in an ICMP error message being generated by the last router to decrement this value. This is one of the metrics that is not measured in bytes. It is simply a numerical value that is decremented each time it goes through a router. Were there not to be ttl values then the internet would probably end up grinding to a halt at some point. It does happen at times that packets get lost for lack of a better term. This value makes sure that at some point the packet is either delivered, or that it is dropped.

id 59169

Next on our hit parade is the metric seen above. What this means is that the IP ID number is 59169. And that means what exactly!? Well it means that should this packet be fragmented for some reason, then every fragment will have the same IP ID number. In this case all fragments would have an ip id of 59169.

This is the because that when the destination computer receives  a fragmented packet, that it knows what fragments belong to each other. There is another value though that would be included and that is the fragmentation offset. This offset would let the computer know in what order the packets should be. After all no good to have all the fragments if you don’t know in what order they go.

len 44

Now the final value contained in the header is len 44. This refers to the total length of the packet itself. This count, which is measured in bytes takes into account not only the TCP and IP header. It would also include the data that was sent if any. This is an important distinction to make, and a good one to remember.

Well that now wraps up all of the header metrics that are viewable in ASCII. We are now at the stage where we will begin looking at the rather cryptic hex values. Please note that the TCP/IP and tcpdump flyer I mentioned in part one is required here. Lastly to find this document look at the bottom of the page under resources for the pdf document titled the same as the hyperlink. What we shall now do is go through the hex one line at a time. So on that note I will paste one line, and comment on it, beneath it.

0x0000   4500 002c e721 0000 3f06 4253 c0a8 0164        E..,.!..?.BS….

Our first value as seen above is 0x0000, and what that signifies is that the value following 0x will be in the hexadecimal numbering format. The funny thing here is that we need to count starting from zero, vice normally starting with one. Another thing that is rather important to remember! So with that said, our byte zero will actually be represented by the characters 45, as seen above. We can now see that if you want to look at a single nibble then that would then be one character only, whether it be a number or letter. Don’t forget that the hexadecimal numbering system uses both letters, and numbers ie:  0-9, A-F.

So what does our first byte, or byte zero actually break out to then? Well if you are looking at your TCP/IP sheet then you will notice that the IP Version is assigned four bits, or a nibble. That nibble in this case is represented by the value of 4. So that tells us that this packet is using IPv4.

Following that is the IHL, or internet header length. This value represents the number of 32 bit words that the IP header has. If we divide 32 by 8 then we would realize that a 32 bit word is actually four bytes. The value we have here is five, and if we multiply that by four then we have 20 bytes in the IP header. That in actuality is a standard IP header, and standard in so much as there are no IP options set in it. Were there IP options such as loose source record route then the value of five would be changed accordingly.

Well we can see that this is pretty simple to break out given our TCP/IP cheatsheet. With that in mind I will skip to the TCP header. The reason I do so is that there are TCP options contained in packet one. Please remember at this time that packet one refers to the SYN packet noted above, and not the SYN/ACK packet seen beneath it.

0x0020   6002 8000 30e0 0000 0204 0218 0000             `…0………

Specifically from the above last line of hex in packet one, is the values of 0204 on to 0000 that we will look at. For as I mentioned above this is where the TCP options are detailed. At this time please take a look at the bottom of the TCP header cheat sheet and see the options segment.

With that said our TCP options begin with the two bytes 0204 noted above in the packet snippet. What that means is that the first TCP option in this TCP header is the mss or maximum segment size. That value of two corresponds to mss as seen at the bottom of the TCP header cheat sheet  that you downloaded, under options. Next we have the size in bytes of that TCP option, which is the length of the option. In this case it is four bytes. After that is 0218, and that in hex equates to 536 in decimal. That happens to be the value of the mss option. If a TCP option has a numerical value then it will follow it, as it does in this case. Lastly there is 0000. Funny thing here is that our total packet length is supposed to 44 as denoted by “len 44”. In this case all that happened is that the nic card probably padded the two extra bytes.

Well as you can see from these articles understanding both TCP and IP is really not all that difficult. All it takes is a bit of practice, and in no time you will be ripping through these like you were a native. I sincerely hope that this was of use to you, and welcome as always any and all comments.

If you would like to read the rest of the articles in this series please go to:


About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top