PPPoE
（Point to Point Protocol over Ethernet，基于以太網的點對點協議）的工作流程包含發現（Discovery）和會話（Session）兩個階段，發現階段是無狀態的，目的是獲得PPPoE終端（在局端的ADSL設備上）的以太網MAC地址，并建立一個惟一的PPPoE SESSION-ID。發現階段結束后，就進入標準的PPP會話階段。
1.發現階段（PPPoED：PPPoE Discovery）
1.1 PADI（PPPoE Active Discovery Initiation）
主機廣播發起分組，分組的目的地址為以太網的廣播地址 0xffffffffffff，CODE（代碼）字段值為0×09（PADI Code），SESSION-ID（會話ID）字段值為0x0000。PADI分組必須至少包含一個服務名稱類型的標簽（Service Name Tag，字段值為0x0101），向接入集中器提出所要求提供的服務。
1.2 PADO（PPPoE Active Discovery Offer）
接入集中器收到在服務范圍內的PADI分組，發送PPPoE有效發現提供包分組，以響應請求。其中CODE字段值為0×07（PADO Code），SESSION-ID字段值仍為0x0000。PADO分組必須包含一個接入集中器名稱類型的標簽（Access Concentrator Name Tag，字段值為0x0102），以及一個或多個服務名稱類型標簽，表明可向主機提供的服務種類。PADO和PADI的Host-Uniq Tag值相同。
1.3 PADR（PPPoE Active Discovery Request）
主機在可能收到的多個PADO分組中選擇一個合適的PADO分組，然后向所選擇的接入集中器發送PPPoE有效發現請求分組。其中CODE字段為0x19（PADR Code），SESSION_ID字段值仍為0x0000。PADR分組必須包含一個服務名稱類型標簽，確定向接入集線器（或交換機）請求的服務種類。當主機在指定的時間內沒有接收到PADO，它應該重新發送它的PADI分組，并且加倍等待時間，這個過程會被重復期望的次數。
1.4 PADS（PPPoE Active Discovery Session-confirmation）
接入集中器收到PADR分組后準備開始PPP會話，它發送一個PPPoE有效發現會話確認PADS分組。其中CODE字段值為0×65（PADS Code），SESSION-ID字段值為接入集中器所產生的一個惟一的PPPoE會話標識號碼。PADS分組也必須包含一個接入集中器名稱類型的標簽以確認向主機提供的服務。當主機收到PADS 分組確認后，雙方就進入PPP會話階段。PADS和PADR的Host-Uniq Tag值相同。
圖1 PPPoE的協商流程
2.會話階段（PPPoES：PPPoE Session）
PPP會話的建立，需要兩端的設備都發送LCP數據包來配置和測試數據通信鏈路。
用戶主機與接入集中器根據在發現階段所協商的PPP會話連接參數進行PPP會話。一旦PPPoE會話開始，PPP數據就可以以任何其他的PPP封裝形式發送。所有的以太網幀都是單播的。PPPoE會話的SESSION-ID一定不能改變，并且必須是發現階段分配的值。
2.1 LCP協商階段（LCP：Link Control Protocol）
LCP的Request主機和AC都要給對方發送，LCP協商階段完成最大傳輸單元（MTU），是否進行認證和采用何種認證方式（Authentication Type）的協商。
（1）LCP協議數據報文分類
鏈路配置報文：用來建立和配置一條鏈路，主要包括Configure-Request、Configure-Ack、Configure-Nak和Configure-Reject報文
鏈路維護報文：用來管理和調試鏈路，主要包括Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply和Discard-Request報文
鏈路終止報文：用來終止一條鏈路，主要包括Terminate-Request和Terminate-Reply報文
（2）LCP協商過程
LCP協商的過程如下：協商雙方互相發送一個LCP Config-Request報文，確認收到的Config-Request報文中的協商選項，根據這些選項的支持與接受情況，做出適當的回應。若兩端都回應了Config-ACK，則標志LCP鏈路建立成功，否則會繼續發送Request報文，直到對端回應了ACK報文為止。
圖2 LCP協商的基本過程
說明：
（1）Config-ACK：若完全支持對端的LCP選項，則回應Config-ACK報文，報文中必須完全協帶對端Request報文中的選項。
（2）Config-NAK：若支持對端的協商選項，但不認可該項協商的內容，則回應Config-NAK報文，在Config-NAK的選項中填上自己期望的內容，如:對端MRU值為1500，而自己期望MRU值為1492，則在Config-NAK報文中埴上自己的期望值1492。
（3）Config-Reject：若不能支持對端的協商選項，則回應Config-Reject報文，報文中帶上不能支持的選項，如Windows撥號器會協商CBCP（被叫回呼），而ME60不支持CBCP功能，則回將此選項拒絕掉。
2.2 認證階段（PPP Authentication：PAP/CHAP）
會話雙方通過LCP協商好的認證方法進行認證，如果認證通過了，才可以進行下面的網絡層的協商。認證過程在鏈路協商結束后就進行。
Ⅰ PAP（Password Authentication Protocol，口令認證協議）認證
PAP為兩次握手協議，它通過用戶名及口令來對用戶進行驗證。PAP驗證過程如下：
當兩端鏈路可相互傳輸數據時，被驗證方發送本端的用戶名及口令到驗證方，驗證方根據本端的用戶表（或Radius服務器）查看是否有此用戶，口令是否正確。如正確則會給對端發送Authenticate-ACK報文，通告對端已被允許進入下一階段協商；否則發送NAK報文，通告對端驗證失敗。此時，并不會直接將鏈路關閉。只有當驗證不過次數達到一定值（缺省為10）時，才會關閉鏈路。
PAP的特點是在網絡上以明文的方式傳遞用戶名及口令，如在傳輸過程中被截獲，便有可能對網絡安全造成極大的威脅。因此，它適用于對網絡安全要求相對較低的環境。
圖3 PAP認證流程
Ⅱ CHAP（Challenge Handshake Authentication Protocol，質詢握手認證協議）認證
CHAP為三次握手協議。只在網絡上傳輸用戶名，并不傳輸用戶口令，因此它的安全性要比PAP高。CHAP的驗證過程為：
首先由驗證方（Server）向被驗證方（Client）發送一些隨機產生的報文，并同時將本端的主機名附帶上一起發送給被驗證方。被驗證方接到對端對本端的驗證請求（Challenge）時，便根據此報文中驗證方的主機名和本端的用戶表查找用戶口令字，如找到用戶表中與驗證方主機名相同的用戶，便利用報文ID、此用戶的密鑰用Md5算法生成應答（Response），隨后將應答和自己的主機名送回。驗證方接到此應答后，用報文ID、本方保留的口令字（密鑰）和隨機報文用Md5算法得出結果，與被驗證方應答比較，根據比較結果返回相應的結果（ACK or NAK）
（1）接受認證端發送Challenge
（2）申請認證端發驗證請求報文
（3）接受認證端回應認證接受報文
經過以上三次報文交互后，CHAP認證完成。
圖4 CHAP認證流程
2.3 NCP協商階段（NCP：Network Control Protocol）
NCP有很多種，如IPCP、BCP、IPv6CP，最為常用的是IPCP（Internet Protocol Control Protocol）協議。NCP的主要功能是協商PPP報文的網絡層參數，如IP地址，DNS Server IP地址，WINS Server IP地址等。PPPoE用戶主要通過IPCP來獲取訪問網絡的IP地址或IP地址段。
NCP流程與LCP流程類似，用戶與ME設備之間互相發送NCP Config-Request報文并且互相回應NCP Config-Ack報文后，標志NCP己協商完，用戶上線成功，可以正常訪問網絡了。
IPCP的協商過程是基于PPP狀態機進行協商的。經過雙方協商，通過配置請求、配置確認、配置否認等包文交換配置信息，最終由initial (或closed)狀態變為Opened狀態。IPCP狀態變為Opened的條件必須是發送方和接收方都發送和接收過確認包文。
IPCP協商過程中，協商包文可包含多個選項，即參數。各個選項的拒絕或否認都不能影響IPCP的UP，IPCP可以無選項協商，無選項協商也同樣能夠UP。選項有IP Address、網關、掩碼等，其中IP Address是最重要的一個選項，有些廠家的實現必須這個選項得到確認，大多數廠家的實現允許這個選項為空。
NCP的基本協商流程見下圖：
圖5 NCP的基本協商流程
用戶和接入設備對IP服務階段的一些要求進行多次協商，以決定雙方都能夠接收的約定。
如：IP業務階段使用的IP壓縮協議等。雙方的協議是通過報文中包含的Option項進行協商的，每一個Option都是一個需要協商的問題。
最后雙方都需要對方答復Configure_Ack的同意報文。
2.4 會話維持（Session Keep-alive）
設備主動發送Echo Request進行PPPoE心跳保活，若3次未得到服務器的響應，則設備主動釋放地址。發LCP Echo Request 的時候，魔術字字段要和之前通信的Configure_Request使用的魔術字字段保持一致。
有些設備或終端不支持主動發送 Echo-Request 報文, 只能支持回應Echo-Reply報文。
2.5 會話結束（Session Termination）
PPPoE 還有一個PADT（PPPOE Active Discovery Terminate）分組，它可以在會話建立后的任何時候發送，來終止PPPoE會話，也就是會話釋放。它可以由主機或者接入集中器發送，目的地址填充為對端的以太網的MAC地址。
當對方接收到一個 PADT（PPPOE Active Discovery Terminate）分組，就不再允許使用這個會話來發送PPP業務。PADT分組不需要任何標簽，其CODE字段值為0xa7（PADT Code），SESSION-ID字段值為需要終止的PPP會話的會話標識號碼。在發送或接收PADT后，即使正常的PPP終止分組也不必發送。PPP對端應該使用PPP協議自身來終止PPPoE會話，但是當PPP不能使用時，可以使用PADT。
3.PPPoE接入流程示例
PPP狀態變遷如圖6所示：
圖6 PPP狀態變遷圖
以PPPoE-CHAP為例，PPP用戶接入流程如圖7所示：
圖7 PPPoE/CHAP接入認證流程
4.Linux中的PPPoE撥號守護進程
（pppd：Point-to-Point Protocol Daemon）
pppd是一個后臺服務進程(daemon)，是一個用戶空間的進程，所以把策略性的內容從內核的PPP協議處理模塊移到pppd中是很自然的事了。pppd實現了所有鑒權、壓縮/解壓和加密/解密等擴展功能的控制協議。
pppd只是一個普通的用戶進程，它如何擴展PPP協議呢？這就是pppd與內核中的PPP協議處理模塊之間約定了，它們之間采用了最傳統的內核空間與用戶空間之間通信方式：設備文件。
設備文件名是/dev/ppp。通過read系統調用，pppd可以讀取PPP協議處理模塊的數據包，當然，PPP協議處理模塊只會把應該由pppd處理的數據包發給pppd。通過write系統調用，pppd可以把要發送的數據包傳遞給PPP協議處理模塊。通過ioctrl系統調用，pppd可以設置PPP協議的參數，可以建立/關閉連接。
參考：
《PPP協議》
《PPP狀態機總結》
《PPP協議詳細解析》
《PPPoE協議篇》
《PPPoE通信協議》
《PPPoE拔號流程》
《PAP和CHAP認證》
《PPP-CHAP原理與配置》
《PPP的CHAP認證完全配置》
《PPPoE實例》
《PPPoE撥號過程抓包解析》
《PPPoE用戶上線交互過程》
《PPPoE協議技術與標準培訓教材》
《路由器如何設置PPPoE上網（ADSL虛擬撥號）》
《Linux系統修改PPPOE配置解決ADSL頻繁掉線問題》
《LinuxPPP實現源碼分析》
《Linux PPP 數據收發流程》
《PPPoE協議和pppd源碼分析》
《如何用Linux做PPPoE服務器》
《LinuxPPPoE設置的六個步驟》
《關于pppd移植和3g功能》
《移植——linux下使用3G撥號上網》
《成功實現Linux下pppd通過GPRS撥號上網》