ppp/pppd/chat关系及数据收发流程

stone_pub

参考：
http://blog.csdn.net/absurd
李先静

一、 协议相关介绍
PPP（Point-to-Point Protocol点到点协议）是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作，并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。

• 链路控制协议LCP（Link Control Protocol）；
  
• 网络控制协议NCP（Network Control Protocol）；
  
• 认证协议：口令验证协议PAP（Password Authentication Protocol）和挑战握手验证协议CHAP（Challenge-Handshake Authentication Protocol）。

LCP协商，协商内容包括除
RFC
1661中所定义的选项之外，还要考虑
PPP
OA和
PPP
OE
协议
中规定的内容。

LCP协商过后就到了Establish阶段，开始PAP或CHAP认证。PAP为两次握手认证，口令为明文。PAP认证过程如下：发送用户名同口令到认证方，认证方查看是否有此用户，口令是否正确，然后发送相应的响应。CHAP为三次握手认证，口令为密文（密钥）CHAP认证由认证方发送一些随机产生的报文，交给被认证，被认证方用自己的口令字用MD5算法进行加密，传回密文，认证方用自己保存的口令字及随机报文用MD5算法加密，比较二者的密文，根据比较结果返回响应的响应。

认证成功即进行Network阶段协商（NCP），在IP接入中主要是IPCP协商（如IP地址和
DNS
地址的协商等）。任何阶段的协商失败都将导致链路的拆除。

协商成功，则链路建立成功，可以开始传输网络层数据报文。

PPPoE（PPP over Ethernet），PPPoA（PPP over ATM）

二、应用关系
IP协议等网络层                     TCP/IP
PPP协议（PPPD协助)                 PPP
以太网和串口等物理层               串口


pppd是一个后台服务进程(daemon)，是一个用户空间的进程，所以把策略性的内容从内核的PPP协议处理模块移到pppd中是很自然的事了。pppd实现了所有鉴权、压缩/解压和加密/解密等扩展功能的控制协议。



pppd是一个普通的用户进程，pppd与内核中的PPP协议处理模块之间采用最传统的内核空间与用户空间之间通信方式：设备文件;设备文件名是/dev/ppp。通过read系统调用，pppd可以读取PPP协议处理模块的数据包，当然，PPP协议处理模块只会把应该由pppd处理的数据包发给pppd。通过write系统调用，pppd可以把要发送的数据包传递给PPP协议处理模块。通过ioctrl系统调用，pppd可以设置PPP协议的参数，可以建立/关闭连接。

在pppd里，每种协议实现都在独立的C文件中，它们通常要实现protent接口，该接口主要用于处理数据包，和fsm_callbacks接口，该接口主要用于状态机的状态切换。数据包的接收是由main.c: get_input统一处理的，然后根据协议类型分发到具体的协议实现上。而数据包的发送则是协议实现者根据需要调用output函数完成的。

chat是pppd所带一个辅助工具。chat用来与GSM模组建立会话。它的实现比较简单，它向串口发送AT命令，建立与GSM模组的会话，以便让PPP协议可以在串口上传输数据包。

三、数据收发流程
应用程序通过socket接口发送TCP/IP数据包，这些TCP/IP数据包如何流经PPP协议处理模块，然后通过串口发送出去呢？pppd在make_ppp_unit函数中调用ioctrl(PPPIOCNEWUNIT)创建一个网络接口（如ppp0），内核中的PPP协议模块在处理PPPIOCNEWUNIT时，调用register_netdev向内核注册ppp的网络接口，该网络接口的传输函数指向ppp_start_xmit。

当应用程序发送数据时，内核根据IP地址和路由表，找到ppp网络接口，然后调用ppp_start_xmit函数，此时控制就转移到PPP协议处理模块了。ppp_start_xmit调用函数ppp_xmit_process去发送队列中的所有数据包，ppp_xmit_process又调用ppp_send_frame去发送单个数据包，ppp_send_frame根据设置，调用压缩等扩展处理之后，又经ppp_push调用pch->chan->ops->start_xmit发送数据包。

pch->chan->ops->start_xmit是什么？它就是具体的传输方式了，比如说对于串口发送方式，则是ppp_async.c: ppp_asynctty_open中注册的ppp_async_send函数，ppp_async_send经ppp_async_push函数调用tty->driver->write把数据发送串口。


1.用户数据发送过程如下所示：

   应用程序                                          pppd
       |                                                           |
       |                                                          |
   socket                                           /dev/ppp
           |                                                |
           |                                                |
                             PPP协议模块
                                      |
                                      |
                                   tty
                                     |
                                     |
                               GSM模组

2.pppd的控制协议数据发送过程：
pppd --Pap/chap/eap(etc)--> /dev/ppp --> PPP协议模块 --> tty --> GSM模组

3.接收数据流程：
ppp_async.c在初始化时(ppp_async_init)，调用tty_register_ldisc向tty注册了行规程处理接口，也就是一组回调函数，当串口tty收到数据时，它就会回调ppp_ldisc的ppp_asynctty_receive函数接收数据。ppp_asynctty_receive调用ppp_async_input把数据buffer转换成sk_buff，并放入接收队列ap->rqueue中。

ppp_async另外有一个tasklet(ppp_async_process)专门处理接收队列ap->rqueue中的数据包，ppp_async_process一直挂在接收队列ap->rqueue上，一旦被唤醒，它就调用ppp_input函数让PPP协议处理模块处理该数据包。

在ppp_input函数中，数据被分成两路，一路是控制协议数据包，放入pch->file.rqb队列，交给pppd处理。另外一路是用户数据包，经ppp_do_recv/ppp_receive_frame进行PPP处理之后，再由netif_rx提交给上层协议处理，最后经socket传递到应用程序。

   应用程序                                          pppd
       |                                               |
       |                                              |
   socket                                           /dev/ppp
          |                                         |
           |                                        |
                             PPP协议模块
                                  |
                                  |
                                  tty
                                   |
                                   |
                               GSM模组


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/61797/showart_483931.html