Linux PPP data sending and receiving process

Ext.: http://blog.csdn.net/yangzheng_yz/article/details/11526671

PPP (point-to-point) provides a standard way to transmit multiple protocol packets over a point-to-point connection, the most common use of which may be traditional dial-up access (the current broadband access is said to be in the form of PPPoE). On the Linux Mobile phone, the network application uses PPP as a communication protocol with the GSM module, and has recently encountered a bit of trouble with PPP, so it took some time to study it.

The PPP protocol is certainly not the most complex network protocol, but after pppd, chat, TTY, socket, CCP, CHAP, PAP, EAP, ECP, IPCP, and many other concepts get tangled up, everyone gets confused. What I care about is the collaboration between the entities in the PPP protocol, not the state transition of the Protocol or the configuration of the service, and the code for the RFC, the kernel, the PPPD, and some of the network tools has to be read because no data is found.

The PPP protocol provides for the establishment, maintenance, and release of data link connections between two entities, which is responsible for functions such as traffic and error control, so it should belong to the Data Link layer protocol.

Under the PPP protocol, the physical layer, such as Ethernet and serial port, is above the network layer such as IP protocol. Here, for the lower level, we only discuss the situation of the serial port, for the upper level, we only discuss the TCP/IP situation. When sent, TCP/IP packets are routed through the serial port after PPP packaging. When receiving, the data from the serial port is escalated to the TCP/IP protocol layer after being unpacked by PPP.

The network protocol is implemented hierarchically, the upper layer generally only need to know its direct lower layer, only in very few cases use the indirect layer of the interface. For example, applications such as MMS, browser, and mail are programmed using the socket interface, which only needs to know the TCP/IP protocol, without needing to know the existence of the PPP protocol. This layered design simplifies the implementation of protocols and the development of applications.

The problem: The PPP protocol does not only provide simple data link layer functionality, it also provides extensions such as authentication (such as PAP/CHAP), data compression/decompression (such as CCP), and Data encryption/decryption (such as ECP). Applications require transparency and do not care about the presence of these extensions, and in turn, the PPP protocol processing module itself cannot handle these strategic things because it does not know the username/password, does not know whether to compress it, and does not know whether to encrypt it.

What to do? How do I use extended functionality when it is transparent to the application? God said, this problem must be solved! So the PPPD appeared. PPPD is a background service process (daemon), which is a process of user space, so it is natural to move the strategic content from the kernel's PPP protocol processing module to the PPPD. The PPPD implements control protocols for all authentication, compression/decompression, and encryption/decryption extensions.

PPPD is just an ordinary user process, how does it extend the PPP protocol? This is the convention between PPPD and the PPP protocol processing module in the kernel, which uses the most traditional means of communication between the kernel space and the user space: the device file.

The device file name is/DEV/PPP. Through the read system call, PPPD can read the PPP Protocol processing module Packet, of course, the PPP protocol processing module will only be processed by the PPPD packets sent to PPPD. Through the write system call, PPPD can pass the packet to be sent to the PPP protocol processing module. By Ioctrl the system call, PPPD can set the parameters of the PPP protocol and can establish/close the connection.

In PPPD, each protocol implementation is in a standalone C file, which typically implements the Protent interface, which is primarily used to process packets, and fsm_callbacks interfaces, which are primarily used for state switching of state machines. The receipt of the packet is handled uniformly by main.c:get_input, and then distributed to the specific protocol implementation according to the protocol type. The delivery of the packet is done by the protocol implementation by invoking the output function as needed.

Chat is a pppd with an auxiliary tool. Well, it's not a type of XChat, XChat is used to chat with people, and chat is used to establish conversations with GSM modules. Its implementation is relatively simple, it sends the AT command to the serial port, establish a session with the GSM module, so that the PPP protocol can transmit packets on the serial port.

The application sends TCP/IP packets through the socket interface, how do these TCP/IP packets flow through the PPP protocol processing module and then send it through the serial port? PPPD calls Ioctrl (Pppiocnewunit) in the Make_ppp_unit function to create a network interface (such as PPP0), and the PPP protocol module in the kernel, when processing pppiocnewunit, calls Register_ Netdev a network interface that registers PPP with the kernel, and the transport function of the network interface points to Ppp_start_xmit.

When the application sends data, the kernel locates the PPP network interface based on the IP address and routing table, and then calls the Ppp_start_xmit function, at which point the control is transferred to the PPP protocol processing module. Ppp_start_xmit calls the function ppp_xmit_process to send all the packets in the queue, Ppp_xmit_process calls Ppp_send_frame to send a single packet, Ppp_send_frame according to the settings, After calling compression and other extended processing, Ppp_push calls pch->chan->ops-> start_xmit to send the packet.

What is PCH->chan->ops->start_xmit? It is the specific transmission mode, for example, for the serial port to send the method is registered in the Ppp_async.c:ppp_asynctty_open ppp_async_send function, ppp_async_send ppp_async_push function call Tty->driver->write send data to the serial port.

The user data sending process is as follows:

The PPPD control protocol data sending process is as follows:

In turn, what is the case of receiving data? PPP_ASYNC.C at Initialization (ppp_async_init), calling Tty_register_ldisc registers the line procedure processing interface with the TTY, which is a set of callback functions that, when the serial TTY receives the data, calls back the Ppp_ldisc ppp_ The Asynctty_receive function receives data. Ppp_asynctty_receive calls Ppp_async_input to convert the data buffer to Sk_buff and into the receive queue ap->rqueue.

Ppp_async another Tasklet (ppp_async_process) specifically handles packets in the Receive Queue Ap->rqueue, Ppp_async_process is hung on the receive queue ap->rqueue, Once awakened, it calls the Ppp_input function to allow the PPP protocol processing module to process the packet.

In the Ppp_input function, the data is divided into two ways, one is to control protocol packets, put into the PCH->FILE.RQB queue, to PPPD processing. The other is the user data packet, after ppp_do_recv/ppp_receive_frame for PPP processing, and then submitted by NETIF_RX to the upper layer protocol processing, and finally passed through the socket to the application.

The data reception process is as follows:

The process of PPP protocol is basically clear, but there are still a lot of details to be studied.

Linux PPP data sending and receiving process