基于Linux内核模式的PPPoE优化与实现

首先通过Raw socket发送PADS、PADR、PADO、PADI，当这个请求完成后，得到远端服务器的MAC地址以及双方建立起来的Session_ID。由于后面的内核封包需要用到这些数据，所以需要将这些数据切换到内核空间去。由于数据量较小，则采用proc文件系统完成内核空间与用户空间的数据切换。
对于proc中的数据，设计以下数据格式：接口名词SMAC DMAC SESSION_ID RX TX。
其中“接口名词”为接口名称，设计中不再用虚拟PPP接口传输数据，而是将数据迁移到物理网卡上，这样在某种程度上减轻了路由模块的负担，但需要去proc文件读取接口名称以此判断该物理接口是否启用PPPoE拨号。“SMAC”和“DMAC”参数为双方的MAC地址，在内核封包中用到。“SESSION_ID”双方建立起来的Session_ID，也用于内核封包。而“RX”和“TX”是用于记录最后一次解包与封包的时间点，该数据用于按需拨号。
在建立好PPP连接后就进行IPCP协商，这个过程将为协商到双方的IP的地址，并将这个IP地址配置到物理口上，而这些数据将通过PPP口通信。除此之外，还需要为PPPoE链路配置相应的路由、更新ARP列表以及获取相应的DNS服务器地址。
2．2 PPPoE数据接收
PPPoE数据接收主要是对数据进行解包，其全部动作在内核空间完成。当一个PPPoE数据包从网卡驱动里面读出来时，是一个完整的PPPoE包。而上层模块无法识别这样的包，所以需要将中间的那些PPP协议数据从包中剥离出来，使其变成一个普通的IP数据包，图4描述了PPPoE接收数据的整体流程。

当从网卡驱动上读取数据时，也就是获取数据的SKB，首先需要判断这个SKB是否有效，然后再判断该网卡是否起动了PPPoE服务，很显然这里需要读取proc的接口信息。如果已经PPPoE拨号服务，还需要判断该包是不是一个LCP或者IPCP等其他协商数据，也就是判断协议域的数据是不是0X0021。因为如果是协商数据，则不需要解包，而直接将其转发到PPP虚拟接口上。对于具体的解包过程将进行代码分析。解完包以后该数据包就属于普通的IP包，后续流程与普通的IP包处理相同。
2．3 PPPoE数据发送
PPPoE数据发送流程基本上是数据接收的逆过程，图5描述整个数据发送过程。首先从用户空间或者FORWARDING模块获取一个数据包，这个数据包属于正常的IP包。很显然这个包是无法发送到PPP链路上的，因为PPPoE服务器并不识别这样的数据包。所以需要利用proc文件中的Session_ID、远端MAC和本地MAC数据来封装IP包，使其成为一个标准的PPP包。