摘? 要: 介紹了PPP協(xié)議原理、單片機PPP協(xié)議、單片機與PC機之間PPP連接的建立,程序流程等。

　　關(guān)鍵詞: PPP協(xié)議? 單片機? 單片機PPP協(xié)議

?

　　PPP協(xié)議(Point-to-Point Protocol)提供了在串行點對點鏈路" title="鏈路">鏈路上傳輸數(shù)據(jù)報的方法,支持異步8位數(shù)據(jù)及位導(dǎo)向的同步連接(如ISDN)。它提供了一種管理兩點間會話的有效方法，正在取代SLIP(Serial Line Interface Protocol)協(xié)議成為點對點網(wǎng)絡(luò)的標準。

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

1 PPP的工作原理

　　PPP采用高級數(shù)據(jù)鏈路控制(HDLC)協(xié)議作為在對點鏈路上分裝數(shù)據(jù)報的基本方法。使用可擴展的鏈路控制協(xié)議" title="控制協(xié)議">控制協(xié)議(LCP)來建立、配置和測試數(shù)據(jù)鏈路。用網(wǎng)絡(luò)控制協(xié)議簇(NCP)來建立和配置不同的網(wǎng)絡(luò)層" title="網(wǎng)絡(luò)層">網(wǎng)絡(luò)層協(xié)議,PPP允許同時采用多種網(wǎng)絡(luò)層協(xié)議。

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

?

?

1.1 連接死亡階段

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

1.2 連接建立階段

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

1.3? 認證階段

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

1.4 網(wǎng)絡(luò)層協(xié)議階段

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

1.5 終止連接階段

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

2 PPP數(shù)據(jù)結(jié)構(gòu)

　　PPP數(shù)據(jù)幀的結(jié)構(gòu)如表1所示,PPP協(xié)議標志如表2所示。

?

?

?

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

　　(1)當(dāng)遇到字符0x7E時,需連續(xù)傳送2個字符：0x7D和0x5E,以實現(xiàn)標志字符的轉(zhuǎn)義。

　　(2)當(dāng)遇到轉(zhuǎn)義字符0x7D時,需連續(xù)傳送2個字符：0x7D和0x5D,以實現(xiàn)轉(zhuǎn)義字符的轉(zhuǎn)義。

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

　　關(guān)于PPP協(xié)議的詳盡描述可以參閱RFC1661文檔。

3 單片機PPP協(xié)議

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

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

4 單片機PPP協(xié)議PPP連接的建立

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

?

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

單片機PPP協(xié)議流程圖如圖3所示。

?

?

　　PPP連接的建立主要經(jīng)過三個階段,分別是LCP協(xié)商、密碼認證以及網(wǎng)絡(luò)層協(xié)議配置。

4.1 LCP處理階段

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

　　下面是由服務(wù)器發(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數(shù)據(jù)包給服務(wù)器端,然后服務(wù)器端通過用戶ID和密碼驗證。

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

　　PAP的格式如圖4所示。

?

?

　　下面是單片機發(fā)送PAP的數(shù)據(jù)包:

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

　　解析如表4所示。

?

?

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

4.3 IPCP處理階段

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

　　連接建立后,PPP將在原有協(xié)議的基礎(chǔ)上調(diào)用網(wǎng)絡(luò)協(xié)議UDP(User Datagram Protocol)和ICMP(Internet Control Messages Protocol)等。有關(guān)用戶數(shù)據(jù)包協(xié)議UDP的詳細資料可參看RFC882、RFC883文檔;Internet信息控制協(xié)議ICMP的詳細資料可參看文檔RFC792。

?

參考文獻

1 Erkins D. Requirements for an Internet Standard Point-to-Point Protocol，RFC 1547.Carnegia Mellon University.December 1993.

2 Reynolds J， Postel J. Assigned Numbers，STD 2，RFC 1340.USC/Information Sciences Institute，July 1992.

3 Douglas E. Comer. Internetworking With TCP/IP Vol I：?Principles，Protocol and Architecture (Third Edition)

4 W.Simpson.STD 51,RFC1661.Network Working Group.July 1994

5 Douglas E. Comer， David L. Stevens. Internetworking With TCP/IP Vol II：Design，Implementation，and Internals?(Second Edition)