嵌入式單片機PPP協(xié)議的應用
加入技術交流群
(3)默認情況下，如果字符的值小于0x20（例如ASCII控制字符），一般都要進行轉義。例如，遇到字符0x01時需連續(xù)傳送0x7D和0x21兩個字符(這時，第6個比特取補碼后變?yōu)?，而前面兩種情況均把它變?yōu)?)。這樣做是防止它們出現在雙方主機的串行接口驅動程序或調制解調器中，因為它們有時會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協(xié)議來指定是否需要對這32個字符中的某些值進行轉義。默認情況下是對所有的32個字符都進行轉義。
關于PPP協(xié)議的詳盡描述可以參閱RFC1661文檔。
3 單片機PPP協(xié)議
單片機PPP協(xié)議是PPP協(xié)議在單片機中的應用，有其特點。單片機的存儲空間只有64KB，而PPP協(xié)議包括LCP、PAP、IPCP以及NCP等協(xié)議，并且在連接建立后還要用到數據傳輸協(xié)議(TCP/IP、UDP等)、各種壓縮協(xié)議等。要把這些協(xié)議完全嵌入單片機是不可能的，所以只能根據實際需要選擇其中的一部分。
例如采用UDP協(xié)議而不是功能相對齊全但協(xié)議內容過于龐大的TCP/IP協(xié)議來傳輸數據，傳輸中基本上不使用數據壓縮協(xié)議，跳過單片機作為服務器端時的密碼驗證過程，省略IPX、AppleTalk等網絡層協(xié)議等。也就是說，本文的單片機PPP協(xié)議，事實上只包含了從PPP連接的建立到實現簡單的數據傳輸所必需的協(xié)議，而不包括PPP協(xié)議的所有功能。這種協(xié)議的取舍是由硬件的客觀限制以及實際的應用需要共同決定的。
4 單片機PPP協(xié)議PPP連接的建立
建立后的單片機PPP連接狀態(tài)如圖2所示。
|
其中，C51系統(tǒng)是已經植入PPP協(xié)議的51系列單片機，電話線部分也可以是某個網絡的一部分，甚至是Internet。
單片機PPP協(xié)議流程圖如圖3所示。
|
PPP連接的建立主要經過三個階段，分別是LCP協(xié)商、密碼認證以及網絡層協(xié)議配置。
4.1 LCP處理階段
首先，第一個LCP數據包被服務器端發(fā)送后，從服務器端返回一個PPP拒絕包給除密碼認證外的所有選項，接著服務器端強制認證協(xié)議進行協(xié)商(先前來自否定幀的PAP和CHAP都被發(fā)送)。隨后服務器端返回一個拒絕包給CHAP，本文用PAP來代替。然后服務器端認同并返回一個新的請求，這時候需要進行PAP。接下去對PAP進行確認，系統(tǒng)對字符映射的丟棄進行協(xié)商。最后所有控制特性被服務器端同意丟棄。
linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解（linux不再難懂）
評論