If you missed the previous article in this series, please go read
Well we left off in part one with two packets to look at. Those two packets as seen below are the SYN and SYN/ACK portions of the three-way handshake. The ACK is not included as some operating systems will leave it out and go straight into the exchange of data. On that note let’s start tearing apart our packets!
00:00:03.700720 192.168.1.100.11955 > 192.168.1.200.80: 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 192.168.1.200.80 > 192.168.1.100.11955: 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………
For our purposes we will refer to the SYN packet as packet one from here on in. In case you are wondering SYN actually stands for “synchronize”, and SYN/ACK stands for “synchronize acknowledgement”. Starting off with packet one, we will move from left to right all the way through.
00:00:03.700720
The above noted is the timestamp of the packet. We have the normal hh mm ss as seen, but we also have six numbers after that as well. That means that this time is accurate to the microsecond. Rather precise isn’t it! An important thing to remember here is that this is not the time that the packet was sent at. Rather it is the time, that the packet was received by the destination computer. On another note, is the fact that the destination computer may be set up for a different time zone then you. In other words don’t automatically assume the time is the same as your local time.
192.168.1.100.11955
What we have here is the source IP address that is initiating communications with the other IP address to the right of it. Following the IP address is the port that is being used, or as we should call it the source port. All ports from 1025 above, are called ephemeral ports. All ports below 1025 as I note a little further down are called the reserved range. Any time that your computer starts up a session with another computer, your computer’s kernel will arbitrarily assign an ephemeral port to that session. This ephemeral port will remain constant during the session itself. The source port will only change if you terminate your session and initiate a new one, at which time a new ephemeral port will be assigned to your new session.
>
Our little symbol above denotes what direction the conversation is coming from. So the pointy end indicates the destination in this case, and is always in this direction. This is another helpful hint to remember who is actually the source, and destination computer in a packet stream.
192.168.1.200.80
Well we can see that the above is an IP address. Question is: is it the source computer’s IP address ie: the sender, or is it the destination address? You can take as gospel that this IP address is the destination computer’s address. This is because as mentioned above it is on the pointy end of my direction symbol. Following the IP address of the destination computer is the destination port used of that very same computer. In this case we have port 80, and we can probably safely assume that there this is a webserver of some sort on this computer. At this time please note that port 80 falls in the “reserved” port range. This range starts at port 0 and ends at port 1024. Not all ports in this reserved range have well known services associated with them, but it is called the reserved range none the less.
S
The ASCII character S as seen above stands for SYN, or as we now know it “synchronize”. That means that this packet is the very first step in our TCP/IP handshake.
[tcp sum ok]
What the above stands for is “TCP Checksum is okay”. That actually means that when the source computer sent out this packet, it did a mathematical check against the TCP header and came up with a value. That value was then stored in the TCP header itself. Once the destination computer received this packet, it in turn also did the same mathematical check. It then verified that its value was the same, as the value it sees in the TCP header. In this case it was, hence the [tcp sum ok]. Were the value different then you would of seen a checksum error message where this was instead.
365712315:365712315
This rather large number separated by a full colon is called the TCP sequence number. You will note in our case that it is the same value separated by a full colon. That is due to the fact that there is no data being exchanged at this point in time. Were there data, and this packet a PSH/ACK vice a SYN packet then the values would be different on both sides of the colon. To be precise it would be different by the exact amount of data sent in that packet. We will see an example of what I mean a little later on.
(0)
The zero seen above tells us that there is no actual data being sent in this packet as it is a SYN packet. That does not mean though that you could not craft a SYN packet and stuff some data into it. Though be aware that your data would be ignored as you did not complete the TCP/IP handshake. One last note on packet crafting; be aware that it has limitations as to what it can do. You could not realistically simulate the handshake via manually crafting your packets.
win 32768
Now the above is referred to as the Window Size or as some call it the receive buffer. The value following it is measured in bytes just like the other numerical values. What this means is that the source computer can receive no more then 32768 bytes of information, before acknowledging to the destination computer that it has processed some of them.
Should it receive more than this without an ACK from it signifying that it has processed a certain amount of data then those extra bytes that were sent would simply hit the bit bucket. In essence they would not be stored in the receive buffer of the application. This is a good time to point out that this value is normally controlled by the application in use. For example this value could be the Win Size of Internet Explorer.
I really don’t like leaving you in suspense but we will break the article at this point. In part three we will cover the remaining metrics seen in packet one. After that we will then wade into the sea of hex that is contained in the packet. You may be in for a surprise as to just what is contained in those hex values! Till then!
If you missed the previous article in this series, please go read
