#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass report
\begin_preamble
\input{preamble}
\end_preamble
\language english
\inputencoding auto
\fontscheme times
\graphics default
\paperfontsize 11
\spacing double 
\papersize letterpaper
\paperpackage a4
\use_geometry 1
\use_amsmath 1
\use_natbib 1
\use_numerical_citations 1
\paperorientation portrait
\leftmargin 1.5in
\topmargin 0.9in
\rightmargin 1in
\bottommargin 1in
\headsep 0.17in
\footskip 0in
\secnumdepth 4
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle fancy

\layout Chapter

Comments on TCP structures
\begin_inset LatexCommand \label{cha:tcpStructs}

\end_inset 


\layout Standard


\begin_inset ERT
status Collapsed

\layout Standard

\backslash 
thispagestyle{empty}
\end_inset 


\begin_inset ERT
status Collapsed

\layout Standard

\backslash 
renewcommand
\backslash 
figurename{Fig.}
\end_inset 

This next section is about the different structures that make up the Linux
 kernel's networking and will be touching on the most important structures.
 Major points about the networking section in the Linux code can be covered
 with the sk_buff, and sockets.
 This next section is mainly a reference describing the different structures.
 This information would assist in creating a new protocol or changing the
 TCP/IP (INET implementation) for research needs.
 
\layout Section

sk_buff
\layout Standard

The sk_buff contains all the information the packet needs to get to the
 destination.
 ip_output.c:ip_queue_xmit() is the last place in the call stack the inet
 socket is used to give extensive information about the packet then the
 sk_buff is the only parameter (and maybe the routing tables) passed through
 the call stack to the network device.
 
\layout Standard

For the TCP, the sk_buff is created for outbound packets in tcp_output.c:tcp_v4_c
onnect() and released at net/core/dev.c:dev_queue_xmit().
 For the incoming packet the sk_buff is created in the process_backlog,
 one reference was not entirely sure where the incoming packet is created
 and believed the packet was created in dev_alloc_skb ( )
\begin_inset LatexCommand \citep{Beck2002}

\end_inset 

.
 
\layout Standard

The sk_buff partitions into six different parts: the link list, packet header,
 routing, control buffer, stats, and markers.
 
\layout Subsection

Link list
\layout Standard

The sk_buff is a structure attached to other sk_buff's in a linked list
 structure and has pointers to control it location, having pointers to the
 head, next, and prev.
 This link list contains other sk_buff structures heading to the same destinatio
n generally going to the common router gateway.
 This linked list is a little different.
\layout Standard

n each sk_buff in the link list, there are two additional pointers to a
 network device (*dev) and to the inet socket (* sk).
 In addition to being double linked to each other with pointers to the head
 and tail, there are also pointers pointing to the device driver and the
 socket.
 Now, when the sk_buff is being populated with packet information it is
 just pointing to the socket.
 As the routing information is calculated, the device pointer is populated.
 At one point, every sk_buff in the link list is pointing to both a device
 and socket.
 And, as the packets are about to be setup to hardware, the socket pointer
 is set to null and only pointing to the device1.
 This section of pointers groups the sk_buff based on connection and then
 on outbound device.
 
\layout Subsection

Packet header
\layout Standard

This section talks about the packet header information.
 The sk_buff and most of the kernel is designed for abstraction using pointer
 arithmetic.
 With many different standards, each of the protocols have to correspond
 by having a similar interface, so the same network mechanism works with
 different protocols (e.g., UDP and TCP protocols).
 
\layout Standard

The sk_buff allows different protocols by using C Unions.
 There are three different headers (same as theOSI network stack): Transport,
 Network, and Link (or hardware).
 In the sk_buff, these headers are all pointers.
 A kmalloc (oppose to malloc) is called using sk_put( ).
 When receiving a packet, the header type is determined and the sk_buff
 maps a poitner to the correct packet header structure.
 The sk_put reserves the memory for each header.
 Since memory is allocated going from a top down structure, the timing of
 when sk_put is called is important.
 The IP header cannot be populate before populating the TCP header.
 The timing of when everything is done is just as or more important as what
 is populated into the sk_buff.
 
\layout Standard

Networks have different type of computers on them.
 These computers read information differently in memory.
 Most of the higher end systems (newer Apples, Suns, and HP Unix) use big
 endian.
 Intel uses little endian (for performance).
 The big and little endians needs to be accounted for when storing data.
 The difference between big and little endian is four bytes: little endian
 has bytes in reverse (not the bits, the bytes).
 An IP address: 172.31.0.173 (hex: ac 1f 00 1d) would be stored as (hex: 1d
 00 f1 ac).
 The network send data as big endian does not reverse the bytes.
 When creating a iphdr (IP header), there are preprocessor statements which
 line the flags and other fields in the right order.
 One important and simple concept is he difference between the actual packet
 in memory and the sk_buff, an independent structure pointing to memory.
\layout Standard

sk_put ( ) reserves or expands the memory space of the packet.
 The sk_buff structure consists of pointers referencing the data area memory.
 In the Linux source code ( net/ipv4/ip_output.c:ip_queue_xmit()), a call
 to skb_push reserves memory for the entire socket structure.
 
\layout Standard

As information passes through each of the layers, additional headers are
 added using the skb_push function.
 In addition to the actual header, routing information is also stored in
 the dst_entry.
\layout Subsection

Routing
\layout Standard

When sending a packet, the dst_entry actually dictates the header information.
 The dst_entry stores the destination and mac addresses for transmission.
 The dst_entry stands for âdestinationâ entry.
 In the 2.4 kernel the dst_entry is assigned for a new connection in the
 tcp_ipv4.c:tcp_v4_connect().
 
\layout Standard

Going through each of the parameters in the call above, tt is a routing
 table structure, and nexthop is the gateway address.
 RT_CONN_FLAGS(sk) sets the connection flag, and sk->bound_dev_if is the
 outbound device.
 Generally, the packet goes to a network device (e.g., eth0).
 If the packet is heading towards an ip tunnel, the packet heads towards
 tunnel network driver (tunl1).
 The only thing populated from the ip_route_connect() is the routing table.
 The routing table is populated based off the actual IP routing table listed
 in the /proc/route and arp cache entry.
\layout Standard

The dst_entry is part of the routing table with other routing information,
 like the gateway, routing destination, and routing source.
 The routing table is placed inside of the INET sock, and the sk_buff has
 a pointer to dst_entry set by the INET socket.
\layout Standard

ne of the entries on the dst_entry the hh (cached hardware header) determines
 in the ip_output.c:ip_finish_ouptput2 if the packet is destined for an IP
 tunnel or regular transmission.
 The source follows a different path in ip_finish_output2 based on hh value.
 If the hh is set to null, the sk_buff will be directed down another source
 path which eventually leads to the ipip.c functions (functions for IP tunneling)
, otherwise the sk_buff continues neigh_resolve_output() uninterrupted.
\layout Standard

he dst_entry also contains a pointer to the dev.
 The dev pointer points to the network device the packet is sent and received.
 The network device also contains pointers to a lot of abstract functions.
 These functions pointers allow for the correct function to be called pro