PPP Establish阶段抓包现象与理论不符

flypanda999 · 发表于 2021-8-15 18:22:05

本帖最后由 flypanda999 于 2021-8-15 22:27 编辑

简介：
想查看一下LCP协商过程（有讨价还价的，而不是直接成交），于是两边都没配三层内容和认证内容，只是把R1的接口MTU值改成了64，R2默认没改，两边封装改成了PPP。协商时抓包，发现R1对应<魔数>的尾数为<6f>，R2对应<魔数>的尾数为<09>;整个协商过程共分三组，对应三个Identifier分别是9、1、10。对于抓包结果我用了三个图来呈现，但是出现了乌龙，学的理论上说“一个Configure-request帧与回应他的Configure-Ack/Nak用同一个Identifier来标识此二者是因果关系的”，但是到我做实验时后两组（Identifier值分别为1和10）都是request和Ack/Nak出自同一端。做了好几次实验，除了<魔数>和<Identifier>具体数值不同之外，全都有这种问题。求高手指点一下，到底是什么情况。谢谢了

eigrpospf · 发表于 2021-8-15 18:22:06

本帖最后由 eigrpospf 于 2022-4-4 08:28 编辑

仔细看了一下楼主抓包的内容，也做了模拟实验，实验现象跟楼主一摸一样。楼主能提出这么深入的问题的确是令人敬佩的，

上网看了一些资料都没有很好的答案，说不到点子上，下载了RFC1548仔细阅读，模拟器开启
debug ppp negotiation
发现实验是最有说服力的。

LCP协商的过程实际是一个有限自动状态机（也叫图灵机），一共有10种不同的状态(0-9), 一个事件event/一个行动action都可以导致状态变化，
从Initial state(Link Dead phase) 开始，经过一系列状态变化，最后到达Opened状态，表示初始连接建立完毕，后面可以继续进行authentication等进一步
协商了。

xiaoyilong520 · 发表于 2021-11-20 23:19:51

大师的大师

xiaoyilong520 · 发表于 2021-11-20 23:20:18

啊啊按时的

eigrpospf · 发表于 2022-4-2 14:48:56

本帖最后由 eigrpospf 于 2022-4-4 08:03 编辑

貌似模拟器抓包出现的问题?
PPP协议集由以下三大协议组成：
链路控制协议LCP
认证协议
网络控制协议NCP

eigrpospf · 发表于 2022-4-4 08:38:18

读过RFC1548可以了解到：
Magic Number主要是用来探测环路的，探测环路场景下代表某一方的identity;
不论哪一端R1/R2，都是非常清楚那个数据包是接收到的(Input),哪个是自己发出的(Output);
一旦收到一个config-request请求，如果同意，发config-ACK包时，需要原封不动的把请求包内option的内容附上！

eigrpospf · 发表于 2022-4-4 08:42:46

记得有人讲过“代码才是最好的文档！”一点都不假。
网上搜索的一些所谓的讲课内容其实都很不靠谱，
比如说Magic Number就是用来标识数据发送方的，借此可以判读数据包走向。部分正确，因为这只是在环路探测时有效；
比如说LCP协商的过程是双方各自发起一个会话过程。部分正确。其实是一个图灵机的自动状态切换；

eigrpospf · 发表于 2022-4-4 08:51:49

读完RFC1548再来看楼主发现的乌龙，其实是正常的协商过程。
第一个乌龙：
Frame7, R2发出config-Request请求协商magic-number;
FRame9, R1回包config-Ack完全同意！所以回包时原封不动的附上了R2发来的请求内容；
这就是为什么看到的magic number相同的原因；
这里的magic-number不能表示是哪一方发的包！

eigrpospf · 发表于 2022-4-4 08:59:40

再看第二个乌龙也是正常的协商过程，并非WOOLOON,
Frame6 : R1->R2, config-request(MRU=64) R1发起请求64可否？
Frame8: R2->R1, config-NACK( MRU=1500) R2答复不可！必须用1500!
Frame10: R1->R2, config-request(MRU=1500) R1修改了请求，1500可否？请求中也包含了magic-number option；
Frame11: R2->R1, config-ACK( MRU=1500) R2答复:完全同意！所以回包时原封不动的附上了frame10中收到的请求内容，这就是为什么回包中看到了R1的魔数的原因！

eigrpospf · 发表于 2022-4-4 09:09:40

为楼主勤学苦练的精神点赞！
能提出这样的问题不简单！
记得一个传说的故事，很多很多年前，某大厂高仿的2501路由器刚刚上市，在某个用户安装时，跟cisco设备通过串口互联出了问题，不通，在现场搞实施的工程师抓包后分析，也提出了类似的问题，说思科的LCP程序有bug，magic number搞错了导致无法连通。传说而已，请勿对号入座！

flypanda999 · 发表于 2022-5-3 11:49:01

eigrpospf 发表于 2022-4-4 09:09
为楼主勤学苦练的精神点赞！
能提出这样的问题不简单！
记得一个传说的故事，很多很多年前，某大厂高仿的 ...

谢谢您~回复了这么多。辛苦辛苦

flypanda999 · 发表于 2022-5-3 12:32:08

eigrpospf 发表于 2022-4-4 09:09
为楼主勤学苦练的精神点赞！
能提出这样的问题不简单！
记得一个传说的故事，很多很多年前，某大厂高仿的 ...

我只是刚学，老师说抓包助学，所以学到一个地方就想抓来看看，谢谢您的耐心讲解和鼓励，受益匪浅，受益匪浅

账号		自动登录	找回密码
密码			论坛注册

[求助] PPP Establish阶段抓包现象与理论不符

最佳答案

客服中心

投诉建议