SYN:  Synchronize sequence numbers.

    			  FIN:  No more data from sender.



8.  Window		- Specifies the maximum size of a segment that you can

			  accept, if the segment is larger than this then it

			  must be fragmented.



9.  Checksum		- The TCP checksum just like we explained with the IP

			  header, is to ensure that there is no loss of Data

			  during transport, it gets the size of the packet and

			  when it gets to the host the host compares the size

			  of the packet with the value of the checksum and if

			  they dont match you can see the packet was mangled

			  during transport.



			  The TCP Checksum is calculated using a psuedo header

			  which is prefixed to the TCP Header. The purpose of

			  this Psuedo Header is to protect the TCP packet from

			  misrouted segments. The Psuedo Header contains 4

			  main pieces of information, the Source IP, the

			  Destination IP numbers, the protocol and the TCP

			  length.





   			  +-----------------------------------+

   			  |           Source Address          |

   			  +-----------------------------------+

   			  |         Destination Address       |

   			  +--------+--------+--------+--------+

   			  |  zero  |  PTCL  |    TCP Length   |

   			  +--------+--------+--------+--------+



			  FIG 1.3  - The structure of a Psuedo Header





			  The TCP Length field is the length of the TCP Header

			  + length of the Data and does not count the length of

			  the Psuedo Header (12 Bytes).



10. Urgent Pointer	- This field is only to be set when the URG control bit

			  is set. It points to a Data area.



11. Options		- The TCP options field is very similiar to the IP Options

			  field except it has fewer interesting parts that need

			  to be mentioned here...  none.



12. Padding		- The same as the IP Padding Field.









3.3 THE UDP HEADER

=======================================



   +---------------------------------+--------------------------------+

   |          Source Port            |       Destination Port         |

   |            16 bits              |           16 bits              |

   +---------------------------------+--------------------------------+

   |            Length               |           Checksum             |

   |            16 bits              |           16 bits              |

   +---------------------------------+--------------------------------+



   FIG 1.4  - The Structure of a UDP Header



The UDP Header is more basic than previous Headers, it has only 4 fields.



1. Source Port

2. Destination Port

3. Length

4. Checksum





1.  Source Port		- Same as in TCP.



2.  Destination Port	- Same as in TCP.



3.  Length		- The length of the Datagram, including UDP Header and

			  Data. Size must be at least 8.



4.  Checksum		- Same as TCP this field protects against misrouted packets

			  it also uses the same Psuedo Header as TCP.







3.4 THE ICMP HEADER

=======================================



   +----------------+----------------+--------------------------------+

   |      Type      |     Code       |           Checksum             |

   |     8 bits     |    8 bits      |           16 bits              |

   +----------------+----------------+--------------------------------+

   |                              Unused                              |

   |                              32 bits                             |

   +------------------------------------------------------------------+

   |            Internet Header + 64 bits of Original Data            |

   |                              32 bits                             |

   +------------------------------------------------------------------+



   FIG 1.5  - The Standard Structure of an ICMP Header



The ICMP Header changes depending on the message it is sending. Different

ICMP Messages are conveyed by combinations of different values and the

Unused Field can contain different values and become used depending upon

the different ICMP messages being sent. For example in some messages you

may need to specify the general Type of message and then its code, this

certain message may require additional information such as the IP Address

of a computer, this address would then be stored in the Unused Field.



The ICMP protocol is similiar to UDP in that it is used in messages of 1

Datagram in size, however, ICMP is more like an extension of IP and certain

fields must also be set for use with ICMP.





The Standard ICMP Header has 4 main fields.



1. Type

2. Code

3. Checksum

4. Unused





1.  Type		- Field declaring the type of ICMP Message.



2.  Code		- Field specifying the messages code to identify its

			  meaning.



3.  Checksum	- Calculated the same as other headers, the kernel may pad

			  this if the checksum is an odd number to respect 32 bit

			  boundaries in most ICMP messages but Checksum is not

			  calculated in some ICMP Messages.



4.  Unused	- The value of this field varies depending on the type of

			  ICMP message, if no value is to be entered in this field

			  it must be specified as 0.





There are several different ICMP messages but here we are only going to refer

to the 2 most interesting types Echo and Netmask request and reply's.



======================

Echo Request and Reply

======================



Description:



These two ICMP Messages are commonly used in conjunction to form

the ping program. First we send an Echo Request to a host and

that host then sends us an echo reply. By sending multiple requests

to a host and comparing the time they were sent with the time that

the Echo Reply was recieved we can calculate the mean time that

packets are sent between us and that host. This Message is also

useful to determine whether a host is reachable and connected to the

internet or not.



Data can be inserted into an Echo request, perhaps for checking

the integrity of a packet which it is returned?





Type:



Echo Request	= 8

Echo Reply 	= 0





Code:



Field Unused	= 0





Checksum:



As specified above.





Identifier:



Same as the IP Identifier, useful to determine which ICMP Echo Reply

belongs to which Echo Request.





Sequence Number:



Used in the same way as the Identifier is above, useful for matching

Echo Reply's with Requests.



====================================================================



=========================

Netmask Request and Reply

=========================



Description:



We can send a netmask request to a host and it will return a netmask

reply containing its subnetmask, getting subnetmasks is useful for

mapping out and gathering information on network topology.





Type:



Netmask Request	= 17

Netmask Reply	= 18





Code:



Field Unused	= 0





Checksum:



Same as above.





Identifier:



Same as the IP Identifier, useful to determine which ICMP Netmask

Reply belongs to which Netmask Request.





Sequence Number:



Used in the same way as the Identifier is above, useful for matching

Netmask Reply's with Requests.



====================================================================







4.0 CREATING A PACKET

=======================================



OK well thats enough Protocol Header theory, lets look at how we are

going to construct a raw socket in code and the differences between

coding raw sockets and normal windows sockets code.



Now with normal Sockets we give certain information to the stack in

the case of windows, the Winsock. This information comprises of things

like what transport layer were gonna use, TCP or UDP, the address of

the host we are going to send it to, the port for it to go to, the

Data to be contained within the Datagram, we name the socket call

the sendto() function and off it goes. What we should consider now

is what then happens to the information that we just provided, we know

how the IP protocol sends it off zooming across the internet and how

the host handles and sends this Data, but what happens inbetween the

time we called sendto() and the time that packet leaves our computer?



Well we passed this information to the winsock, the winsock then

takes information such as the Destination address and our own address

along with the protocol we specified and fills out the relevant

fields in the protocol header, it then sets the TTL with its own

default value of 35.



Then the winsock uses the other information we provided, the source

and destination port numbers, and fills the relevant TCP or UDP

Header fields, and constructs the header, wraps the headers around

the Data we specified and calculates things such as fragmentation

and fills in the fields. Once everything is filled out and wrapped

up the winsock calculates the size of the packet and specifies the

checksum value.



With all this done the winsock sends the packet off to whiz around

the internet.



So with normal sockets we dont have to specify all those nasty fields

in the Headers we leave it up to good ol' winsock and it handles that

but we want to create our own headers so how do we stop the winsock

from prefixing its headers onto our packet?





4.1 SETSOCKOPT()

=======================================



The setsockopt() function is very important in raw sockets, its here

that we tell the winsock that we want to use our own headers for this

packet and for it to not add its own to ours.



The setsockopt() function has 5 parameters:



1. Socket

2. Level

3. Option Name

4. Option value

5. Option Length





1. Socket		- Just like in normal sockets this is a Socket

		 	  that we made earlier in the program.



2. Level		- This is the protocol we are going to be using

		 	  in the program, it has values such as

		 	  IPPROTO_TCP and IPPROTO_IP.



3. Option Name		- The socket option we are going to set, we will

			  be setting this to IP_HDRINCL, this option is

			  what tells the winsock we want to include our

			  own headers for the packet.



4. Option Value		- Pointer to the buffer in which the value for

			  the requested option is supplied. We will be

			  using a boolean called bOpt set to true for

			  this, set to false would mean that we dont want

			  to use the IP_HDRINCL option.



5. Option Length	- The size of the buffer which supplies the

			  value. We will use sizeof(bOpt) for this.





The setsockopt() function well be looking at so will look like this:



setsockopt(myraw, IPPROTO_IP, IP_HDRINCL, (char *)&bOpt, sizeof(bOpt)





So now how do we tell the winsock that we want to use raw sockets

instead of normal sockets in the first place?





4.2 SOCKET()

=======================================



Of course weve already covered the socket() function in the past and

are familiar with its different parameters but what we have to be

concerned about two of its parameters, its type and protocol.



A normal socket looks like the following:



socket(AF_INET, SOCK_STREAM, 0)



Before we used to set its type as SOCK_STREAM or SOCK_DGRAM for TCP

and UDP respectively. In raw sockets however we will set the type

parameter to SOCK_RAW and the protocol to IPPROTO_RAW.



A Raw Socket looks like this:



socket(AF_INET, SOCK_RAW, IPPROTO_RAW);



So thats how we tell the winsock that its a raw socket that we will

be using which still leaves the question how do we build the actual

header?