PPPoe的抓包分析（详细）

PPPoe的报文结构

可以看出PPPoe的报文结构其实很简单，只不过是将PPPoe的报文塞到以太网的载荷中，而且它的头部字段也十分的简单，TLV就不说了，code字段表示了PPPoe不同的报文类型，比较常见的就是上面的五个报文了，PPPoe的报文类型其实还蛮多的。session ID主要的作用就是标识一段会话，因为使用PPPoe的最主要作用就是使得多台设备可以借助以太网多点接入多点访问的特点去和一台设备做上网认证请求，这样运营商一台认证设备就可以满足多个用户的认证请求，这和PPP相比起来好的不止一点。虽然传统的广域网链路的传输距离比较长，但是速率低是它的痛点，而且随着以太网的发展和光纤的发展，用户连接到运营商的介质不仅仅局限于双绞线，所以像传统的广域网链路在用户于运营商之间也越来越少了。

PPPoe的头部后面就是PPP的报文了，因为我们需要的是ppp协议中的认证功能，所以自然需要有完整的ppp报文去完成这一部分的功能。

1、PPPoe的发现阶段

因为是将ppp在以太网上实现，所以在一个广播链路上可能有多个相关的PPPoe服务端，所以PPPoe的发现阶段和DHCP的发现阶段十分的相似

我们现在来抓包分析一下它的发现过程：

 1、首先发送Init的初始报文去寻找PPPoe的服务端，下面是init初始报文

 可以看到初始报文比较简洁，在以太网载荷部分，也就是PPPoe的有效内容部分，存在的只有PPPoe的头部，我们现在可以看到Session ID此时是全0，因为此时我们还没有和服务端取得联系，还没有建立会话。

2、服务端回送一个offer报文，表示它可以提供一个PPPoe的服务

 

可以看到offer报文的内容也是十分的简洁，PPPoe的有效内容部分仅仅包含着PPPoe的包头，其实我们也能够理解，因为PPPoe的会话发现阶段并不需要其他的内容，我们只要通过init和offer报文互相发现，互相确认即可。

3、客户端发送request报文，表示希望请求该服务端的PPPoe服务

 同样request报文也很简洁，我就不赘述了

4、服务端发送session-confirm表示对建立的会话的确认

这个报文同样很简洁，我们还可以发现上面三个报文的session-ID都是0，但是因为最后一个报文是服务器端确定了客户端要使用自己的PPPoe的服务，所以它就生成了PPPoe的session-ID填入到session-confirm中表示我已经将会话建立起来了，你后面使用这个session-ID就好。

5、正常的PPP链路协商

 协商的细节我在另一篇博客里面有写这里就不赘述了