Horace papa's life

1)Both Non-Napi and Napi driver will call the netif_receive_skb() function, Non-Napi driver will through the function of prcess_blocklog(),   Napi driver will through the function of polling function in device driver.

2)The netif_receive_skb() does the below tasks.  

 
#skb_bond():

allows a group of interfaces to be grouped together and be treated as a single interface. the frame was received blonged to the one such group, the skb->dev must be changed to the device in the group with the role of master.

#Give a copy of the frame to each register protocol sniffer: list each  packet handle in ptype_all which entry is added by dev_add_pack()

and then send skb into the function deliver_skb();

#handle_diverter():

Diverter allows the kernel to change the L2 destination MAC address of frames to the other hosts originally to the local host. besides skb->pkt_type must be changed to PACKERT_HOST.

# Give a copy of the frame to each L3 registerd protocol handler: list each  packet handle in

Non-ptype_all (&ptype_base[hash]), which entry is added by dev_add_pack()and then send skb into the function deliver_skb();

#deliver_skb():

Two ways to receiving rx packets.

1) Non-Napi aware driver:

The device driver interrupt handler calls netif_rx to put the skb received from netdevice into input_pkt_queue per CPU and then call netif_rx_schedule() to add blacklog dev(virtul device) into CPU poll_list and raises softirq.

2) Napi aware driver:

The device driver interrupt handler calls netif_rx_schedule() or netif_rx_schedule_pre() and __netif_rx_schedule() to add dev into poll_list and raises softirq.

After raise_softirq NET_RX_SOFTIRQ the net_rx_action() will be called.  net_rx_action() is added by net_dev_init function with the function open_softirq() to add into NET_RX_SOFTIRQ.

IN net_rx_action() the Non-Napi aware device will run the poll function asigned by net_dev_init() with the line of "sd->backlog.poll = process_backlog"

The Napi aware device will register poll function into poll_list in the networking initial function of device driver, in net_rx_action function the the poll_list will retrived all the devices and run their poll functions. The packets receiving from Non-Napi aware driver, the process_blacklog function will be run in net_rx_action().    

3)when the packets, which received by Non-NAPI device, pass to the function of  process_blacklog() , they are dequeued from input_pkt_queue of local CPU and pass to netif_receive_skb(). viceversa, when the packets, received by Napi aware device, would passed to the poll function implemented by device driver and later on pass to netif_receive_skb() function.

Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol that extends Point-to-Point Protocol (PPP) to support a link layer tunnel between a requesting L2TP client (L2TP Access Concentrator or LAC) and a target L2TP server endpoint (L2TP Network Server or LNS).

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzaiy/rzaiyl2tpsupport.htm

This first diagram illustrates the layout of the SKB data area and where in that area the various pointers in 'struct sk_buff' point.

The rest of this page will walk through what the SKB data area looks like in a newly allocated SKB. How to modify those pointers to add headers, add user data, and pop headers.

Also, we will discuss how page non-linear data areas are implemented. We will also discuss how to work with them.

   skb = alloc_skb(len, GFP_KERNEL);

This is what a new SKB looks like right after you allocate it using alloc_skb()

As you can see, the head, data, and tail pointers all point to the beginning of the data buffer. And the end pointer points to the end of it. Note that all of the data area is considered tail room.

The length of this SKB is zero, it isn't very interesting since it doesn't contain any packet data at all. Let's reserve some space for protocol headers using skb_reserve()

   skb_reserve(skb, header_len);

This is what a new SKB looks like right after the skb_reserve() call.

Typically, when building output packets, we reserve enough bytes for the maximum amount of header space we think we'll need. Most IPV4 protocols can do this by using the socket value sk->sk_prot->max_header.

When setting up receive packets that an ethernet device will DMA into, we typically call skb_reserve(skb, NET_IP_ALIGN). By default NET_IP_ALIGN is defined to '2'. This makes it so that, after the ethernet header, the protocol header will be aligned on at least a 4-byte boundary. Nearly all of the IPV4 and IPV6 protocol processing assumes that the headers are properly aligned.

Let's now add some user data to the packet.

   unsigned char *data = skb_put(skb, user_data_len);
        int err = 0;
        skb->csum = csum_and_copy_from_user(user_pointer, data,
                                            user_data_len, 0, &err);
        if (err)
                goto user_fault;

This is what a new SKB looks like right after the user data is added.

skb_put() advances 'skb->tail' by the specified number of bytes, it also increments 'skb->len' by that number of bytes as well. This routine must not be called on a SKB that has any paged data. You must also be sure that there is enough tail room in the SKB for the amount of bytes you are trying to put. Both of these conditions are checked for by skb_put() and an assertion failure will trigger if either rule is violated.

The computed checksum is remembered in 'skb->csum'. Now, it's time to build the protocol headers. We'll build a UDP header, then one for IPV4.

TCP connections

In this section and the upcoming ones, we will take a closer look at the states and how they are handled for each of the three basic protocols TCP, UDP and ICMP. Also, we will take a closer look at how connections are handled per default, if they can not be classified as either of these three protocols. We have chosen to start out with the TCP protocol since it is a stateful protocol in itself, and has a lot of interesting details with regard to the state machine in iptables.

A TCP connection is always initiated with the 3-way handshake, which establishes and negotiates the actual connection over which data will be sent. The whole session is begun with a SYN packet, then a SYN/ACK packet and finally an ACK packet to acknowledge the whole session establishment. At this point the connection is established and able to start sending data. The big problem is, how does connection tracking hook up into this? Quite simply really.

As far as the user is concerned, connection tracking works basically the same for all connection types. Have a look at the picture below to see exactly what state the stream enters during the different stages of the connection. As you can see, the connection tracking code does not really follow the flow of the TCP connection, from the users viewpoint. Once it has seen one packet(the SYN), it considers the connection as NEW. Once it sees the return packet(SYN/ACK), it considers the connection as ESTABLISHED. If you think about this a second, you will understand why. With this particular implementation, you can allow NEW and ESTABLISHED packets to leave your local network, only allow ESTABLISHED connections back, and that will work perfectly. Conversely, if the connection tracking machine were to consider the whole connection establishment as NEW, we would never really be able to stop outside connections to our local network, since we would have to allow NEW packets back in again. To make things more complicated, there is a number of other internal states that are used for TCP connections inside the kernel, but which are not available for us in User-land. Roughly, they follow the state standards specified within RFC 793 - Transmission Control Protocol at page 21-23. We will consider these in more detail further along in this section.

As you can see, it is really quite simple, seen from the user's point of view. However, looking at the whole construction from the kernel's point of view, it's a little more difficult. Let's look at an example. Consider exactly how the connection states change in the /proc/net/ip_conntrack table. The first state is reported upon receipt of the first SYN packet in a connection.

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1
   

As you can see from the above entry, we have a precise state in which a SYN packet has been sent, (the SYN_SENT flag is set), and to which as yet no reply has been sent (witness the [UNREPLIED] flag). The next internal state will be reached when we see another packet in the other direction.

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1
   

Now we have received a corresponding SYN/ACK in return. As soon as this packet has been received, the state changes once again, this time to SYN_RECV. SYN_RECV tells us that the original SYN was delivered correctly and that the SYN/ACK return packet also got through the firewall properly. Moreover, this connection tracking entry has now seen traffic in both directions and is hence considered as having been replied to. This is not explicit, but rather assumed, as was the [UNREPLIED] flag above. The final step will be reached once we have seen the final ACK in the 3-way handshake.

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 use=1
   

In the last example, we have gotten the final ACK in the 3-way handshake and the connection has entered the ESTABLISHED state, as far as the internal mechanisms of iptables are aware. After a few more packets, the connection will also become [ASSURED], as shown in the introduction section of this chapter.

When a TCP connection is closed down, it is done in the following way and takes the following states.

As you can see, the connection is never really closed until the last ACK is sent. Do note that this picture only describes how it is closed down under normal circumstances. A connection may also, for example, be closed by sending a RST(reset), if the connection were to be refused. In this case, the connection would be closed down after a predetermined time.