【实验作业】
实验一 分析iNode （802.1x ）的认证过程
1.1 802.1x认证简述
802.1x 身份认证，又称EAPOE (Extensible Authentication Protocol Of Ethernet)认证，全称为基于以太网端口的可扩展身份验证协议。该协议由IEEE 协会提出，是完成标准化的一个 符合IEEE 802协议集的局域网接入控制协议，主要用于宽带城域网。它提供了一种连接到局域网的用户认证和授权手段，达到了接受合法用户接入，保护网络安全的目的。
802.1x 认证体系主要由以下三个部分组成：
客户端：一般安装在用户的工作站上，当用户有上网需求时，激活客户端程序，输入必要的用户名和口令，客户端程序将会送出连接请求。
认证系统：在以太网系统中指认证交换机，其主要作用是完成用户认证信息的上传、下达工作，并根据认证的结果打开或关闭端口。
认证服务器：通过检验客户端发送来的身份标识（用户名和口令）来判别用户是否有权使用网络系统提供的网络服务，并根据认证结果向交换机发出打开或保持端口关闭的状态。
1.2 802.1x认证过程描述
⑴ 客户端广播发送一个EAPOL-Start 报文寻找认证系统，准备802.1x 认证接入；
⑵ 认证系统向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来；
⑶ 客户端回应一个EAP-Response/Identity报文给认证系统的请求，其中包括用户名；
⑷ 认证系统将报文封装到RADIUS Access-Request报文中，发送给认证服务器；
⑸ 认证服务器产生一个Challenge ，通过RADIUS Access-Challenge报文发送给认证系统；
⑹ 认证系统通过EAP-Request/MD5-Challenge报文将Challenge 发送给客户端进行认证；
⑺ 客户端收到报文后，将用户名、密码和Challenge 做MD5算法得到Challenged-Password ，通过
⑻ 认证系统将Challenge ，Challenged Password 和用户名一起，通过RADIUS Access-Request 报文送到认证服务器进行认证；
⑼ 认证服务器根据用户信息，做MD5算法判断用户是否合法，如果合法，则回应RADIUS 报文到认证系统；
⑽ 认证系统携带协商参数及用户的相关业务属性，通过EAP-Success 报文给客户端授权；
⑾ 客户端通过标准的DHCP 协议 ，通过认证系统获取规划的IP 地址；
⑿ 认证系统发起计费开始请求给认证服务器，服务器回应计费开始请求，用户上线完毕。
1.3 DHCP配置过程描述
⑴ 客户端为获取IP 地址，广播发送DHCP-DISCOVERY 报文，联系本地所有DHCP 服务器； ⑵ DHCP 服务器响应客户端的请求，向客户端发送DHCP-OFFER 报文，包含客户端的配置信息及分配给它的IP 地址；
⑶ 客户端选择一个服务器并向其发送DHCP-REQUEST 报文；
⑷ DHCP服务器如果同意使用该配置，将向客户端发送DHCP-ACK 报文，完成配置过程。
1.4 实例分析iNode 客户端登录时的802.1x 认证过程
1.4.1 操作步骤
⑴ 打开Wireshark 软件，选择网络接口，对以太网适配器进行抓包。
⑵ 打开iNode 客户端，采用802.1x 接入方式，输入用户名(111100824)和密码，自动获取IP 地址接入互联网。客户端认证过程如下图。
⑶ 接入网络后，停止Wireshark 抓包，过滤并分析与802.1x 认证过程相关的数据包。
1.4.2 EAP数据包格式
EAP(Extensible Authentication Protocol，可扩展身份验证协议) 的数据包通过IEEE 802协议集被定义在802.1x 中，如果802.1x 认证数据段内含的是EAP 协议，则其头部的类型(Type)字节为[00](EAP Packet)。
EAP 数据包格式如下图所示，这些字段从左到右传送。
代码(Code)字段是一个字节，确定了EAP 数据包类型。定义了代码1-4，其它的代码将被简单丢弃。 01 请求 02 回应 03 成功 04 失败
身份(Id)字段是一个字节，用于匹配请求的回应。一次会话的两个或多个EAP 数据包身份应相同。 长度(Length)字段是两个字节，用于表示EAP 数据包包含代码，身份，长度和数据字段的字节数。超出长度字段的字节将被当作数据链路层的填补而被忽略，而当消息长度字段设置的值大于接收字节数时，将被简单丢弃。
数据(Data)字段是0字节或多字节，格式由代码字段确定。当代码字段是请求(01)或者回应(02)时，数据字段是多字节，请求/回应类型(Type)主要有：
01 身份 02 通知 03 Nak响应 04 MD5-挑战 254 扩展类型
正常且正确的认证过程一般只包含类型1和4。
1.4.3 认证过程分析
Ⅰ．先通过关键词“eapol”过滤出EAPOL 协议的数据包，如下图。与认证过程相关的帧数为10、11、14、15、16、20。除此之外的第17、18帧代码类型未知(Unknown)，原因可能是：1、Wireshark 版本较低，无法解析该数据代码。2、802.1x 协议有相关补充文档，即EAP 数据有新类型的代码。3、学校的网络协议含有一些不同于一般802.1x 接入方式的定制项目；第195、196和197帧已经不属于认证过程。
以上的每一帧都由两部分组成：属于数据链路层的MAC 帧头帧尾，和封装在其中的EAP 协议数据段。其中，前者在整个认证过程中的数据基本相似，因此对MAC 帧头帧尾只分析第10、11帧。
① 第10帧：EAPOL-Start 报文
这一帧的作用是客户端通过广播一个EAPOL-Start 报文，用来寻找所有可以接入的认证系统，过程对应上文1.2-⑴。
开始是MAC 帧头信息，从ff 到8e 共14个字节。1-6字节是目标MAC 地址[ff:ff:ff:ff:ff:ff]，表示发送方式是广播(Broadcast)。7-12字节是源MAC 地址[5c:26:0a:7e:3b:c7]，解析为Dell_7e:3b:c7，对应于本机品牌(戴尔) 和以太网适配器的物理地址，见下图，表示该帧由本机客户端发送。13-14字节是数据帧类型[0x888e]，表示该帧封装了802.1x Authentication数据。
中间部分是802.1x 认证数据。第15字节是认证数据版本(Version)[01]，以下各帧版本也都是1。第16帧是认证数据类型(Type)[01]，表示认证过程开始(Start)。17-18字节是认证数据长度
(Length)[00]，表示该帧只提示认证开始，没有其他数据。
从第19字节开始是MAC 帧尾信息，包含拖曳数据(Trailer)和帧检验序列(Frame check
sequence) 。
② 第11帧：EAP-Request/Identity报文
这一帧的作用是认证系统通过向客户端发送一个EAP-Request/Identity报文，请求客户端将其
身份(用户名) 上传，过程对应上文1.2-⑵。
MAC 帧头信息中，目标MAC 地址为[5c:26:0a:7e:3b:c7]，表示发送目标是本机客户端。源MAC 地址为[3c:e5:a6:f7:a9:e5]，解析为Hangzhou_f7:a9:e5，对应于认证系统的公司名和物理地址，表示该帧由认证系统发送给客户端。
802.1x 认证数据类型为[00]，表示该帧封装了一个EAP 数据包。与之对应，认证数据的长度大于0，该帧为[0005]，表示该EAP 数据包的长度为5字节。
接下来的19-23字节是EAP 数据，其格式见上文1.3.2。第19字节是EAP 类型代码(Code)[01]，表示发送请求。第20字节是身份(Id)[01]，表示该EAP 请求的身份为1，由定义规则可知，对应该请求的回应的身份也应该是1。21-22字节是EAP 数据长度[0005]，与802.1x 认证数据中的长度含义相同。第23字节是数据类型(Type)[01]，这里指请求类型为身份(Identity)请求。
MAC 帧尾信息与第10帧类似。
③ 第14帧：EAP-Response/Identity报文
以下认证过程的各帧都是EAP 数据包，并且每一帧除EAP 数据段之外，内容基本同10、11
帧，因此以下各帧只分析EAP 数据部分。
这一帧的作用是客户端回应11帧认证系统的请求，将客户帐号的用户名加载在一个
EAP-Response/Identity报文中发送给认证系统，过程对应上文1.2-⑶。
EAP 类型代码(Code)是[02]，表示发送回应。身份(Id)是[01]，对应于第11帧EAP-Request 请求。EAP 数据长度(Length)是46字节。数据类型(Type)还是[01]，表示是第11帧身份请求对应的身份(Identity)回应。再后面的41个字节就是回应的身份信息[...=111100824]，对应于本机客户端帐号的用户名，见1.3.2-⑵图。
④ 第15帧：EAP-Request/MD5-Challenge报文
在这一帧到来之前，认证系统已经将用户名发送给认证服务器，并且后者产生了一个Challenge 发送给了认证系统。
这一帧的作用是认证系统通过EAP-Request/MD5-Challenge报文将认证服务器产生的Challenge 发送给客户端进行身份认证，过程对应上文1.2-⑹。
EAP 类型代码(Code)是[01]，表示发送请求。身份(Id)是[02]，表示新一轮EAP 请求的身份是2，可推断该帧的回应身份也应该是2。EAP 数据长度(Length)是22字节。数据类型(Type)还是[04]，表示是使用MD5算法的挑战。供MD5计算使用的随机数值长(Value-Size)是16字节，值(Value)为
[5a744b6f53336b42060723c8640a3b23]。
⑤ 第16帧：EAP-Response/MD5-Challenge报文
这一帧的作用是客户端将用户名、密码和Challenge 做MD5算法得到的Challenged-Password ，通过EAP-Response/MD5-Challenge报文回应给认证系统，过程对应上文1.2-⑺。
EAP 类型代码(Code)是[02]，表示发送回应。身份(Id)是[02]，对应于第15帧EAP-Request 请求。EAP 数据长度(Length)是31字节。数据类型(Type)还是[04]，表示是第15帧MD5挑战请求对应的回应。经过MD5计算后的值长(Value-Size)是16字节，值(Value)为[6c58d73f60884d39e5dafe788c5da2fb]。最后9字节的额外数据(Extra data)是[[***********]]，观察可知是用户名[111100824]每位前加数字3所得，方便认证系统进行身份认证。
⑥ 第20帧：EAP-Success 报文
在这一帧到来之前，认证系统已经将Challenge 、Challenged Password和用户名一起发送到了认证服务器，后者做用户合法性检验，并回应通过消息到认证系统。
这一帧的作用是认证系统通过一个EAP-Success 报文，授权客户端接入网络的请求，完成整个认证过程，过程对应上文1.2-⑽。
EAP 类型代码(Code)是[03]，表示认证成功。身份(Id)还是[02]，对应于第15、16帧的会话结果。EAP 数据长度(Length)是4字节。
Ⅱ．再通过关键词“bootp ”过滤出DHCP 协议的数据包，如下图。
配置过程
第21、28、29和30这4帧是DHCP 配置过程，对应上文1.2-⑾。其中，
① 第21帧：DHCP-Discover 报文，过程对应上文1.3-⑴。
② 第28帧：DHCP-Offer 报文，过程对应上文1.3-⑵。
③ 第29帧：DHCP-Request 报文，过程对应上文1.3-⑶。
④ 第30帧：DHCP-ACK 报文，过程对应上文1.3-⑷。
DHCP 采用了BOOTP 报文的格式和端口号，第28帧的自举协议(Bootstrap Protocol)举例如下图。
实验二 分析PPPoE 的协议流程
2.1 PPPoE协议简述
PPPoE 协议提供了在以太网中多台主机连接到远端的宽带接入服务器上的一种标准。在这种网络模型中，所有用户的主机都需要独立的初始化自已的PPP 协议栈，而且通过PPP 协议本身所具有的一些特点，实现在广播式网络上对用户进行计费和管理。为了能在广播式的网络上建立、维持各主机与访问集中器之间点对点的关系，就需要每个主机与访问集中器之间能建立唯一的点到点的会话。
PPPoE 协议包括两个阶段，即发现阶段(Discovery Stage)和会话阶段（Session Stage）。当一个主机希望开始一个PPPoE 会话时，它首先会在以太网上寻找一个宽带接入服务器，如果网络上存在多个服务器时，主机会根据各服务器所能提供的服务或用户的预先的一些配置来进行相应的选择。当主机选择完了所需要的服务器后，就开始和服务器建立一个PPPoE 会话进程。在这个过程中服务器会为每一个PPPoE 会话分配一个唯一的进程ID ，会话建立起来后就开始了PPPoE 的会话阶段，在这个阶段中已建立好点对点连接的双方就采用PPP 协议来交换数据报文，从而完成一系列PPP 的过程，最终将在这点对点的逻辑通道上进行网络层数据报的传送。
2.2 PPPoE协议流程描述
2.2.1 发现阶段描述
发现阶段包括以下4个步骤：
⑴ 主机广播一个发起（PADI ）分组，代码字段值为0x09，会话ID 字段值为0x0000。PADI 包必须至少包含一个服务名称类型的标签，标签类型字段值为0x0101，向服务器提出所要求提供的服务。
⑵ 服务器收到在服务范围内的PADI 包分组，发送提供（PADO ）分组，以响应请求，代码字段值为0x07 ，会话ID 字段值仍为0x0000。PADO 分组必须包含一个服务器名称类型的标签，标签类型字段值为0x0102，以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。
⑶ 主机在可能收到的多个PADO 分组中选择一个合适的PADO 分组，然后向所选择的服务器发送请求（PADR ）分组，代码字段值为0x19 ，会话ID 字段值仍为0x0000。PADR 分组必须包含一个服务名称类型标签，确定向服务器请求的服务种类。当主机在指定的时间内没有接收到PADO ，它应该重新发送它的PADI 分组，并且加倍等待时间，这个过程会被重复期望的次数。
⑷ 服务器收到PADR 包后准备开始PPP 会话，它发送一个确认（PADS ）分组，代码字段值为0x65 ，会话ID 字段值为服务器所产生的一个惟一的会话标识号码。PADS 分组也必须包含一个接入集中器名称类型的标签确认向主机提供的服务。当主机收到PADS 包确认后，双方就进入PPP 会话阶段。
2.2.2 会话阶段描述
用户主机与服务器根据在发现阶段所协商的PPP 会话连接参数进行PPP 会话。一旦PPPoE 会话开始，PPP 数据就可以以任何其它的PPP 封装形式发送。会话阶段所有的以太网帧都是单播的，这依赖于发现阶段产生的会话ID ，因此在一次会话中ID 的值不能改变。
终止(PADT)分组可以在会话建立后的任何时候终止PPPoE 会话。它可以由主机或者服务器发送。PADT 包不需要任何标签，代码字段值为0xa7 ，会话ID 字段值为需要终止的PPP 会话的会话标识号码。
2.3 实例分析PPPoE 协议流程
在Wireshark 软件里打开PPPoE 数据包文件——“PPP 登录”、“PPP 登录”和“PPP 登录”，并参考文档“配置截图”。通过后者分析可知，进行该PPPoE 数据包抓取时的网络环境参数及路由表如下图：
由路由表可以分析得知之后的通信数据传输方式，以及所经过的接口。
2.3.1 PPPoE数据报文格式
所有PPPoE 数据报文都是封装在以太网数据帧的数据域内进行传输的，为了区分PPPoE 的两大阶段，以太网帧通过类型(Type)域进行区分：在PPPoE 的发现阶段时，以太网的类型域填充0x8863；在PPPoE 的会话阶段时，以太网的类型域填充为0x8864。
下图为PPPoE 的报文的格式：
1、最开始的4位为版本域，协议中给出了明确的规定，这个域的内容填充0x01。
2、版本域后的4位是类型域，协议中同样规定，这个域的内容填充为0x01。
3、代码域占用1个字节，对于PPPoE 的不同阶段这个域内的内容也是不一样的：
① 0x09：发起PADI （PPPOE Active Discovery Initiation）
② 0x07：提供PADO （PPPOE Active Discovery offer）
③ 0x19：请求PADR （PPPOE Active Discovery Request）
④ 0x65：确认PADS （PPPOE Active Discovery Session-confirmation）
⑤ 0xA7：终止PADT （PPPOE Active Discovery Terminate）
⑥ 0x00：会话
4、会话ID 点用2个字节，当服务器还未分配唯一的会话ID 给用户主机时，该域内的内容填充为0x0000。一旦获取会话ID ，那么在后续的所有报文中该域填充这个唯一的会话ID 值。
5、长度域为2个字节，用来指示PPPoE 数据报文中净载荷的长度。
6、净载荷域，在PPPoE 的不同阶段该域内的数据内容会有很大的不同：
① 对于发现阶段，该域内会包含零个或多个Tag （标记），标记的格式如下图：
标记的封装格式采用TLV 结构，即类型+长度+数据。标记的类型域为2个字节，标记类型取值及含义如下表：
② 对于发现阶段，该域则携带的是PPP 报文。
2.3.2 发现阶段分析
数据包文件“PPP 登录”的前4帧对应的正是PPPoE 发现阶段的4个过程，如下图。
以上的4帧都是以太网帧封装的PPPoE 发现帧(PPPoE Discovery)，类型(Type)是[0x8863]，表示是发现阶段。以下逐一分析每一帧的PPPoE 报文部分： ① 第1帧：PADI 发起分组
这一帧的作用是客户端通过广播请求以获取可用的服务器，过程对应上文2.2.1-⑴。
目标MAC 地址是[ff:ff:ff:ff:ff:ff]，表示是广播发送。源MAC 地址[bc:ae:5c:da:d9:92]，对应上图路由表中的本地以太网适配器地址，说明这一帧发往以太网接口。
版本和类型都是默认值1，代码[0x09]表示发起过程，会话ID 因为处于发现阶段所以是默认值0。标记(Tags)都采用TLV 三元组结构，类型(T)和长度(L)部分只分析本帧，数据如下图：
这一发现帧的静荷载长度为16字节，其中包含了两个标记：第1个标记类型为0101(服务名) ，长度为0。第2个标记类型为0103(主机唯一标识) ，长度为8字节，值为[[**************]0]，相当于主机的身份标志。 ② 第2帧：PADO 提供分组
这一帧的作用是服务器收到请求后回应客户端可提供服务，过程对应上文2.2.1-⑵。
目标MAC 地址是[bc:ae:5c:da:d9:92]，表示发往本地以太网接口。源MAC 地址[00:30:88:11:29:c8]，解析为Siara_11:29:c8，应该是提供网络服务的服务器地址。
代码[0x07]表示提供过程，静荷载长度为99字节，其中包含有7个标记：第1个标记是主机的唯一标识，与上一帧相同。第2个标记类型为0102(服务器名) ，表示客户端收到了名为[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1]的服务器的回应。后面的5个标记类型都为0101(服务名) ，表示服务器可以向客户提供的服务有五个，分别是[xyxf][shenyan.ha][iptv.ha][cnc][CNC]。 ③ 第3帧：PADR 请求分组
这一帧的作用是客户端选择一个并向该服务器发出请求，过程对应上文2.2.1-⑶。
目标MAC 地址是提供服务的服务器，源MAC 地址是本地以太网接口。
代码[0x19]表示请求过程，静荷载长度为20字节，其中包含有2个标记：第1个标记是服务名，表示客户端选择了一个服务[xyxf]。第2个标记为主机唯一标识[[**************]0]，相对上两帧的主机标识[[**************]0]有了变化，说明一个主机标识只需匹配一次发送和接收，而不需要一直保持不变。
④ 第4帧：PADS 确认分组
这一帧的作用是服务器收到请求后回应客户端可提供服务，过程对应上文2.2.1-⑷。
目标MAC 地址是本地以太网接口，源MAC 地址是提供服务的服务器。
代码[0x65]表示确认过程，静荷载长度为60字节，其中包含有3个标记：第1个标记是服务名，表示服务器确认了客户端选择的服务[xyxf]。第2个标记为主机唯一标识[[**************]0]，与上一帧对应相同。第3个标记向客户端确认了提供服务的服务器名[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1]。
注意到这一发现帧的会话ID 已经不再是0，而是由服务器分配给客户端的一个唯一的值[0x1ada]。在接下来的会话阶段，该会话ID 将一直保持不变。
2.3.3 PPP帧格式
PPP 帧格式如下图。
Ⅰ“协议”字段取值及含义：
Ⅱ“编码”字段取值及含义(不同的协议类型有所不同) ： ① 链路控制协议LCP ：
1/2/3/4-Configure-Request/Ack/Nak/Reject 5/6-Terminate-Request/Ack 7-Code-Reject 8-Protocol-Reject
9/10-Echo-Request/Reply 11-Discard-Request
在LCP 协议中定义了多种配置选项，封装在载荷域内，分别的取值及含义：
01-最大接收单元MRU 03-认证协议 05-幻数MN 07-协议域压缩PFC 08-地址及控制域压缩ACFC 13/0d-回调控制协议CBCP ② IP 控制协议IPCP ：
2-IP 压缩协议 3-IP 地址 ③ 基于挑战的认证协议CHAP ：
1-Challenge 2-Response 3-Success 4-Failure ④ 压缩控制协议CCP ：
1-7与LCP 相同 14-Reset-Request 15-Reset-Ack
2.3.4 会话阶段分析
数据包文件“PPP 登录”从第5帧开始就是PPPoE 会话阶段的数据帧，如下图。
以上的5-27帧都是以太网帧封装的PPPoE 会话帧(PPPoE Session)，类型(Type)是[0x8864]，表示是会话阶段。PPPoE 会话帧实质都是通过封装的PPP 帧进行通信。这些PPP 帧分为不同的协议，该例中主要协议有：LCP 、CHAP 、IPCP 和CCP ，下面根据PPP 协议流程的阶段顺序逐个分析： ⑴ 链路建立阶段(Establish)
在这个阶段，通信双方用链路控制协议(LCP)配置PPP 链路。这个阶段完成的标识是发起方收到对方发送的LCP Configure-Ack报文。
分析可知，该阶段包含以下6个LCP 协议帧，通过ID 匹配请求与回应，通过ID 匹配两两顺序排列结果如下。
① 第5帧与第7帧
客户端向服务器发送一个Configure-Request 报文试图建立链路，但服务器回应一个Configure-Reject 报文拒绝了客户端的请求。从回应帧的选项可知，拒绝的原因是请求报文中的回调协议控制(CBCP)选项不被服务器识别或接受。为此，客户端在第9帧的Configure-Request 报文中进行了调整。由图可知，这两帧ID 为[0x00]，客户端的最大接收单元为[1480]字节，发出的幻数值为[0x4e7d1279]。
② 第6帧与第8帧
服务器向客户端发送一个Configure-Request 报文请求建立链路，客户端回应一个Configure-Ack 报文通过了服务器的请求，服务器向客户端的链路建立成功。由图可知，这两帧ID 为[0x2e]，服务器的最大接收单元为[1492]字节，发出和收到的幻数值都为[0x56a02122]，表示没有回路。 ③ 第9帧与第10帧
客户端又向服务器发送了一个Configure-Request 报文，这个报文相比第5帧少了回调(Callback)选项，这一次服务器回应一个Configure-Ack 报文通过了客户端的请求，客户端向服务器的链路建立成功。由图可知，这两帧ID 为[0x01]，客户端的最大接收单元还是[1480]字节，发出和收到的幻数值都是[0x4e7d1279]，表示没有回路。
至此，通信双方接收到了对方的Configure-Ack 报文，链路建立阶段完成。
⑵ 认证阶段(Authenticate)
在这个阶段，服务器通过基于挑战的认证协议(CHAP)认证客户端的身份。这个阶段完成的标识是客户端收到服务器发送的CHAP Success报文。
分析可知，该阶段包含以下3个CHAP 协议帧，它们的ID 都是1。 ① 第11帧：Challenge 报文
这一帧是认证方(服务器[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1])向被认证方(客户端[bc:ae:5c:da:d9:92])发送的Challenge 报文，其中包含了长度为16字节的随机数c ，其值为[60d547eeeafb04b4e9bebb0ee035ec69]，该随机数用于MD5算法计算。 ② 第14帧：Response 报文
作为回应，被认证方(客户端) 将双方共享的密值s 与随机数c 作为输入，使用MD5算法计算出散列值A 1，值为[8e9fbe65able4d4ad199b97e0760c636]，通过该Response 报文返回给认证方(服务器) 。 ③ 第17帧：Success 报文
认证方(服务器) 在本地将密值s 与随机数c 作为输入，同用以散列函数计算出散列值A 2，将A 2
与接收到的A 1进行比较，如果A 1=A2，则说明被认证方(客户端) 提供了正确的秘密信息，CHAP 认证成功，返回Success 报文。
至此，客户端收到服务器发送的CHAP Success报文，认证阶段完成。
⑶ 网络层协议阶段(Network)
在这个阶段，服务器通过IP 控制协议(IPCP)为客户端分配IP 地址，双方还通过压缩控制协议(CCP)协商采用什么压缩算法。这个阶段完成的标识是发起方收到对方发送的IPCP Configure-Ack报文。
分析可知，该阶段包含以下8个IPCP 协议帧和2个CCP 帧(其中后一帧封装在LCP 帧中) ，通过ID 匹配两两顺序排列结果如下。
① 第18帧与第21帧
服务器向客户端发送一个Configure-Request 报文请求配置协议，客户端回应一个Configure-Ack 报文通过了服务器的请求，服务器对客户端的网络层协议配置成功。由图可知，这两帧ID 为[0xfd]，服务器给客户端提供的服务器IP 地址为[123.14.232.1]。 ② 第19帧与第22帧
客户端向服务器发送一个CCP 协议的Configure-Request 报文，ID 为[0x04]，协商试图采用微软PPC 的数据压缩算法[MPPC]，但服务器回应一个LCP 协议的Protocol-Reject 报文，拒绝了客户端发送的第19帧中ID 同为[0x04]的CCP 协议包，告诉客户端不要采取数据压缩算法[MPPC]。 ③ 第20帧与第23帧
客户端向服务器发送一个Configure-Request 报文试图配置协议，请求得到IP 地址、DNS 和WINS 服务器地址，但服务器回应一个Configure-Reject 报文拒绝了客户端的请求。从回应帧的选项可知，拒绝的原因是请求报文中的WINS 服务器IP 地址选项不被服务器识别或接受。为此，客户端在第24帧的Configure-Request 报文中进行了调整。由图可知，这两帧ID 为[0x05]。
④ 第24帧与第25帧
客户端又向服务器发送了一个Configure-Request 报文，这个报文相比第20帧少了WINS 服务器IP 地址选项，这一次服务器回应一个Configure-Nak 报文，其中包含了客户端请求的IP 地址[123.14.232.151]和DNS 服务器地址[202.102.224.68][202.102.227.68]，协议配置的必要条件已具备。由图可知，这两帧ID 为[0x06]。 ⑤ 第26帧与第27帧
客户端再向服务器发送一个Configure-Request 报文，再次确认服务器提供的IP 地址和DNS 服务器地址，服务器回应一个Configure-Ack 报文，客户端对服务器的网络层协议配置成功。由图可知，这两帧ID 为[0x07]。
至此，通信双方都接收到了对方的Configure-Ack 报文，客户端得到了服务器IP 地址、服务器分配的本机IP 地址及DNS 服务器地址。网络层协议阶段完成，双方可以传输通信数据。
【实验作业】
实验一 分析iNode （802.1x ）的认证过程
1.1 802.1x认证简述
802.1x 身份认证，又称EAPOE (Extensible Authentication Protocol Of Ethernet)认证，全称为基于以太网端口的可扩展身份验证协议。该协议由IEEE 协会提出，是完成标准化的一个 符合IEEE 802协议集的局域网接入控制协议，主要用于宽带城域网。它提供了一种连接到局域网的用户认证和授权手段，达到了接受合法用户接入，保护网络安全的目的。
802.1x 认证体系主要由以下三个部分组成：
客户端：一般安装在用户的工作站上，当用户有上网需求时，激活客户端程序，输入必要的用户名和口令，客户端程序将会送出连接请求。
认证系统：在以太网系统中指认证交换机，其主要作用是完成用户认证信息的上传、下达工作，并根据认证的结果打开或关闭端口。
认证服务器：通过检验客户端发送来的身份标识（用户名和口令）来判别用户是否有权使用网络系统提供的网络服务，并根据认证结果向交换机发出打开或保持端口关闭的状态。
1.2 802.1x认证过程描述
⑴ 客户端广播发送一个EAPOL-Start 报文寻找认证系统，准备802.1x 认证接入；
⑵ 认证系统向客户端发送EAP-Request/Identity报文，要求客户端将用户名送上来；
⑶ 客户端回应一个EAP-Response/Identity报文给认证系统的请求，其中包括用户名；
⑷ 认证系统将报文封装到RADIUS Access-Request报文中，发送给认证服务器；
⑸ 认证服务器产生一个Challenge ，通过RADIUS Access-Challenge报文发送给认证系统；
⑹ 认证系统通过EAP-Request/MD5-Challenge报文将Challenge 发送给客户端进行认证；
⑺ 客户端收到报文后，将用户名、密码和Challenge 做MD5算法得到Challenged-Password ，通过
⑻ 认证系统将Challenge ，Challenged Password 和用户名一起，通过RADIUS Access-Request 报文送到认证服务器进行认证；
⑼ 认证服务器根据用户信息，做MD5算法判断用户是否合法，如果合法，则回应RADIUS 报文到认证系统；
⑽ 认证系统携带协商参数及用户的相关业务属性，通过EAP-Success 报文给客户端授权；
⑾ 客户端通过标准的DHCP 协议 ，通过认证系统获取规划的IP 地址；
⑿ 认证系统发起计费开始请求给认证服务器，服务器回应计费开始请求，用户上线完毕。
1.3 DHCP配置过程描述
⑴ 客户端为获取IP 地址，广播发送DHCP-DISCOVERY 报文，联系本地所有DHCP 服务器； ⑵ DHCP 服务器响应客户端的请求，向客户端发送DHCP-OFFER 报文，包含客户端的配置信息及分配给它的IP 地址；
⑶ 客户端选择一个服务器并向其发送DHCP-REQUEST 报文；
⑷ DHCP服务器如果同意使用该配置，将向客户端发送DHCP-ACK 报文，完成配置过程。
1.4 实例分析iNode 客户端登录时的802.1x 认证过程
1.4.1 操作步骤
⑴ 打开Wireshark 软件，选择网络接口，对以太网适配器进行抓包。
⑵ 打开iNode 客户端，采用802.1x 接入方式，输入用户名(111100824)和密码，自动获取IP 地址接入互联网。客户端认证过程如下图。
⑶ 接入网络后，停止Wireshark 抓包，过滤并分析与802.1x 认证过程相关的数据包。
1.4.2 EAP数据包格式
EAP(Extensible Authentication Protocol，可扩展身份验证协议) 的数据包通过IEEE 802协议集被定义在802.1x 中，如果802.1x 认证数据段内含的是EAP 协议，则其头部的类型(Type)字节为[00](EAP Packet)。
EAP 数据包格式如下图所示，这些字段从左到右传送。
代码(Code)字段是一个字节，确定了EAP 数据包类型。定义了代码1-4，其它的代码将被简单丢弃。 01 请求 02 回应 03 成功 04 失败
身份(Id)字段是一个字节，用于匹配请求的回应。一次会话的两个或多个EAP 数据包身份应相同。 长度(Length)字段是两个字节，用于表示EAP 数据包包含代码，身份，长度和数据字段的字节数。超出长度字段的字节将被当作数据链路层的填补而被忽略，而当消息长度字段设置的值大于接收字节数时，将被简单丢弃。
数据(Data)字段是0字节或多字节，格式由代码字段确定。当代码字段是请求(01)或者回应(02)时，数据字段是多字节，请求/回应类型(Type)主要有：
01 身份 02 通知 03 Nak响应 04 MD5-挑战 254 扩展类型
正常且正确的认证过程一般只包含类型1和4。
1.4.3 认证过程分析
Ⅰ．先通过关键词“eapol”过滤出EAPOL 协议的数据包，如下图。与认证过程相关的帧数为10、11、14、15、16、20。除此之外的第17、18帧代码类型未知(Unknown)，原因可能是：1、Wireshark 版本较低，无法解析该数据代码。2、802.1x 协议有相关补充文档，即EAP 数据有新类型的代码。3、学校的网络协议含有一些不同于一般802.1x 接入方式的定制项目；第195、196和197帧已经不属于认证过程。
以上的每一帧都由两部分组成：属于数据链路层的MAC 帧头帧尾，和封装在其中的EAP 协议数据段。其中，前者在整个认证过程中的数据基本相似，因此对MAC 帧头帧尾只分析第10、11帧。
① 第10帧：EAPOL-Start 报文
这一帧的作用是客户端通过广播一个EAPOL-Start 报文，用来寻找所有可以接入的认证系统，过程对应上文1.2-⑴。
开始是MAC 帧头信息，从ff 到8e 共14个字节。1-6字节是目标MAC 地址[ff:ff:ff:ff:ff:ff]，表示发送方式是广播(Broadcast)。7-12字节是源MAC 地址[5c:26:0a:7e:3b:c7]，解析为Dell_7e:3b:c7，对应于本机品牌(戴尔) 和以太网适配器的物理地址，见下图，表示该帧由本机客户端发送。13-14字节是数据帧类型[0x888e]，表示该帧封装了802.1x Authentication数据。
中间部分是802.1x 认证数据。第15字节是认证数据版本(Version)[01]，以下各帧版本也都是1。第16帧是认证数据类型(Type)[01]，表示认证过程开始(Start)。17-18字节是认证数据长度
(Length)[00]，表示该帧只提示认证开始，没有其他数据。
从第19字节开始是MAC 帧尾信息，包含拖曳数据(Trailer)和帧检验序列(Frame check
sequence) 。
② 第11帧：EAP-Request/Identity报文
这一帧的作用是认证系统通过向客户端发送一个EAP-Request/Identity报文，请求客户端将其
身份(用户名) 上传，过程对应上文1.2-⑵。
MAC 帧头信息中，目标MAC 地址为[5c:26:0a:7e:3b:c7]，表示发送目标是本机客户端。源MAC 地址为[3c:e5:a6:f7:a9:e5]，解析为Hangzhou_f7:a9:e5，对应于认证系统的公司名和物理地址，表示该帧由认证系统发送给客户端。
802.1x 认证数据类型为[00]，表示该帧封装了一个EAP 数据包。与之对应，认证数据的长度大于0，该帧为[0005]，表示该EAP 数据包的长度为5字节。
接下来的19-23字节是EAP 数据，其格式见上文1.3.2。第19字节是EAP 类型代码(Code)[01]，表示发送请求。第20字节是身份(Id)[01]，表示该EAP 请求的身份为1，由定义规则可知，对应该请求的回应的身份也应该是1。21-22字节是EAP 数据长度[0005]，与802.1x 认证数据中的长度含义相同。第23字节是数据类型(Type)[01]，这里指请求类型为身份(Identity)请求。
MAC 帧尾信息与第10帧类似。
③ 第14帧：EAP-Response/Identity报文
以下认证过程的各帧都是EAP 数据包，并且每一帧除EAP 数据段之外，内容基本同10、11
帧，因此以下各帧只分析EAP 数据部分。
这一帧的作用是客户端回应11帧认证系统的请求，将客户帐号的用户名加载在一个
EAP-Response/Identity报文中发送给认证系统，过程对应上文1.2-⑶。
EAP 类型代码(Code)是[02]，表示发送回应。身份(Id)是[01]，对应于第11帧EAP-Request 请求。EAP 数据长度(Length)是46字节。数据类型(Type)还是[01]，表示是第11帧身份请求对应的身份(Identity)回应。再后面的41个字节就是回应的身份信息[...=111100824]，对应于本机客户端帐号的用户名，见1.3.2-⑵图。
④ 第15帧：EAP-Request/MD5-Challenge报文
在这一帧到来之前，认证系统已经将用户名发送给认证服务器，并且后者产生了一个Challenge 发送给了认证系统。
这一帧的作用是认证系统通过EAP-Request/MD5-Challenge报文将认证服务器产生的Challenge 发送给客户端进行身份认证，过程对应上文1.2-⑹。
EAP 类型代码(Code)是[01]，表示发送请求。身份(Id)是[02]，表示新一轮EAP 请求的身份是2，可推断该帧的回应身份也应该是2。EAP 数据长度(Length)是22字节。数据类型(Type)还是[04]，表示是使用MD5算法的挑战。供MD5计算使用的随机数值长(Value-Size)是16字节，值(Value)为
[5a744b6f53336b42060723c8640a3b23]。
⑤ 第16帧：EAP-Response/MD5-Challenge报文
这一帧的作用是客户端将用户名、密码和Challenge 做MD5算法得到的Challenged-Password ，通过EAP-Response/MD5-Challenge报文回应给认证系统，过程对应上文1.2-⑺。
EAP 类型代码(Code)是[02]，表示发送回应。身份(Id)是[02]，对应于第15帧EAP-Request 请求。EAP 数据长度(Length)是31字节。数据类型(Type)还是[04]，表示是第15帧MD5挑战请求对应的回应。经过MD5计算后的值长(Value-Size)是16字节，值(Value)为[6c58d73f60884d39e5dafe788c5da2fb]。最后9字节的额外数据(Extra data)是[[***********]]，观察可知是用户名[111100824]每位前加数字3所得，方便认证系统进行身份认证。
⑥ 第20帧：EAP-Success 报文
在这一帧到来之前，认证系统已经将Challenge 、Challenged Password和用户名一起发送到了认证服务器，后者做用户合法性检验，并回应通过消息到认证系统。
这一帧的作用是认证系统通过一个EAP-Success 报文，授权客户端接入网络的请求，完成整个认证过程，过程对应上文1.2-⑽。
EAP 类型代码(Code)是[03]，表示认证成功。身份(Id)还是[02]，对应于第15、16帧的会话结果。EAP 数据长度(Length)是4字节。
Ⅱ．再通过关键词“bootp ”过滤出DHCP 协议的数据包，如下图。
配置过程
第21、28、29和30这4帧是DHCP 配置过程，对应上文1.2-⑾。其中，
① 第21帧：DHCP-Discover 报文，过程对应上文1.3-⑴。
② 第28帧：DHCP-Offer 报文，过程对应上文1.3-⑵。
③ 第29帧：DHCP-Request 报文，过程对应上文1.3-⑶。
④ 第30帧：DHCP-ACK 报文，过程对应上文1.3-⑷。
DHCP 采用了BOOTP 报文的格式和端口号，第28帧的自举协议(Bootstrap Protocol)举例如下图。
实验二 分析PPPoE 的协议流程
2.1 PPPoE协议简述
PPPoE 协议提供了在以太网中多台主机连接到远端的宽带接入服务器上的一种标准。在这种网络模型中，所有用户的主机都需要独立的初始化自已的PPP 协议栈，而且通过PPP 协议本身所具有的一些特点，实现在广播式网络上对用户进行计费和管理。为了能在广播式的网络上建立、维持各主机与访问集中器之间点对点的关系，就需要每个主机与访问集中器之间能建立唯一的点到点的会话。
PPPoE 协议包括两个阶段，即发现阶段(Discovery Stage)和会话阶段（Session Stage）。当一个主机希望开始一个PPPoE 会话时，它首先会在以太网上寻找一个宽带接入服务器，如果网络上存在多个服务器时，主机会根据各服务器所能提供的服务或用户的预先的一些配置来进行相应的选择。当主机选择完了所需要的服务器后，就开始和服务器建立一个PPPoE 会话进程。在这个过程中服务器会为每一个PPPoE 会话分配一个唯一的进程ID ，会话建立起来后就开始了PPPoE 的会话阶段，在这个阶段中已建立好点对点连接的双方就采用PPP 协议来交换数据报文，从而完成一系列PPP 的过程，最终将在这点对点的逻辑通道上进行网络层数据报的传送。
2.2 PPPoE协议流程描述
2.2.1 发现阶段描述
发现阶段包括以下4个步骤：
⑴ 主机广播一个发起（PADI ）分组，代码字段值为0x09，会话ID 字段值为0x0000。PADI 包必须至少包含一个服务名称类型的标签，标签类型字段值为0x0101，向服务器提出所要求提供的服务。
⑵ 服务器收到在服务范围内的PADI 包分组，发送提供（PADO ）分组，以响应请求，代码字段值为0x07 ，会话ID 字段值仍为0x0000。PADO 分组必须包含一个服务器名称类型的标签，标签类型字段值为0x0102，以及一个或多个服务名称类型标签，表明可向主机提供的服务种类。
⑶ 主机在可能收到的多个PADO 分组中选择一个合适的PADO 分组，然后向所选择的服务器发送请求（PADR ）分组，代码字段值为0x19 ，会话ID 字段值仍为0x0000。PADR 分组必须包含一个服务名称类型标签，确定向服务器请求的服务种类。当主机在指定的时间内没有接收到PADO ，它应该重新发送它的PADI 分组，并且加倍等待时间，这个过程会被重复期望的次数。
⑷ 服务器收到PADR 包后准备开始PPP 会话，它发送一个确认（PADS ）分组，代码字段值为0x65 ，会话ID 字段值为服务器所产生的一个惟一的会话标识号码。PADS 分组也必须包含一个接入集中器名称类型的标签确认向主机提供的服务。当主机收到PADS 包确认后，双方就进入PPP 会话阶段。
2.2.2 会话阶段描述
用户主机与服务器根据在发现阶段所协商的PPP 会话连接参数进行PPP 会话。一旦PPPoE 会话开始，PPP 数据就可以以任何其它的PPP 封装形式发送。会话阶段所有的以太网帧都是单播的，这依赖于发现阶段产生的会话ID ，因此在一次会话中ID 的值不能改变。
终止(PADT)分组可以在会话建立后的任何时候终止PPPoE 会话。它可以由主机或者服务器发送。PADT 包不需要任何标签，代码字段值为0xa7 ，会话ID 字段值为需要终止的PPP 会话的会话标识号码。
2.3 实例分析PPPoE 协议流程
在Wireshark 软件里打开PPPoE 数据包文件——“PPP 登录”、“PPP 登录”和“PPP 登录”，并参考文档“配置截图”。通过后者分析可知，进行该PPPoE 数据包抓取时的网络环境参数及路由表如下图：
由路由表可以分析得知之后的通信数据传输方式，以及所经过的接口。
2.3.1 PPPoE数据报文格式
所有PPPoE 数据报文都是封装在以太网数据帧的数据域内进行传输的，为了区分PPPoE 的两大阶段，以太网帧通过类型(Type)域进行区分：在PPPoE 的发现阶段时，以太网的类型域填充0x8863；在PPPoE 的会话阶段时，以太网的类型域填充为0x8864。
下图为PPPoE 的报文的格式：
1、最开始的4位为版本域，协议中给出了明确的规定，这个域的内容填充0x01。
2、版本域后的4位是类型域，协议中同样规定，这个域的内容填充为0x01。
3、代码域占用1个字节，对于PPPoE 的不同阶段这个域内的内容也是不一样的：
① 0x09：发起PADI （PPPOE Active Discovery Initiation）
② 0x07：提供PADO （PPPOE Active Discovery offer）
③ 0x19：请求PADR （PPPOE Active Discovery Request）
④ 0x65：确认PADS （PPPOE Active Discovery Session-confirmation）
⑤ 0xA7：终止PADT （PPPOE Active Discovery Terminate）
⑥ 0x00：会话
4、会话ID 点用2个字节，当服务器还未分配唯一的会话ID 给用户主机时，该域内的内容填充为0x0000。一旦获取会话ID ，那么在后续的所有报文中该域填充这个唯一的会话ID 值。
5、长度域为2个字节，用来指示PPPoE 数据报文中净载荷的长度。
6、净载荷域，在PPPoE 的不同阶段该域内的数据内容会有很大的不同：
① 对于发现阶段，该域内会包含零个或多个Tag （标记），标记的格式如下图：
标记的封装格式采用TLV 结构，即类型+长度+数据。标记的类型域为2个字节，标记类型取值及含义如下表：
② 对于发现阶段，该域则携带的是PPP 报文。
2.3.2 发现阶段分析
数据包文件“PPP 登录”的前4帧对应的正是PPPoE 发现阶段的4个过程，如下图。
以上的4帧都是以太网帧封装的PPPoE 发现帧(PPPoE Discovery)，类型(Type)是[0x8863]，表示是发现阶段。以下逐一分析每一帧的PPPoE 报文部分： ① 第1帧：PADI 发起分组
这一帧的作用是客户端通过广播请求以获取可用的服务器，过程对应上文2.2.1-⑴。
目标MAC 地址是[ff:ff:ff:ff:ff:ff]，表示是广播发送。源MAC 地址[bc:ae:5c:da:d9:92]，对应上图路由表中的本地以太网适配器地址，说明这一帧发往以太网接口。
版本和类型都是默认值1，代码[0x09]表示发起过程，会话ID 因为处于发现阶段所以是默认值0。标记(Tags)都采用TLV 三元组结构，类型(T)和长度(L)部分只分析本帧，数据如下图：
这一发现帧的静荷载长度为16字节，其中包含了两个标记：第1个标记类型为0101(服务名) ，长度为0。第2个标记类型为0103(主机唯一标识) ，长度为8字节，值为[[**************]0]，相当于主机的身份标志。 ② 第2帧：PADO 提供分组
这一帧的作用是服务器收到请求后回应客户端可提供服务，过程对应上文2.2.1-⑵。
目标MAC 地址是[bc:ae:5c:da:d9:92]，表示发往本地以太网接口。源MAC 地址[00:30:88:11:29:c8]，解析为Siara_11:29:c8，应该是提供网络服务的服务器地址。
代码[0x07]表示提供过程，静荷载长度为99字节，其中包含有7个标记：第1个标记是主机的唯一标识，与上一帧相同。第2个标记类型为0102(服务器名) ，表示客户端收到了名为[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1]的服务器的回应。后面的5个标记类型都为0101(服务名) ，表示服务器可以向客户提供的服务有五个，分别是[xyxf][shenyan.ha][iptv.ha][cnc][CNC]。 ③ 第3帧：PADR 请求分组
这一帧的作用是客户端选择一个并向该服务器发出请求，过程对应上文2.2.1-⑶。
目标MAC 地址是提供服务的服务器，源MAC 地址是本地以太网接口。
代码[0x19]表示请求过程，静荷载长度为20字节，其中包含有2个标记：第1个标记是服务名，表示客户端选择了一个服务[xyxf]。第2个标记为主机唯一标识[[**************]0]，相对上两帧的主机标识[[**************]0]有了变化，说明一个主机标识只需匹配一次发送和接收，而不需要一直保持不变。
④ 第4帧：PADS 确认分组
这一帧的作用是服务器收到请求后回应客户端可提供服务，过程对应上文2.2.1-⑷。
目标MAC 地址是本地以太网接口，源MAC 地址是提供服务的服务器。
代码[0x65]表示确认过程，静荷载长度为60字节，其中包含有3个标记：第1个标记是服务名，表示服务器确认了客户端选择的服务[xyxf]。第2个标记为主机唯一标识[[**************]0]，与上一帧对应相同。第3个标记向客户端确认了提供服务的服务器名[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1]。
注意到这一发现帧的会话ID 已经不再是0，而是由服务器分配给客户端的一个唯一的值[0x1ada]。在接下来的会话阶段，该会话ID 将一直保持不变。
2.3.3 PPP帧格式
PPP 帧格式如下图。
Ⅰ“协议”字段取值及含义：
Ⅱ“编码”字段取值及含义(不同的协议类型有所不同) ： ① 链路控制协议LCP ：
1/2/3/4-Configure-Request/Ack/Nak/Reject 5/6-Terminate-Request/Ack 7-Code-Reject 8-Protocol-Reject
9/10-Echo-Request/Reply 11-Discard-Request
在LCP 协议中定义了多种配置选项，封装在载荷域内，分别的取值及含义：
01-最大接收单元MRU 03-认证协议 05-幻数MN 07-协议域压缩PFC 08-地址及控制域压缩ACFC 13/0d-回调控制协议CBCP ② IP 控制协议IPCP ：
2-IP 压缩协议 3-IP 地址 ③ 基于挑战的认证协议CHAP ：
1-Challenge 2-Response 3-Success 4-Failure ④ 压缩控制协议CCP ：
1-7与LCP 相同 14-Reset-Request 15-Reset-Ack
2.3.4 会话阶段分析
数据包文件“PPP 登录”从第5帧开始就是PPPoE 会话阶段的数据帧，如下图。
以上的5-27帧都是以太网帧封装的PPPoE 会话帧(PPPoE Session)，类型(Type)是[0x8864]，表示是会话阶段。PPPoE 会话帧实质都是通过封装的PPP 帧进行通信。这些PPP 帧分为不同的协议，该例中主要协议有：LCP 、CHAP 、IPCP 和CCP ，下面根据PPP 协议流程的阶段顺序逐个分析： ⑴ 链路建立阶段(Establish)
在这个阶段，通信双方用链路控制协议(LCP)配置PPP 链路。这个阶段完成的标识是发起方收到对方发送的LCP Configure-Ack报文。
分析可知，该阶段包含以下6个LCP 协议帧，通过ID 匹配请求与回应，通过ID 匹配两两顺序排列结果如下。
① 第5帧与第7帧
客户端向服务器发送一个Configure-Request 报文试图建立链路，但服务器回应一个Configure-Reject 报文拒绝了客户端的请求。从回应帧的选项可知，拒绝的原因是请求报文中的回调协议控制(CBCP)选项不被服务器识别或接受。为此，客户端在第9帧的Configure-Request 报文中进行了调整。由图可知，这两帧ID 为[0x00]，客户端的最大接收单元为[1480]字节，发出的幻数值为[0x4e7d1279]。
② 第6帧与第8帧
服务器向客户端发送一个Configure-Request 报文请求建立链路，客户端回应一个Configure-Ack 报文通过了服务器的请求，服务器向客户端的链路建立成功。由图可知，这两帧ID 为[0x2e]，服务器的最大接收单元为[1492]字节，发出和收到的幻数值都为[0x56a02122]，表示没有回路。 ③ 第9帧与第10帧
客户端又向服务器发送了一个Configure-Request 报文，这个报文相比第5帧少了回调(Callback)选项，这一次服务器回应一个Configure-Ack 报文通过了客户端的请求，客户端向服务器的链路建立成功。由图可知，这两帧ID 为[0x01]，客户端的最大接收单元还是[1480]字节，发出和收到的幻数值都是[0x4e7d1279]，表示没有回路。
至此，通信双方接收到了对方的Configure-Ack 报文，链路建立阶段完成。
⑵ 认证阶段(Authenticate)
在这个阶段，服务器通过基于挑战的认证协议(CHAP)认证客户端的身份。这个阶段完成的标识是客户端收到服务器发送的CHAP Success报文。
分析可知，该阶段包含以下3个CHAP 协议帧，它们的ID 都是1。 ① 第11帧：Challenge 报文
这一帧是认证方(服务器[MS-ZZ-WHL-RBSE800-001-8Y[1**********]1])向被认证方(客户端[bc:ae:5c:da:d9:92])发送的Challenge 报文，其中包含了长度为16字节的随机数c ，其值为[60d547eeeafb04b4e9bebb0ee035ec69]，该随机数用于MD5算法计算。 ② 第14帧：Response 报文
作为回应，被认证方(客户端) 将双方共享的密值s 与随机数c 作为输入，使用MD5算法计算出散列值A 1，值为[8e9fbe65able4d4ad199b97e0760c636]，通过该Response 报文返回给认证方(服务器) 。 ③ 第17帧：Success 报文
认证方(服务器) 在本地将密值s 与随机数c 作为输入，同用以散列函数计算出散列值A 2，将A 2
与接收到的A 1进行比较，如果A 1=A2，则说明被认证方(客户端) 提供了正确的秘密信息，CHAP 认证成功，返回Success 报文。
至此，客户端收到服务器发送的CHAP Success报文，认证阶段完成。
⑶ 网络层协议阶段(Network)
在这个阶段，服务器通过IP 控制协议(IPCP)为客户端分配IP 地址，双方还通过压缩控制协议(CCP)协商采用什么压缩算法。这个阶段完成的标识是发起方收到对方发送的IPCP Configure-Ack报文。
分析可知，该阶段包含以下8个IPCP 协议帧和2个CCP 帧(其中后一帧封装在LCP 帧中) ，通过ID 匹配两两顺序排列结果如下。
① 第18帧与第21帧
服务器向客户端发送一个Configure-Request 报文请求配置协议，客户端回应一个Configure-Ack 报文通过了服务器的请求，服务器对客户端的网络层协议配置成功。由图可知，这两帧ID 为[0xfd]，服务器给客户端提供的服务器IP 地址为[123.14.232.1]。 ② 第19帧与第22帧
客户端向服务器发送一个CCP 协议的Configure-Request 报文，ID 为[0x04]，协商试图采用微软PPC 的数据压缩算法[MPPC]，但服务器回应一个LCP 协议的Protocol-Reject 报文，拒绝了客户端发送的第19帧中ID 同为[0x04]的CCP 协议包，告诉客户端不要采取数据压缩算法[MPPC]。 ③ 第20帧与第23帧
客户端向服务器发送一个Configure-Request 报文试图配置协议，请求得到IP 地址、DNS 和WINS 服务器地址，但服务器回应一个Configure-Reject 报文拒绝了客户端的请求。从回应帧的选项可知，拒绝的原因是请求报文中的WINS 服务器IP 地址选项不被服务器识别或接受。为此，客户端在第24帧的Configure-Request 报文中进行了调整。由图可知，这两帧ID 为[0x05]。
④ 第24帧与第25帧
客户端又向服务器发送了一个Configure-Request 报文，这个报文相比第20帧少了WINS 服务器IP 地址选项，这一次服务器回应一个Configure-Nak 报文，其中包含了客户端请求的IP 地址[123.14.232.151]和DNS 服务器地址[202.102.224.68][202.102.227.68]，协议配置的必要条件已具备。由图可知，这两帧ID 为[0x06]。 ⑤ 第26帧与第27帧
客户端再向服务器发送一个Configure-Request 报文，再次确认服务器提供的IP 地址和DNS 服务器地址，服务器回应一个Configure-Ack 报文，客户端对服务器的网络层协议配置成功。由图可知，这两帧ID 为[0x07]。
至此，通信双方都接收到了对方的Configure-Ack 报文，客户端得到了服务器IP 地址、服务器分配的本机IP 地址及DNS 服务器地址。网络层协议阶段完成，双方可以传输通信数据。