首先通過Raw socket發(fā)送PADS、PADR、PADO、PADI，當這個請求完成后，得到遠端服務器的MAC地址以及雙方建立起來的Session_ID。由于后面的內核封包需要用到這些數據，所以需要將這些數據切換到內核空間去。由于數據量較小，則采用proc文件系統(tǒng)完成內核空間與用戶空間的數據切換。
對于proc中的數據，設計以下數據格式：接口名詞SMAC DMAC SESSION_ID RX TX。
其中“接口名詞”為接口名稱，設計中不再用虛擬PPP接口傳輸數據，而是將數據遷移到物理網卡上，這樣在某種程度上減輕了路由模塊的負擔，但需要去proc文件讀取接口名稱以此判斷該物理接口是否啟用PPPoE撥號。“SMAC”和“DMAC”參數為雙方的MAC地址，在內核封包中用到。“SESSION_ID”雙方建立起來的Session_ID，也用于內核封包。而“RX”和“TX”是用于記錄最后一次解包與封包的時間點，該數據用于按需撥號。
在建立好PPP連接后就進行IPCP協(xié)商，這個過程將為協(xié)商到雙方的IP的地址，并將這個IP地址配置到物理口上，而這些數據將通過PPP口通信。除此之外，還需要為PPPoE鏈路配置相應的路由、更新ARP列表以及獲取相應的DNS服務器地址。
2．2 PPPoE數據接收
PPPoE數據接收主要是對數據進行解包，其全部動作在內核空間完成。當一個PPPoE數據包從網卡驅動里面讀出來時，是一個完整的PPPoE包。而上層模塊無法識別這樣的包，所以需要將中間的那些PPP協(xié)議數據從包中剝離出來，使其變成一個普通的IP數據包，圖4描述了PPPoE接收數據的整體流程。

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