嵌入式單片機(jī)PPP協(xié)議的應(yīng)用研究

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

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

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

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

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

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

4.1 LCP處理階段

首先，第一個(gè)LCP數(shù)據(jù)包被服務(wù)器端發(fā)送后，從服務(wù)器端返回一個(gè)PPP拒絕包給除密碼認(rèn)證外的所有選項(xiàng)，接著服務(wù)器端強(qiáng)制認(rèn)證協(xié)議進(jìn)行協(xié)商(先前來(lái)自否定幀的PAP和CHAP都被發(fā)送)。隨后服務(wù)器端返回一個(gè)拒絕包給CHAP，本文用PAP來(lái)代替。然后服務(wù)器端認(rèn)同并返回一個(gè)新的請(qǐng)求，這時(shí)候需要進(jìn)行PAP。接下去對(duì)PAP進(jìn)行確認(rèn)，系統(tǒng)對(duì)字符映射的丟棄進(jìn)行協(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

對(duì)它進(jìn)行分析如表3。

4.2 PAP處理階段

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

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

PAP的格式如圖4所示。

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

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

解析如表4所示。

單片機(jī)向PC機(jī)發(fā)送PAP數(shù)據(jù)包是在PC機(jī)發(fā)送對(duì)單片機(jī)LCP選項(xiàng)的確認(rèn)之后、PC機(jī)向單片機(jī)發(fā)送IPCP請(qǐng)求之前。

4.3 IPCP處理階段

IPCP是用來(lái)設(shè)置PPP連接中的網(wǎng)絡(luò)環(huán)境，包括IP地址、IP壓縮協(xié)議、DNS服務(wù)器地址等都是通過(guò)IPCP來(lái)協(xié)商的。首先服務(wù)器端發(fā)送請(qǐng)求進(jìn)行IPCP協(xié)商，然后系統(tǒng)返回一個(gè)拒絕包給除IP地址外的所有操作。由于先前的發(fā)送被拒絕，服務(wù)器端發(fā)送一個(gè)回復(fù)，只包含IP地址。此時(shí)，系統(tǒng)相當(dāng)于服務(wù)器端的IP地址認(rèn)證，然后由請(qǐng)求信息和IP地址來(lái)完成三路握手協(xié)議。接著服務(wù)器端返回一個(gè)包含預(yù)先指派IP地址的拒絕包。此時(shí)連接建立并擁有一個(gè)指定的IP地址。IPCP幀的格式與LCP也是類似的：一字節(jié)的代碼，然后是標(biāo)志，長(zhǎng)度，選項(xiàng)。當(dāng)IP協(xié)議的選項(xiàng)配置完，就可以開(kāi)始通訊了。IPCP的詳細(xì)描述在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的詳細(xì)資料可參看RFC882、RFC883文檔；Internet信息控制協(xié)議ICMP的詳細(xì)資料可參看文檔RFC792。

參考文獻(xiàn)

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)

6PAPdatasheethttp://www.dzsc.com/datasheet/PAP_2058949.html.