怎樣設(shè)計(jì)并實(shí)現(xiàn)一個(gè)基于Linux的PPPoE內(nèi)核模式撥號(hào)？

PPPoE（Point．to．Point Protoeol over Ethernet）是將PPP協(xié)議封裝在以太網(wǎng)幀上進(jìn)行傳輸，它的通信過(guò)程分為探測(cè)（Discovery）和PPP會(huì)話（Session）2個(gè)階段。PPPoE Discovery階段主要是客戶機(jī)確定AC（Access Concentrator）以及客戶機(jī)與AC協(xié)商Session ID。而PPPoE Sess-ion用于完成數(shù)據(jù)包的接收與發(fā)送，同時(shí)它也用于完成PPP鏈路的協(xié)商（LCP），以及網(wǎng)絡(luò)層的控制協(xié)商（IPCP）等。

傳統(tǒng)的PPPoE先會(huì)用Raw socket讀取數(shù)據(jù)，然后采用用戶態(tài)程序?qū)ζ浞獍獍缓笤侔l(fā)送給內(nèi)核。但是這種方法會(huì)引起大量的內(nèi)核空間與用戶空間的上下文切換，從而帶來(lái)不必要的開(kāi)銷(xiāo)。而對(duì)于實(shí)現(xiàn)于內(nèi)核態(tài)的PPPoE，它會(huì)把所有的封包以及解包實(shí)現(xiàn)于內(nèi)核，這樣就大大提高PPPoE的效率。

1 PPPoE協(xié)議概述

1. 1 PPPoE Discovery階段

在PPPoE Discovery階段，客戶機(jī)首先廣播一個(gè)PADI（0x09）幀。收到PADI幀的一個(gè)或多個(gè)服務(wù)器會(huì)發(fā)送PADO（0x07）幀，這個(gè)包中包含了服務(wù)器的各種標(biāo)識(shí)。然后，客戶機(jī)會(huì)選擇其中一個(gè)服務(wù)器發(fā)送PADR（0x19），表明主機(jī)選擇了這個(gè)服務(wù)器。最終，收到PADR（0x65）幀的服務(wù)器會(huì)為新的會(huì)話分配資源并向客戶機(jī)發(fā)送PADS（0x65）。當(dāng)此階段完成，這兩次的對(duì)話完成了SESSION_ID以及雙方物理地址，為后續(xù)數(shù)據(jù)會(huì)話打好基礎(chǔ)。

同時(shí)PPP協(xié)議還提供了一個(gè)PADT請(qǐng)求，該請(qǐng)求用于結(jié)束這次PPPoE會(huì)話。這個(gè)請(qǐng)求可以由任何一方發(fā)出，同時(shí)代表這次回話的結(jié)束，圖1描述整個(gè)discovery過(guò)程。

1．2 PPPoE Session階段

PPPoE Discovery階段是為整個(gè)PPPoE會(huì)話獲取雙方物理地址以及Session_ID，這個(gè)Session_ID就成為了雙方的通信憑證，在整個(gè)會(huì)話過(guò)程中保持不變。PPP幀數(shù)據(jù)被封在以太幀中，它在以太幀的標(biāo)識(shí)為0x8864，當(dāng)碰到0x8864時(shí)，就認(rèn)為是一個(gè)PPPoE包。

在PPPoE Session階段，PPPoE除數(shù)據(jù)傳輸以外，還提供了鏈路的協(xié)商（LCP），以及網(wǎng)絡(luò)層的控制協(xié)商（IPCP）等其他服務(wù)。對(duì)于LCP，它主要用于配置和測(cè)試數(shù)據(jù)通信鏈路，用來(lái)協(xié)商PPP協(xié)議的一些配置參數(shù)選項(xiàng)；處理不同大小的數(shù)據(jù)幀：檢測(cè)鏈路環(huán)路和一些鏈路的錯(cuò)誤；終止一條鏈路，其作用類(lèi)似于IP層的ICMP協(xié)議。而對(duì)于IPCP，它主要用于動(dòng)態(tài)地協(xié)商客戶機(jī)與服務(wù)器雙方IP，實(shí)際的數(shù)據(jù)報(bào)文交換過(guò)程中主要涉及Config-Request、Config-Ack、Config-Nak和Config-Re-ject。圖2描述IPCP協(xié)商IP的過(guò)程。

2 PPPOE設(shè)計(jì)實(shí)現(xiàn)

從上述PPPoE協(xié)議描述中，了解到整個(gè)PPPoE會(huì)話包括Discovery、鏈路協(xié)商和數(shù)據(jù)傳輸3種交互。這3種數(shù)據(jù)中，數(shù)據(jù)傳輸最重要，數(shù)據(jù)量最大。對(duì)于用戶空間模式的PPPoE，數(shù)據(jù)包收發(fā)需要通過(guò)pty，由用戶空間的PPPoE進(jìn)程處理PPPoE包頭后通過(guò)Raw socket收發(fā)。也就是說(shuō)所有的PPPoE數(shù)據(jù)封包結(jié)果都在用戶空間執(zhí)行，這樣就大大增加了內(nèi)核空間與用戶空間數(shù)據(jù)切換的次數(shù)。為了減少這種開(kāi)銷(xiāo)。這里采用一個(gè)內(nèi)核模塊來(lái)處理數(shù)據(jù)的封包解包，這樣就大大減少了內(nèi)核空間與用戶空間數(shù)據(jù)切換的次數(shù)，提高效率。所以對(duì)內(nèi)核空間模式的PPPoE的處理策略是：Discovery以及鏈路協(xié)商交互全部在用戶空間完成，而數(shù)據(jù)的封解包則通過(guò)一個(gè)內(nèi)核模塊在內(nèi)核空間完成。

2．1 PPPoE會(huì)話初始化

PPPoE的初始化包括整個(gè)Discovery階段以及Session階段的IPCP和LCP等其他鏈路協(xié)商過(guò)程，所有的工作都在用戶空間完成，圖3描述了整個(gè)初始化的流程。

首先通過(guò)Raw socket發(fā)送PADS、PADR、PADO、PADI，當(dāng)這個(gè)請(qǐng)求完成后，得到遠(yuǎn)端服務(wù)器的MAC地址以及雙方建立起來(lái)的Session_ID。由于后面的內(nèi)核封包需要用到這些數(shù)據(jù)，所以需要將這些數(shù)據(jù)切換到內(nèi)核空間去。由于數(shù)據(jù)量較小，則采用proc文件系統(tǒng)完成內(nèi)核空間與用戶空間的數(shù)據(jù)切換。

對(duì)于proc中的數(shù)據(jù)，設(shè)計(jì)以下數(shù)據(jù)格式：接口名詞SMAC DMAC SESSION_ID RX TX。

其中“接口名詞”為接口名稱，設(shè)計(jì)中不再用虛擬PPP接口傳輸數(shù)據(jù)，而是將數(shù)據(jù)遷移到物理網(wǎng)卡上，這樣在某種程度上減輕了路由模塊的負(fù)擔(dān)，但需要去proc文件讀取接口名稱以此判斷該物理接口是否啟用PPPoE撥號(hào)?！癝MAC”和“DMAC”參數(shù)為雙方的MAC地址，在內(nèi)核封包中用到?！癝ESSION_ID”雙方建立起來(lái)的Session_ID，也用于內(nèi)核封包。而“RX”和“TX”是用于記錄最后一次解包與封包的時(shí)間點(diǎn)，該數(shù)據(jù)用于按需撥號(hào)。

在建立好PPP連接后就進(jìn)行IPCP協(xié)商，這個(gè)過(guò)程將為協(xié)商到雙方的IP的地址，并將這個(gè)IP地址配置到物理口上，而這些數(shù)據(jù)將通過(guò)PPP口通信。除此之外，還需要為PPPoE鏈路配置相應(yīng)的路由、更新ARP列表以及獲取相應(yīng)的DNS服務(wù)器地址。

2．2 PPPoE數(shù)據(jù)接收

PPPoE數(shù)據(jù)接收主要是對(duì)數(shù)據(jù)進(jìn)行解包，其全部動(dòng)作在內(nèi)核空間完成。當(dāng)一個(gè)PPPoE數(shù)據(jù)包從網(wǎng)卡驅(qū)動(dòng)里面讀出來(lái)時(shí)，是一個(gè)完整的PPPoE包。而上層模塊無(wú)法識(shí)別這樣的包，所以需要將中間的那些PPP協(xié)議數(shù)據(jù)從包中剝離出來(lái)，使其變成一個(gè)普通的IP數(shù)據(jù)包，圖4描述了PPPoE接收數(shù)據(jù)的整體流程。

當(dāng)從網(wǎng)卡驅(qū)動(dòng)上讀取數(shù)據(jù)時(shí)，也就是獲取數(shù)據(jù)的SKB，首先需要判斷這個(gè)SKB是否有效，然后再判斷該網(wǎng)卡是否起動(dòng)了PPPoE服務(wù)，很顯然這里需要讀取proc的接口信息。如果已經(jīng)PPPoE撥號(hào)服務(wù)，還需要判斷該包是不是一個(gè)LCP或者IPCP等其他協(xié)商數(shù)據(jù)，也就是判斷協(xié)議域的數(shù)據(jù)是不是0X0021。因?yàn)槿绻菂f(xié)商數(shù)據(jù)，則不需要解包，而直接將其轉(zhuǎn)發(fā)到PPP虛擬接口上。對(duì)于具體的解包過(guò)程將進(jìn)行代碼分析。解完包以后該數(shù)據(jù)包就屬于普通的IP包，后續(xù)流程與普通的IP包處理相同。

2．3 PPPoE數(shù)據(jù)發(fā)送

PPPoE數(shù)據(jù)發(fā)送流程基本上是數(shù)據(jù)接收的逆過(guò)程，圖5描述整個(gè)數(shù)據(jù)發(fā)送過(guò)程。首先從用戶空間或者FORWARDING模塊獲取一個(gè)數(shù)據(jù)包，這個(gè)數(shù)據(jù)包屬于正常的IP包。很顯然這個(gè)包是無(wú)法發(fā)送到PPP鏈路上的，因?yàn)镻PPoE服務(wù)器并不識(shí)別這樣的數(shù)據(jù)包。所以需要利用proc文件中的Session_ID、遠(yuǎn)端MAC和本地MAC數(shù)據(jù)來(lái)封裝IP包，使其成為一個(gè)標(biāo)準(zhǔn)的PPP包。

2．4 核心代碼實(shí)現(xiàn)

整個(gè)PPPoE內(nèi)核模式撥號(hào)的核心代碼主要集中在內(nèi)核模塊上，該模塊主要功能有proc文件讀寫(xiě)、數(shù)據(jù)包的封裝、解包等操作，下面是這個(gè)內(nèi)核模塊的包封裝的部分程序。

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

3 結(jié)束語(yǔ)

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