基于Linux內(nèi)核模式的PPPoE優(yōu)化與實(shí)現(xiàn)

首先通過Raw socket發(fā)送PADS、PADR、PADO、PADI，當(dāng)這個請求完成后，得到遠(yuǎn)端服務(wù)器的MAC地址以及雙方建立起來的Session_ID。由于后面的內(nèi)核封包需要用到這些數(shù)據(jù)，所以需要將這些數(shù)據(jù)切換到內(nèi)核空間去。由于數(shù)據(jù)量較小，則采用proc文件系統(tǒng)完成內(nèi)核空間與用戶空間的數(shù)據(jù)切換。
對于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撥號。“SMAC”和“DMAC”參數(shù)為雙方的MAC地址，在內(nèi)核封包中用到。“SESSION_ID”雙方建立起來的Session_ID，也用于內(nèi)核封包。而“RX”和“TX”是用于記錄最后一次解包與封包的時(shí)間點(diǎn)，該數(shù)據(jù)用于按需撥號。
在建立好PPP連接后就進(jìn)行IPCP協(xié)商，這個過程將為協(xié)商到雙方的IP的地址，并將這個IP地址配置到物理口上，而這些數(shù)據(jù)將通過PPP口通信。除此之外，還需要為PPPoE鏈路配置相應(yīng)的路由、更新ARP列表以及獲取相應(yīng)的DNS服務(wù)器地址。
2．2 PPPoE數(shù)據(jù)接收
PPPoE數(shù)據(jù)接收主要是對數(shù)據(jù)進(jìn)行解包，其全部動作在內(nèi)核空間完成。當(dāng)一個PPPoE數(shù)據(jù)包從網(wǎng)卡驅(qū)動里面讀出來時(shí)，是一個完整的PPPoE包。而上層模塊無法識別這樣的包，所以需要將中間的那些PPP協(xié)議數(shù)據(jù)從包中剝離出來，使其變成一個普通的IP數(shù)據(jù)包，圖4描述了PPPoE接收數(shù)據(jù)的整體流程。

當(dāng)從網(wǎng)卡驅(qū)動上讀取數(shù)據(jù)時(shí)，也就是獲取數(shù)據(jù)的SKB，首先需要判斷這個SKB是否有效，然后再判斷該網(wǎng)卡是否起動了PPPoE服務(wù)，很顯然這里需要讀取proc的接口信息。如果已經(jīng)PPPoE撥號服務(wù)，還需要判斷該包是不是一個LCP或者IPCP等其他協(xié)商數(shù)據(jù)，也就是判斷協(xié)議域的數(shù)據(jù)是不是0X0021。因?yàn)槿绻菂f(xié)商數(shù)據(jù)，則不需要解包，而直接將其轉(zhuǎn)發(fā)到PPP虛擬接口上。對于具體的解包過程將進(jìn)行代碼分析。解完包以后該數(shù)據(jù)包就屬于普通的IP包，后續(xù)流程與普通的IP包處理相同。
2．3 PPPoE數(shù)據(jù)發(fā)送
PPPoE數(shù)據(jù)發(fā)送流程基本上是數(shù)據(jù)接收的逆過程，圖5描述整個數(shù)據(jù)發(fā)送過程。首先從用戶空間或者FORWARDING模塊獲取一個數(shù)據(jù)包，這個數(shù)據(jù)包屬于正常的IP包。很顯然這個包是無法發(fā)送到PPP鏈路上的，因?yàn)镻PPoE服務(wù)器并不識別這樣的數(shù)據(jù)包。所以需要利用proc文件中的Session_ID、遠(yuǎn)端MAC和本地MAC數(shù)據(jù)來封裝IP包，使其成為一個標(biāo)準(zhǔn)的PPP包。