PTP FAQ

• What is PTP?

The Precision Time Protocol is a method by which a computer, communicating over a
Local Area Network can keep its local clock synchronized to a better time source,
commonly referred to as a Master Clock.

• My computer has a clock, why do I need PTP?

All commercially available computers do come with a built in clock. The built in clock
in an off the shelf desktop, server or laptop is only accurate to within a few seconds
per day. Depending on local conditions, such as high heat or vibration the clock built
into your computer can wander by minutes in a day. If you don't need your computer's
clock to be in line with the rest of the world's clocks by more than a few seconds
then you don't need PTP. Stop here, rest easy.

• I run an operating system that has Internet time synchronization built in, why would I use PTP?

Most operating systems (FreeBSD, MacOS X, Linux, Windows, etc.) have a built in network time
client based on the Network Time Protocol (NTP). NTP is meant to synchronize a clock over the Internet.
Many organizations, including companies and governments, set up very accurate clocks,

linux-2.6.35.6 nf_conntrack
http://bbs.chinaunix.net/thread-4082396-1-1.html

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.

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).

quotation:

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzaiy%2Frzaiyl2tpsupport.htm

Layer Two Tunneling Protocol

By using Layer Two Tunneling Protocol (L2TP) tunnels, it is possible to separate the location at which the dial-up protocol ends and where the access to the network is provided. That is why L2TP is also referred to as Virtual PPP.

These figures illustrate three different tunneling implementations of L2TP.

Figure 1. PPP virtual initiator or PPP virtual terminator

Figure 2. PPP dial initiator or PPP virtual terminator

Figure 3. PPP virtual dial or PPP virtual answer

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.

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():

http://blog.chinaunix.net/u3/115276/showart_2284947.html

一、sk_buff的结构图如下

二.sk_buff结构基本操作

     1、skb_headroom(), skb_tailroom() 

    原型/描述

 

int skb_headroom(const struct sk_buff *skb);

   bytes at buffer head

int skb_tailroom(const struct sk_buff *skb);

  bytes at buffer

     示图

2、skb_reserve()

原型 

 

void skb_reserve(struct sk_buff *skb, unsigned int len);

 

描述 

       adjust headroom

示图 

 

3、skb_push()

原型

 

unsigned char *skb_push(struct sk_buff *skb, unsigned int len);