一.LCP协商阶段.doc

一．LCP协商configure_request 00 //标识符identifier 00 17 //长度 02 06 00 00 00 00 //表示选项的type为2，06为长度，00 0A 00 00表示ACCM选项的数据域. 05 06 76 39 51 79 //选项type为5，表示magic number，06为长度，后面的是内容 07 02 //选项type为7表示协议域压缩 08 02 //选项type为8表示地址控制域压缩 0D 03 06 //选项type为0D表示回调（Callback） CA 93 //表示FCS 7E //flag ISP→GTM900(LCP REJ) ISP向GTM900发送LCP REJECT数据包，表明不支持Magic Number与Callback。 R: 7E FF 03 C0 21 04 // 表示Configure-Reject 00 //标识符 00 0D //长度 05 06 76 39 51 79 //magic number（被拒绝的选项配置） 0D 03 06 //Callback(被拒绝的选项配置) D9 EA //FCS 7E GTM900→ISP(LCP REQ) GTM900向ISP再一次发送LCP REQUEST数据包，此次取消了Magic Number与Callback W: 7E FF 03 C0 21 01 //configure_request 01 //标识符+1 00 0E // 长度 02 06 00 00 00 00 //表示选项的type为2，06为长度，00 00 00 00表示ACCM选项的数据域. 07 02 //协议域压缩 08 02 //地址控制域压缩 70 34 //FCS 7E ISP→GTM900(LCP Ack) 经过协商，ISP接受了GTM900的请求 R: 7E FF 03 C0 21 02 // Configure-Ack 01 //标识符 00 0E //长度 02 06 00 00 00 00 //表示选项的type为2，06为长度，00 00 00 00表示ACCM选项的数据域 07 02 //协议域压缩 08 02 //地址控制域压缩 4E B7 //FCS 7E ISP→GTM900(LCP REQ) ISP向GTM900发送一个LCP REQUEST，表明要选择CHAP验证方式 R: 7E FF 03 C0 21 01 //Configure-Request 09 //标识符 00 13 //长度 02 06 00 00 00 00 //表示选项的type为2，06为长度，00 00 00 00表示ACCM选项的数据域 03 05 C2 23 05 //C2 23（CHAP,挑战握手验证协议) 05(MD5算法）Configure-Ack 09 //标识符 00 13 //长度 02 06 00 00 00 00 //表示选项的type为2，06为长度，00 00 00 00表示ACCM选项的数据域 03 05 C2 23 05 //C2 23（CHAP,挑战握手验证协议) 05(MD5算法）Challenge） 协商完成后，ISP开始对GTM900发出挑战数据包，内容包括： ⒈ 01所在的字段是类型字段，01表示这是一个挑战。 ⒉ ID字段表示这次挑战的序列号。 ⒊ 随机数字 ⒋ 用户名字段，用于对方根据该名称查找对应的PASSWORD。 在发出这个挑战包后，ISP在自己的路由器里保存了ID和随机数字值，供下面的MD5计算用。 R: 7E C2 23 //挑战握手认证协议 CHAP 01 //代码段 01代表挑战 Challenge39 //value值大小 53 2F B5 26 40 0A 98 FD BA 94 B9 82 0F B5 D6 A6 CC 8B E8 B4 EA 2A 30 75 B7 14 07 05 86 77 63 73 16 29 28 1C C3 64 35 C4 6F 41 29 79 2E F5 F9 28 B3 CF 33 FC 7D 5E ED 0F 7A C3 //value 随机数字 E8 C0 //用户名字段,用于对方根据该名称查找对应的PASSWORD 7E GTM900→ISP G