PPP 的HDLC封裝_(重點).doc

PPP 協(xié)議的類HDLC封裝摘要： PPP協(xié)議(RFC1661)提供了一種在PPP鏈路之上傳送多協(xié)議數(shù)據(jù)報文的方法。本文檔描述使用類HDLC幀封裝PPP數(shù)據(jù)包的方法。1.簡介： 本文提供對在按位和按字節(jié)同步鏈路和八位數(shù)據(jù)（無奇偶位）異步鏈路上幀封裝地詳細說明，這些鏈路必須是完全雙工，但可以是通過電路切換來實現(xiàn)的雙工。 通過轉(zhuǎn)義機制實現(xiàn)控制數(shù)據(jù)（如：XON/XOFF）在鏈路上的透明傳輸，也可以刪除鏈路中的由硬件或軟件插入的控制字符。 一些協(xié)議允許錯誤自由傳送，有的提供了某一條件下的錯誤檢測措施，有的干脆沒有。PPP協(xié)議使用HDLC幀監(jiān)測序列來進行錯誤檢測。這可以很容易地用硬件實現(xiàn)，也可用軟件實現(xiàn)。（本文提供了一種軟件實現(xiàn)方法）。1.1. 需求說明： 1.1 必要的規(guī)范必須: 該詞,或者形容詞”必需的”,是在協(xié)議中必須被滿足的.決不能: 協(xié)議中絕對被禁止的.應(yīng)該: “被推薦的”,協(xié)議中,如果在某種具體的環(huán)境下,有合法的理由可以忽略該項目,但是完整的實現(xiàn)必須理解,在做出一個不同選擇之前必須仔細的考慮. 可以: “任選的”,該項目是可選的.一個不包括任選項目的實現(xiàn)必須能與包括該項目的實現(xiàn)進行互操作.實現(xiàn): 表示協(xié)議的一個具體實現(xiàn). 1.2 術(shù)語:1 數(shù)據(jù)包(datagrame): 在網(wǎng)絡(luò)層傳輸?shù)膯卧?一個數(shù)據(jù)包可以被封裝成一個或多個分組信息包 (packet)通過數(shù)據(jù)鏈路層.2 幀(frame):數(shù)據(jù)鏈路層傳輸?shù)膯卧?.一個正可以包括一個頭部,或者還包括一個尾部,還有若干數(shù)據(jù)單元.3 分組信息包(packet):封裝的基本單元,它是網(wǎng)絡(luò)層與數(shù)據(jù)鏈路層之間的接口數(shù)據(jù)單元.它一般與幀對應(yīng),但在數(shù)據(jù)鏈路層正在進行分片或者多個分組信息包被集成到單一的幀時出現(xiàn)例外.4 對等方(peer):點到點鏈路的另一端.5 靜默丟棄(silently discard):實現(xiàn)不作任何處理丟棄分組包.實現(xiàn)應(yīng)該提供紀(jì)錄這種錯誤的能力,并且應(yīng)該在一個統(tǒng)計數(shù)其中紀(jì)錄該事件.2. 物理層需求： PPP可以通過大多數(shù)的DTE/DCE（如EIA RS-232-E, EIA RS-422和CCITT V.35）接口進行操作，PPP協(xié)議的唯一要求就是全雙工通道，可以采用異步方式，位同步方式和字節(jié)同步方式，實現(xiàn)PPP的透明數(shù)據(jù)鏈路。接口格式：PPP物理層提供8位組接口，對于子八位組的支持程度無具體規(guī)定。 傳輸速率： PPP協(xié)議對傳輸速率無任何特別的限制，它對速率的要求與DTE/DCE接口保持一致。 控制信號： PPP協(xié)議不需要類似如RTS,CTS,DCD,DTR之類的控制信號。當(dāng)然，在條件許可得情況下，使用這些信號可以達到更好的性能，特別，這些信號在LCP選項自動協(xié)商時被用來表示UP和DOWN事件【RFC1661】。當(dāng)這些信號不可用時，實現(xiàn)必須在初始化時發(fā)送UP信號，但不能發(fā)送DOWN事件。 因為控制信號不是必須的，物理層功能可以被數(shù)據(jù)鏈路層功能減弱，隱藏物理層傳輸?shù)募毠?jié)，在移動蜂窩無線網(wǎng)絡(luò)和其它一些快速的鏈路切換更是如此。 當(dāng)在同一小區(qū)的不同蜂窩之間移動時，盡管在幾種不同的頻率之間進行切換，但實現(xiàn)時可以把整個小區(qū)當(dāng)作單一的鏈路。這條鏈路被認為是與小區(qū)控制中心相連，而不是獨立的單元無線收發(fā)器相連，然而，當(dāng)鏈路被切換到一個不同的管理站時，鏈路應(yīng)當(dāng)重建它的配置。 由于數(shù)據(jù)的突發(fā)性，一些實現(xiàn)選擇在休眠時間斷開物理連接，當(dāng)數(shù)據(jù)流開始時在不通知數(shù)據(jù)鏈路層的情況下再重建連接。可靠的實現(xiàn)應(yīng)該避免使用這些方法，應(yīng)為降低建立的期限將導(dǎo)致安全性的降低，實現(xiàn)應(yīng)當(dāng)在鏈路斷開后一定的時間內(nèi)發(fā)送鏈路DOWN事件，該時間段值得確定方法很有爭論，它應(yīng)根據(jù)話務(wù)量，呼叫建立時間，安全關(guān)系的建立時間等因素來確定。3. 數(shù)據(jù)鏈路層：PPP協(xié)議使用HDLC幀格式【ISO 3309-1979】封裝，最近該標(biāo)準(zhǔn)的第四版對在異步方式使用HDLC幀進行了一些修改。PPP控制過程使用控制域譯碼。3.1. 幀格式： 下圖為PPP的HDL幀格式，該圖不包括因傳輸而引入的停止位和起始位，各個域從左向右傳送。FlagAddressControlProtocolInformationPaddingFCSFlagInter-frame Fill or next Address0111111011111111000000118/16 bits*16/32 bits01111110 協(xié)議域，信息域，填充域在PPP協(xié)議封裝中描述【RFC1661】. 標(biāo)志序列：每一幀都以一個標(biāo)志序列開始和結(jié)束，用來進行幀同步。該標(biāo)志的二進制表示為01111110(十六進制為： 0x7e)，在兩個幀之間只需要一個標(biāo)志序列，兩個連續(xù)的標(biāo)志序列表示一個空幀，空幀將被靜默丟棄，該丟棄不被視為FCS校驗錯誤。 地址域：一個8位組，包含二進制序列1 (十六進制為： 0xff)，是所有站的地址，不分配單一站地址，實現(xiàn)時必須識別和接受全站地址（1111111）。以后后可能使用其它長度和數(shù)值得地址，通過預(yù)先的協(xié)商亦可可能使用其它長度和數(shù)值得地址，帶有無效地址的幀應(yīng)該被靜默丟棄。 控制域：一個8位組，包含二進制序列00000011(十六進制為：0x03)，以后后可能使用其它長度和數(shù)值的控制域，通過預(yù)先的協(xié)商亦可可能使用其它長度和數(shù)值得控制域，帶有無效控制域的幀應(yīng)該被靜默丟棄。 幀校驗域(FCS) ：默認值為兩個8位組的FCS，4個8位組的FCS也被定義，它可能在PPP的LCP Extensions中使用【RFC 1570,】。有可能在以后或通過雙方同意使用其它的FCS長度。FCS域通過計算地址域，控制域，協(xié)議域，信息域，填充域的每一比特爾得到。不包括停止位和開始位，也不包括標(biāo)志位和FCS域自身。當(dāng)接收到異步控制轉(zhuǎn)義字符時，在計算FCS之前應(yīng)被拋棄。附錄中有FCS的詳細信息。 信息域和填充域的結(jié)束位置通過定位結(jié)束標(biāo)志序列，移去校驗域后可以確定。3.2. 基本幀格式的修改： 鏈路控制協(xié)議能夠協(xié)商修改標(biāo)準(zhǔn)的HDLC幀格式，然而，修改后的幀格式總是與標(biāo)準(zhǔn)格式有著明顯得差異。地址和控制域壓縮：當(dāng)使用類HDLC標(biāo)準(zhǔn)幀時，地址域和控制域包含十六進制值0xff 和0x03，當(dāng)使用其它地址域和控制域時，不準(zhǔn)協(xié)商地址和控制域壓縮。在傳送時，壓縮地址和控制域只是簡單地省略。 當(dāng)接收方收到HDLC幀時，通過檢查前兩個8位組就可以解壓縮，假如幀中含有值0xff和0x03，它們就被視為地址域和控制域，若沒有，則認為幀被壓縮，地址域和控制域沒傳送。 通過定義，可使協(xié)議域中的第一個8位組永遠不為0xff，協(xié)議域的值也不能為0x00ff，避免使用協(xié)議壓縮算法時協(xié)議域與信息域的第一個8位組是0x03時引起的歧義。4. 八位組填充幀： 透明性：使用8位組填充過程實現(xiàn)數(shù)據(jù)的透明傳輸。定義控制轉(zhuǎn)義8位組為01111101（0x7d）。即使是發(fā)送方的最小實現(xiàn)也必須實現(xiàn)轉(zhuǎn)義標(biāo)志序列和控制轉(zhuǎn)義字節(jié)，在校驗計算完成后，發(fā)送器檢測整個幀，每個標(biāo)志序列、控制轉(zhuǎn)義字節(jié)和任何ACCM的8位組，都用兩個8位組（一個控制轉(zhuǎn)義8位組需要轉(zhuǎn)義的8位組與0x20進行異或后的值）來組成。接收方必須能正確處理所有的控制轉(zhuǎn)義序列。接收方在進行校驗計算之前，每個小于0X20的字節(jié)都要進行檢查，假如它在接收方的ACCM中，它將被去除。每個轉(zhuǎn)義控制字節(jié)也應(yīng)被去除，再將下一個8位組與0X20異或，除非它是標(biāo)志序列。 下面舉一些例子加以說明，轉(zhuǎn)義數(shù)據(jù)在鏈路中傳送如下： 0x7e 在鏈路中傳送為： 0x7d, 0x5e. (標(biāo)志序列) 0x7d在鏈路中傳送為： 0x7d, 0x5d. (控制轉(zhuǎn)義) 0x03在鏈路中傳送為： 0x7d, 0x23. (ETX) 一些有流量控制軟件的調(diào)制解調(diào)器截取發(fā)送的DC1和DC3，而忽略第8位（奇偶校驗位）。這些數(shù)據(jù)在鏈路中以如下方式傳輸： 0x11在鏈路中傳送為： 0x7d, 0x31. (XON) 0x13在鏈路中傳送為： 0x7d, 0x33. (XOFF) 0x91在鏈路中傳送為： 0x7d, 0xb1. (XON with parity set) 0x93在鏈路中傳送為： 0x7d, 0xb3. (XOFF with parity set)4.3. 無效幀：當(dāng)幀的長度太小時（使用16位校驗時，小于4個八位組）或以一個控制轉(zhuǎn)義字節(jié)一個標(biāo)志序列結(jié)束，或異常幀（當(dāng)需要傳送1時卻傳送了0作為停止位）都被靜默丟棄，不作為FCS的校驗錯誤。 4.4. 時間填充：4.4.1. 子幀同步： 對于內(nèi)部字節(jié)的時間間隔填充無具體的規(guī)定。標(biāo)志位必須在幀之間傳送。4.4.2. 異步： 8位組之間的空閑時間必須傳送連續(xù)的“1”（標(biāo)志鏈路占用狀態(tài)），幀之間的空閑可看作8位組之間空閑的擴展，因為標(biāo)志序列既可作為幀的開始也可作為幀的結(jié)束，這樣可以每一幀可以節(jié)省一個字節(jié)，降低延遲增加帶寬。在接收了任何幀以后，在另一幀開始之前有一個空閑時間。穩(wěn)健的傳送實現(xiàn)不應(yīng)采用這些技巧，因為降低延遲的代價就是降低文檔性。噪聲較大的鏈路可能使接收器接收垃圾字符并把他們作為接收幀的一部分。假如發(fā)送器在發(fā)送下一幀之前不發(fā)送一個新的標(biāo)志序列將導(dǎo)致產(chǎn)生無效的幀。4.5. 傳送考慮：4.5.1. 字節(jié)同步： 定義不同的編碼規(guī)則是所使用的DTE/DCE的責(zé)任，不在本討論的范圍之內(nèi)。4.5.2. 異步： 所有的八位組按低位優(yōu)先的原則傳送，一個起始位，八個數(shù)據(jù)位和一個停止位，對于7位異步鏈路無具體規(guī)定。5. 位填充幀：5.1. 標(biāo)志序列： The Flag Sequence indicates the beginning or end of a frame, and is used for frame synchronization. The bit stream is examined on a bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). The shared zero mode Flag Sequence 011111101111110 SHOULD NOT be used. When not avoidable, such an implementation MUST ensure that the first Flag Sequence detected (the end of the frame) is promptly communicated to the link layer. Use of the shared zero mode hinders interoperability with bit-synchronous to asynchronous and bit- synchronous to octet-synchronous converters.5.2. 透明性： After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. A 0 bit is inserted after all sequences of five contiguous 1 bits (including the last 5 bits of the FCS) to ensure that a Flag Sequence is not simulated. On reception, prior to FCS computation, any 0 bit that directly follows five contiguous 1 bits is discarded.5.3. 無效幀： Frames which are too short (less than 4 octets when using the 16-bit FCS), or which end with a sequence of more than six 1 bits, are silently discarded, and not counted as a FCS error.5.4. Time Fill There is no provision for inter-octet time fill. The Flag Sequence SHOULD be transmitted during inter-frame time fill. However, certain types of circuit-switched links require the use of mark idle (continuous ones), particularly those that calculate accounting based on periods of bit activity. When mark idle is used on a bit-synchronous link, the implementation MUST ensure at least 15 consecutive 1 bits between Flags during the idle period, and that the Flag Sequence is always generated at the beginning of a frame after an idle period. This differs from practice in ISO 3309, which allows 7 to 14 bit mark idle.5.5. 傳送考慮： All octets are transmitted least significant bit first. The definition of various encodings and scrambling is the responsibility of the DTE/DCE equipment in use, and is outside the scope of this specification. While PPP will operate without regard to the underlying representation of the bit stream, lack of standards for transmission will hinder interoperability as surely as lack of data link standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently most widely available, and on that basis is recommended as a default. When configuration of the encoding is allowed, NRZI is recommended as an alternative, because of its relative immunity to signal inversion configuration errors, and instances when it MAY allow connection without an expensive DSU/CSU. Unfortunately, NRZI encoding exacerbates the missing x1 factor of the 16-bit FCS, so that one error in 2*15 goes undetected (instead of one in 2*16), and triple errors are not detected. Therefore, when NRZI is in use, it is recommended that the 32-bit FCS be negotiated, which includes the x1 factor. At higher speeds of up to 45 Mbps, some implementors have chosen the ANSI High Speed Synchronous Interface HSSI. While this experience is currently limited, implementors are encouraged to cooperate in choosing transmission encoding.6. 異步到同步的轉(zhuǎn)換： There may be some use of asynchronous-to-synchronous converters (some built into modems and cellular interfaces), resulting in an asynchronous PPP implementation on one end of a link and a synchronous implementation on the other. It is the responsibility of the converter to do all stuffing conversions during operation. To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter.7. 附加的LCP配置選項： The Configuration Option format and basic options are already defined for LCP 1. Up-to-date values of the LCP Option Type field are specified in the most recent Assigned Numbers RFC 10. This document concerns the following values:7.1. 異步控制轉(zhuǎn)義字符映射 (ACCM) 描述：這個配置選項提供了一種在異步鏈路上進行透明傳送控制字符的協(xié)商方法。每個異步鏈路的端點維護兩個異步控制字符映射表。接收方的ACCM是32位，發(fā)送方ACCM可以達到256位。每一個端點2個，兩端共4個，對于異步鏈路，默認接收方的ACCM是0XFFFFFFFF，默認發(fā)送方的ACCM也是0XFFFFFFFF，加上控制轉(zhuǎn)義和標(biāo)志序列字符自身，再加上其它任何要發(fā)送的轉(zhuǎn)義字符（預(yù)先配置）。對于其它類型的鏈路，因為無需轉(zhuǎn)義映射，所有ACCM的默認值是0。默認值允許所有的ASCII控制字符（包括所有的小于0x20的字節(jié)，不包括DEL）在所有的數(shù)據(jù)設(shè)備上進行透明傳送。發(fā)送者亦可用控制轉(zhuǎn)義格式發(fā)送從0X40到0Xff之間的值（不包括0x5e）。因為這些字節(jié)的值未協(xié)商，所以這沒有解決接收方不能處理非控制字符的問題。此外，因為技術(shù)不能影響第8位，所以這也不能解決只能傳送7位數(shù)據(jù)位的通訊鏈路的問題。 Note that this specification differs in detail from later amendments, such as 3309:1991/Amendment 2 3. However, such extended transparency is applied only by prior agreement. Use of the transparency methods in this specification constitute a prior agreement with respect to PPP. For compatibility with 3309:1991/Amendment 2, the transmitter MAY escape DEL and ACCM equivalents with the 8th (most significant) bit set. No change is required in the receiving algorithm. Following ACCM negotiation, the transmitter SHOULD cease escaping DEL. However, it is rarely necessary to map all control characters, and often it is unnecessary to map any control characters. The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them. The peer MAY still send any other octets in mapped format, if it is necessary because of constraints known to the peer. The peer SHOULD Configure-Nak with the logical union of the sets of mapped octets, so that when such octets are spuriously introduced they can be ignored on receipt. 異步控制轉(zhuǎn)義字符映射配置選項的格式如下：（從左到右傳送） Type 2 Length 6 ACCM ACCM字段占4個字節(jié)，表明要映射的控制字符集合，映射發(fā)送時高位在前。每位對應(yīng)于一個與位置相等的值，假如某一位置0，則該位位置值對于的八位組不需要轉(zhuǎn)義，否則該位要進行轉(zhuǎn)義映射。例如第19位設(shè)為0，則ASCII控制字符19(DC3, Control-S)以原始方式發(fā)送，無需轉(zhuǎn)義。 A. 推薦的 LCP 選項： 對于高速鏈路：Magic Number，Link Quality Monitoring，No Address and Control Field ，Compression，No Protocol Field Compression 對于低速鏈路和異步鏈路：Async Control Character Map，Magic Number，Address and Control Field Compression，Protocol Field CompressionB. PPP幀的自動識別： 有時候需要監(jiān)測PPP幀，例如在注冊時。下面的字節(jié)序列都是有效的PPP LCP偵： 7e ff 03 c0 21 7e ff 7d 23 c0 21 7e 7d df 7d 23 c0 21 Note that the first two forms are not a valid username for Unix. However, only the third form generates a correctly checksummed PPP frame, whenever 03 and ff are taken as the control characters ETX and DEL without regard to parity (they are correct for an even parity link) and discarded. Many implementations deal with this by putting the interface into packet mode when one of the above username patterns are detected during login, without examining the initial PPP checksum. The initial incoming PPP frame is discarded, but a Configure-Request is sent immediately.C. 快速幀校驗序列(FCS)的實現(xiàn)：FCS最初設(shè)計為硬件實現(xiàn)，當(dāng)數(shù)據(jù)位發(fā)送到線路時，發(fā)送方邊發(fā)送邊計算FCS值，最后將FCS的值和幀結(jié)束標(biāo)志序列發(fā)送到線路，完成一個幀的傳送。接收方在沒有收到幀結(jié)束標(biāo)志序列之前無法確定合適FCS值計算應(yīng)該結(jié)束。因此只有對包括FCS域在內(nèi)的字節(jié)進行校驗計算，當(dāng)?shù)竭_到幀結(jié)束標(biāo)志序列時，判斷FCS的計算結(jié)果是否為某一特定值，從而確定幀是否正確。C.1. FCS 表的產(chǎn)生： 下面的代碼產(chǎn)生一個表供計算FCS-16查找： /* * The FCS-16 generator polynomial: x*0 + x*5 + x*12 + x*16. */ #define P 0x8408 main() register unsigned int b, v; register int i; printf(typedef unsigned short u16;n); printf(static u16 fcstab256 = ); for (b = 0; ; ) if (b % 8 = 0) printf(n); v = b; for (i = 8; i-; ) v = v & 1 ? (v 1) P : v 1; printf(t0x%04x, v & 0xFFFF); if (+b = 256) break; printf(,); printf(n;n); C.2. FCS-16 的計算方法： 下面的代碼提供了一種查表計算FCS16的方法： /* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16; /* * FCS lookup table as calculated by the table generator. */ static u16 fcstab256 = 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 ; #define PPPINITFCS16 0xffff /* Initial FCS value */ #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */ /* * Calculate a new fcs given the current fcs and the new data. */ u16 pppfcs16(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; ASSERT(sizeof (u16) = 2); ASSERT(u16) -1) 0); while (len-) fcs = (fcs 8) fcstab(fcs *cp+) & 0xff; return (fcs); /* * How to use the fcs */ tryfcs16(cp, len) register unsigned char *cp; register int len; u16 trialfcs; /* add on output */ trialfcs = pppfcs16( PPPINITFCS16, cp, len ); trialfcs = 0xffff; /* complement */ cplen = (trialfcs & 0x00ff); /* least significant byte first */ cplen+1 = (trialfcs 8) & 0x00ff); /* check on input */ trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); if ( trialfcs = PPPGOODFCS16 ) printf(Good FCSn); C.3. 32位FCS 計算方法： /* * The FCS-32 generator polynomial: x*0 + x*1 + x*2 + x*4 + x*5 * + x*7 + x*8 + x*10 + x*11 + x*12 + x*16 * + x*22 + x*23 + x*26 + x*32. */ /* * u32 represents an unsigned 32-bit number. Adjust the typedef for * your hardware. */ typedef unsigned long u32; static u32 fcstab_32256 = 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, 0x4db26158, 0x