嵌入式單片機PPP協議的應用

PPP協議(Point-to-Point Protocol)提供了在串行點對點鏈路上傳輸數據報的方法，支持異步8位數據及位導向的同步連接(如ISDN)。它提供了一種管理兩點間會話的有效方法，正在取代SLIP（Serial Line Interface Protocol）協議成為點對點網絡的標準。

嵌入式單片機PPP協議是在單片機中嵌入PPP協議，以實現單片機與計算機之間的PPP數據傳輸，使它既可以作為PPP連接的客戶端，也可以作為獨立的PPP服務器端來使用。它在家電控制和小型數據傳輸系統(tǒng)中具有非常廣闊的應用前景，并且具有成本低、傳輸穩(wěn)定等特點，是當前單片機研究的熱門話題之一。

1 PPP的工作原理

PPP采用高級數據鏈路控制(HDLC)協議作為在對點鏈路上分裝數據報的基本方法。使用可擴展的鏈路控制協議(LCP)來建立、配置和測試數據鏈路。用網絡控制協議簇(NCP)來建立和配置不同的網絡層協議，PPP允許同時采用多種網絡層協議。

為了建立點對點鏈路上的通信連接，發(fā)送端PPP首先發(fā)送LCP幀，以配置和測試數據鏈路。在LCP建立好數據鏈路并協調好所選設備后，發(fā)送端PPP發(fā)送NCP幀，以選擇和配置一個或多個網絡層協議。當所選的網絡層協議配置好后，便可以將各網絡層協議的數據包發(fā)送到數據鏈路上。配置好的鏈路將一直處于通信狀態(tài)，直到LCP幀或NCP幀明確提示關閉鏈路，或有其它的外部事件發(fā)生。PPP連接狀態(tài)圖如圖1所示。

1.1 連接死亡階段

一個連接的開始和結束都要經歷這個階段。當一個外部事件指示物理層已準備好并可使用時，PPP進入建立連接階段。此時，LCP自動機處于初始階段。當它向鏈路建立階段轉換時將給LCP自動機發(fā)送一個UP事件信號。

1.2 連接建立階段

LCP用于交換配置信息包、建立連接。一旦一個配置成功的信息包發(fā)送且被接收，就完成了交換，進入LCP開啟狀態(tài)。所有的配置選項都假定使用默認值，除非在配置交換過程中被改變。只有那些與特定的網絡層協議無關的選項才會被LCP配置。收到LCP配置數據包將使鏈路從網絡層協議階段或者認證階段返回到鏈路建立階段。

1.3 認證階段

在某些連接情況下，希望在允許網絡層協議交換數據前對等實行認證。默認情況下，是不要求認證的。認證要求必須在建立連接階段提出，然后進入認證階段。如果認證失敗，將進入連接終止階段。在此階段只對連接協議、認證協議、連接質量測試數據包進行處理。

1.4 網絡層協議階段

一旦PPP完成上述階段，便進入網絡協議階段。每一個網絡層協議 (例如IP、IPX、AppleTalk等)必須有相應的網絡控制協議(NCP)單獨配置，每個網絡控制協議都可以隨時打開或關閉。此階段，LCP協議自動狀態(tài)機處于打開狀態(tài)，接收到的任何不支持的協議數據包都會被返回一個協議拒絕包，而接收到的所有支持的數據包都將被丟棄。此時，鏈路上流通的是LCP數據包、NCP數據包以及網絡協議數據包。

1.5 終止連接階段

PPP連接可以隨時被終止。LCP通過交換連接終止包來終止連接。當連接被終止時，PPP會通知物理層采取相應的動作。只有當物理層斷開，連接才會真正被終止。此階段，接收到的所有非LCP數據包都將被丟棄。

2 PPP數據結構

PPP數據幀的結構如表1所示，PPP協議標志如表2所示。



每個PPP數據包的開始和結束都有一個0x7E的數據標志。在開始標志后，緊跟2個HDLC常量：地址常量0xFF和控制常量0x03。協議域長度通常為2字節(jié)，表示信息域里包含的是哪種協議以及它的處理信息。隨后是代碼(Code)、標識符(ID)和長度域(Length)。事實上它們都是信息域(Payload)的一部分。信息域長度最多為1500字節(jié)。代碼部分用來指示LCP、PAP、IPCP或者CHAP協議數據包中的某種類型。通常情況下，用來表示IP自尋址信息數據包的標識是0x45。ID對于每一幀來說都是唯一的，所有協議間的商談和響應都通過ID聯系在一起。只有當PPP協議幀被壓縮成IP尋址信息包時例外。這個時候ID表示的是一種服務類型。有效載荷部分是可變的，并能隨著請求和響應的變化作相應的改變。在IP自尋址情況下，IP數據包的大小與PPP協議幀的大小是兼容的，有效載荷包含有關協議的商談和數據包的保持。然后是一個長度為2字節(jié)循環(huán)冗余檢驗碼，以檢測數據幀中的錯誤。由于標志字符的值是0x7E，因此當該字符出現在信息字段中時， PPP需要對它進行轉義。具體實現過程如下：

(1)當遇到字符0x7E時，需連續(xù)傳送2個字符：0x7D和0x5E，以實現標志字符的轉義。

(2)當遇到轉義字符0x7D時，需連續(xù)傳送2個字符：0x7D和0x5D，以實現轉義字符的轉義。

(3)默認情況下，如果字符的值小于0x20（例如ASCII控制字符），一般都要進行轉義。例如，遇到字符0x01時需連續(xù)傳送0x7D和0x21兩個字符(這時，第6個比特取補碼后變?yōu)?，而前面兩種情況均把它變?yōu)?)。這樣做是防止它們出現在雙方主機的串行接口驅動程序或調制解調器中，因為它們有時會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協議來指定是否需要對這32個字符中的某些值進行轉義。默認情況下是對所有的32個字符都進行轉義。

關于PPP協議的詳盡描述可以參閱RFC1661文檔。

3 單片機PPP協議

單片機PPP協議是PPP協議在單片機中的應用，有其特點。單片機的存儲空間只有64KB，而PPP協議包括LCP、PAP、IPCP以及NCP等協議，并且在連接建立后還要用到數據傳輸協議(TCP/IP、UDP等)、各種壓縮協議等。要把這些協議完全嵌入單片機是不可能的，所以只能根據實際需要選擇其中的一部分。

例如采用UDP協議而不是功能相對齊全但協議內容過于龐大的TCP/IP協議來傳輸數據，傳輸中基本上不使用數據壓縮協議，跳過單片機作為服務器端時的密碼驗證過程，省略IPX、AppleTalk等網絡層協議等。也就是說，本文的單片機PPP協議，事實上只包含了從PPP連接的建立到實現簡單的數據傳輸所必需的協議，而不包括PPP協議的所有功能。這種協議的取舍是由硬件的客觀限制以及實際的應用需要共同決定的。

4 單片機PPP協議PPP連接的建立

建立后的單片機PPP連接狀態(tài)如圖2所示。


其中，C51系統(tǒng)是已經植入PPP協議的51系列單片機，電話線部分也可以是某個網絡的一部分，甚至是Internet。

單片機PPP協議流程圖如圖3所示。


PPP連接的建立主要經過三個階段，分別是LCP協商、密碼認證以及網絡層協議配置。

4.1 LCP處理階段

首先，第一個LCP數據包被服務器端發(fā)送后，從服務器端返回一個PPP拒絕包給除密碼認證外的所有選項，接著服務器端強制認證協議進行協商(先前來自否定幀的PAP和CHAP都被發(fā)送)。隨后服務器端返回一個拒絕包給CHAP，本文用PAP來代替。然后服務器端認同并返回一個新的請求，這時候需要進行PAP。接下去對PAP進行確認，系統(tǒng)對字符映射的丟棄進行協商。最后所有控制特性被服務器端同意丟棄。

下面是由服務器發(fā)送的一段LCP建立連接的字符串：

0000：7E FF 03 C0 21 01 71 00 2B 01 04 06 40 05 06 3A 5D 8B B4 02 06 00
0016：00 00 00 11 04 06 40 17 04 00 64 00 02 03 04 C0 23 13 09 03 08 00
002C：03 0A 2C 2C 95 7F 7E

對它進行分析如表3。


4.2 PAP處理階段

首先，系統(tǒng)發(fā)送PAP數據包給服務器端，然后服務器端通過用戶ID和密碼驗證。

PAP密碼驗證協議在RFC1334中有詳細定義，主要是為撥號網絡中提供密碼保護。這個選項是可選的。在本應用軟件中，強制單片機和PC協商的選項中，PC要求密碼驗證，單片機端不要求。所以如果PC機作為服務器，單片機需要發(fā)送用戶名和密碼；如果單片機作服務器，則沒有密碼驗證的要求。

PAP的格式如圖4所示。


下面是單片機發(fā)送PAP的數據包：

7E FF 03 C0 23 01 06 00 0C 03 7A 77 6D 03 7A 77 6D…

解析如表4所示。


單片機向PC機發(fā)送PAP數據包是在PC機發(fā)送對單片機LCP選項的確認之后、PC機向單片機發(fā)送IPCP請求之前。

4.3 IPCP處理階段

IPCP是用來設置PPP連接中的網絡環(huán)境，包括IP地址、IP壓縮協議、DNS服務器地址等都是通過IPCP來協商的。首先服務器端發(fā)送請求進行IPCP協商，然后系統(tǒng)返回一個拒絕包給除IP地址外的所有操作。由于先前的發(fā)送被拒絕，服務器端發(fā)送一個回復，只包含IP地址。此時，系統(tǒng)相當于服務器端的IP地址認證，然后由請求信息和IP地址來完成三路握手協議。接著服務器端返回一個包含預先指派IP地址的拒絕包。此時連接建立并擁有一個指定的IP地址。IPCP幀的格式與LCP也是類似的：一字節(jié)的代碼，然后是標志，長度，選項。當IP協議的選項配置完，就可以開始通訊了。IPCP的詳細描述在RFC1332中。

連接建立后，PPP將在原有協議的基礎上調用網絡協議UDP(User Datagram Protocol)和ICMP(Internet Control Messages Protocol)等。有關用戶數據包協議UDP的詳細資料可參看RFC882、RFC883文檔；Internet信息控制協議ICMP的詳細資料可參看文檔RFC792。