PPPOE(Point．to．Point Protoeol over Ethernet)是將PPP協議封裝在以太網幀上進行傳輸，它的通信過程分為探測(Discovery)和PPP會話(Session)2個階段。PPPoE Discovery階段主要是客戶機確定AC(Access Concentrator)以及客戶機與AC協商Session ID。而PPPoE Sess-ion用于完成數據包的接收與發送，同時它也用于完成PPP鏈路的協商(LCP)，以及網絡層的控制協商(IPCP)等。
    傳統的PPPoE先會用Raw socket讀取數據，然后采用用戶態程序對其封包解包，然后再發送給內核。但是這種方法會引起大量的內核空間與用戶空間的上下文切換，從而帶來不必要的開銷。而對于實現于內核態的PPPoE，它會把所有的封包以及解包實現于內核，這樣就大大提高PPPoE的效率。

1 PPPoE協議概述
1. 1 PPPoE Discovery階段
    在PPPoE Discovery階段，客戶機首先廣播一個PADI(0x09)幀。收到PADI幀的一個或多個服務器會發送PADO(0x07)幀，這個包中包含了服務器的各種標識。然后，客戶機會選擇其中一個服務器發送PADR(0x19)，表明主機選擇了這個服務器。最終，收到PADR(0x65)幀的服務器會為新的會話分配資源并向客戶機發送PADS(0x65)。當此階段完成，這兩次的對話完成了SESSION_ID以及雙方物理地址，為后續數據會話打好基礎。
    同時PPP協議還提供了一個PADT請求，該請求用于結束這次PPPoE會話。這個請求可以由任何一方發出，同時代表這次回話的結束，圖1描述整個discovery過程。

1．2 PPPoE Session階段
    PPPoE Discovery階段是為整個PPPoE會話獲取雙方物理地址以及Session_ID，這個Session_ID就成為了雙方的通信憑證，在整個會話過程中保持不變。PPP幀數據被封在以太幀中，它在以太幀的標識為0x8864，當碰到0x8864時，就認為是一個PPPoE包。
    在PPPoE Session階段，PPPoE除數據傳輸以外，還提供了鏈路的協商(LCP)，以及網絡層的控制協商(IPCP)等其他服務。對于LCP，它主要用于配置和測試數據通信鏈路，用來協商PPP協議的一些配置參數選項；處理不同大小的數據幀：檢測鏈路環路和一些鏈路的錯誤；終止一條鏈路，其作用類似于IP層的ICMP協議。而對于IPCP，它主要用于動態地協商客戶機與服務器雙方IP，實際的數據報文交換過程中主要涉及Config-Request、Config-Ack、Config-Nak和Config-Re-ject。圖2描述IPCP協商IP的過程。

2 PPPOE設計實現
    從上述PPPoE協議描述中，了解到整個PPPoE會話包括Discovery、鏈路協商和數據傳輸3種交互。這3種數據中，數據傳輸最重要，數據量最大。對于用戶空間模式的PPPoE，數據包收發需要通過pty，由用戶空間的PPPoE進程處理PPPoE包頭后通過Raw socket收發。也就是說所有的PPPoE數據封包結果都在用戶空間執行，這樣就大大增加了內核空間與用戶空間數據切換的次數。為了減少這種開銷。這里采用一個內核模塊來處理數據的封包解包，這樣就大大減少了內核空間與用戶空間數據切換的次數，提高效率。所以對內核空間模式的PPPoE的處理策略是：Discovery以及鏈路協商交互全部在用戶空間完成，而數據的封解包則通過一個內核模塊在內核空間完成。
2．1 PPPoE會話初始化
    PPPoE的初始化包括整個Discovery階段以及Session階段的IPCP和LCP等其他鏈路協商過程，所有的工作都在用戶空間完成，圖3描述了整個初始化的流程。

    首先通過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包。

2．4 核心代碼實現
    整個PPPoE內核模式撥號的核心代碼主要集中在內核模塊上，該模塊主要功能有proc文件讀寫、數據包的封裝、解包等操作，下面是這個內核模塊的包封裝的部分程序。


    以上只是部分代碼，由于代碼太多，而且很多代碼和項目的硬件抽象層模塊(HAL)息息相關，所以在此不再詳細闡述。具體可以參考Lin-ux內核中pppoe模塊里面的代碼，雖然工作的層次有點不一樣，但是總體的思路是一樣的，本文的實現代碼基本上也是參考的Linux內核中PP-PoE的代碼。

3 結束語
    本文主要描述了PPPoE內核模式撥號的設計與實現，該模式將封包動作從用戶空間轉移到內核空間，從而大大降低了內核空間與用戶空間切換的次數，目前這種內核模式下的撥號已經大量地應用于各種網關產品中。雖然PPPoE是一種非常成熟的技術，Linux內核也已開始支持PP-PoE內核態撥號，同時由卡耐基梅隆大學開發的PPPD開源項目已經廣泛應用于各種網關產品中，但是熟悉整個內核態撥號的流程是非常重要的，同時PPPD目前還存在一些BUG，在項目開發的過程中還需做大量修改。本文提供解決方案有別于傳統的通過PPP虛擬接口來傳輸數據的方案，在某種程度上也降低了路由模塊的工作任務，尤其是需要實現多路PPPoE的時候。另外該設計方案在Linux2．6．18上已經成功通過測試，并投入使用。