这个周为了解决一个PPPoE的问题,自己专门研究了一下PPPoE,通过抓包文件来详细的说一下
在wireshake中使用"pppoed || pppoes"来过滤其他无关的包,以免干扰分析.
PPPoE 可以分为 发现阶段和绘话阶段(LCP,CHAP,NCP(IPCP,BCP,IPV6CP))
发现阶段:
PADI:
Destination,Source,Type 属于以太帧的首部,目的地址是以太网的广播地址(0xffffff),源地址写的是自己的网卡地址
其中Type (0x8863) 表示目前处在发现阶段, (0x8864) 表示目前处在绘话阶段,
version 表示PPPoE的协议版本(1个字节),Type 表示类型 1个字节,
PPP-over-Ethernet Discovery:
code 表示PPPoE绘话类型占两个字, 0x09 :PADI,0x07:PADO/PADT,0x19:PADR,0x65:PADS
session ID 目前尚未建立绘话,填充为0
Payload Length 表示整个PPPoE Tags的长度
PPPoE-Tags 占12个字节 由 一个或者多个TLV组成
01 03 标识主机唯一标识(TYPE)
00 04 表示Host-Uniq的长度(LENGTH)
40 2f 00 00 表示数值(VALUE)
PADO:
当主机在指定时间内没有收到PADO,它应该重新发送它的PADI分组,并且加倍等待时间,这个过程会被重复期望的次数
PPPoE-Tags 占48个字节,由三组TLV构成(Host-Uniq,AC-cookie,AC-Name)构成, Host-Uniq 不在分析.
AC-cookie 01 04 表示 TYPE, 00 10 表示LEGNGTH, 还有一个VALUE
AC-Name 01 02 表示TYPE, 00 0c 表示LEGNGTH , 还有一个VALUE
PADR:
PADS
:
session ID 已经赋值,表名绘话建立成功,下一步进入绘话阶段
绘话阶段
LCP
LCP协商阶段完成最大传输单元(MTU) ,是否进行认证和采用何种认证方式(Authentication Type)的协商
LCP协议报文分类:
链路配置报文: 用来建立和配置一条链路 报文有Configure-Request,Configure-Ack,Configure-Nak,Configure-Reject
Configure-Ack 如果完全支持对端的LCP选项,就回复ACK,报文中必须携带Request报文中的参数选项
Configure-Nak 如果支持对端协商选项,但是不认可该项协商的内容,则回应Configure-Nak报文,在Configure-Nak选项中填上自 己认可的内容
Configure-Reject 如果不支持对端的协商选项则回应Configure-Reject,报文中带上不支持的选项....
链路维护报文:用来管理和调试链路 报文有Code-Reject,Protocol-Reject, Echo_Request,Echo-Reply,Discard-Request
链路终止报文:用来终止一条链路 Terminate_Request和Termiate-Replay
如果一端发送request之后, 对端没有回复ack,那么将继续发送request,直到对端回应ACK报文.如果双方发送的request,都接到了对端的发送的ACK,则链路成功建立.
Configuration Request:(c->s)
Point-to-Point Protocol
code : Configuration Request(1), Configuration Ack(2),
Identifier (从0开始增长, 每一组应答( Configuration Request,Configuration Ack)中Identifier都是一样的,存在的意义就是确定请 求与应答)
Options: 包含 Max Receive Unit(MTU) ,Magic Number
Configuration Ack:(s->c):
如果对端同意参数配置,那么对端就会发送 Configuration Ack,如果不同意的话,就会返回Configuration Nck(把存在异议的参数配置写到包中)
Configuration Request:(s->c)
Configuration Request:(s->c)的请求中比Configuration Request (c->s)中多了一个ACHP的参数,这是用来下一步做认证的参数,同样在Configuration Ack:(c->s)也会携带这个数据.
Configuration Ack:(c->s)
在绘话阶段,客户端与服务器端会通过 Echo Request/Echo Reply 来维持绘话
CHAP/PAP:
pap:在网络上是用明文传递用户名和口令,不安全
IPCP:
119 Configuration Request:(s->c) : 服务端给客户端一个IP地址(网关地址)
120 Configuration Request:(c->s) : 客户端告知服务器端 本机IP,主要DNS,次要DNS(地址都是0000)
121 Configuration Ack:(c->s) : 客户端表示同意
122 Configuration Nak:(s->c) : 服务端表示不同意,于是就给客户端分配IP,主要DNS,次要DNS
123 Configuration Request:(c->s) : 客户端告知服务器端 本机IP,主要DNS,次要DNS(server端分配的)
124 Configuration Ack:(c->s) : 服务端表示同意
客户端就可以使用分配的ip上网了.
在分析过程中,困扰我的是出问题的包中,建立了多次绘话, 多个绘话的请求和应答交互出现,分析起来比较头疼,后来突然看到SessionID 和Identifier,突然想明白可以依赖这俩字段在众多的包中找出一个完整的交互过程来.
SessionID 用来确定一个绘话, Identifier可以用来确定一组应答(双方的request中Identifier都是从1开始递增的, Identifier最早出现在LCP协商的request中,比如说 A->B的request中Identifier为1,那么B->A的应答中Identifier也为1)
==================================================================================
