嵌入式單片機(jī)PPP協(xié)議的應(yīng)用
加入技術(shù)交流群
(3)默認(rèn)情況下，如果字符的值小于0x20（例如ASCII控制字符），一般都要進(jìn)行轉(zhuǎn)義。例如，遇到字符0x01時(shí)需連續(xù)傳送0x7D和0x21兩個(gè)字符(這時(shí)，第6個(gè)比特取補(bǔ)碼后變?yōu)?，而前面兩種情況均把它變?yōu)?)。這樣做是防止它們出現(xiàn)在雙方主機(jī)的串行接口驅(qū)動程序或調(diào)制解調(diào)器中，因?yàn)樗鼈冇袝r(shí)會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協(xié)議來指定是否需要對這32個(gè)字符中的某些值進(jìn)行轉(zhuǎn)義。默認(rèn)情況下是對所有的32個(gè)字符都進(jìn)行轉(zhuǎn)義。
關(guān)于PPP協(xié)議的詳盡描述可以參閱RFC1661文檔。
3 單片機(jī)PPP協(xié)議
單片機(jī)PPP協(xié)議是PPP協(xié)議在單片機(jī)中的應(yīng)用，有其特點(diǎn)。單片機(jī)的存儲空間只有64KB，而PPP協(xié)議包括LCP、PAP、IPCP以及NCP等協(xié)議，并且在連接建立后還要用到數(shù)據(jù)傳輸協(xié)議(TCP/IP、UDP等)、各種壓縮協(xié)議等。要把這些協(xié)議完全嵌入單片機(jī)是不可能的，所以只能根據(jù)實(shí)際需要選擇其中的一部分。
例如采用UDP協(xié)議而不是功能相對齊全但協(xié)議內(nèi)容過于龐大的TCP/IP協(xié)議來傳輸數(shù)據(jù)，傳輸中基本上不使用數(shù)據(jù)壓縮協(xié)議，跳過單片機(jī)作為服務(wù)器端時(shí)的密碼驗(yàn)證過程，省略IPX、AppleTalk等網(wǎng)絡(luò)層協(xié)議等。也就是說，本文的單片機(jī)PPP協(xié)議，事實(shí)上只包含了從PPP連接的建立到實(shí)現(xià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)過三個(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é)商(先前來自否定幀的PAP和CHAP都被發(fā)送)。隨后服務(wù)器端返回一個(gè)拒絕包給CHAP，本文用PAP來代替。然后服務(wù)器端認(rèn)同并返回一個(gè)新的請求，這時(shí)候需要進(jìn)行PAP。接下去對PAP進(jìn)行確認(rèn)，系統(tǒng)對字符映射的丟棄進(jìn)行協(xié)商。最后所有控制特性被服務(wù)器端同意丟棄。
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解（linux不再難懂）
評論