PPPoE有两个截然不同的阶段，即发现阶段（Discovery stage）及PPP会话阶段（PPP Session stage）。
对于发现帧而言，这个值或者是单播地址，或者是广播地址，就如在发现一节中所描述的一样。
对于PPP会话通信，这个域必须包含对方的单播地址，该地址由发现阶段决定
以太包类型（ETHER_TYPE）被设备为0x8863（发现阶段）或者0x8864（PPP会话阶段）
PPPoE的以太有效载荷如下所示
VER域占用4位，对于本版本的PPPoE规格说明书，必须设置为0x1。
TYPE域占用4位，对于本版本的PPPoE规格说明书，必须设置为0x1。
CODE域占用8位，对于发现阶段和PPP会话阶段，它的定义稍后再做描述
SESSION_ID域占用16位。这是一个网络字节顺序的无符号数值。它的值在发现包中给出。
对于给定的PPP会话，这个值是固定的，并且，事实上，它与以太网源地址和目标地址一起定义了一个PPP会话。
0xffff是保留值，可能在将来会被使用，但现在必须不能使用。
LENGTH域占用16位。这个网络字节顺序的值，指出PPPoE有效载荷的长度。它不包括以太包及PPPoE包头
在发现阶段有4个步骤。当它完成时，两端都将知道PPPoE的会话ID及对方的以太网址，
而且它们一起唯一标识了PPPoE会话。
这些步骤包括：主机广播一个初始（Initiation）包，一个或者多个访问集中器发送提议（Offer）包，
主机发送一个单播会话请求（Session Request）包，被选择的访问集中器发送一个确认（Confirmation）包。
当主机接收到这个确认包时，它就可以进入到PPP会话阶段了。当访问集中器发送了确认包以后，它就可以进入到PPP会话阶段了
4个步骤 : 这些步骤的协议都是PPPoED 都是Discovery
eth.addr == 98:bc:57:46:52:d2 and eth.type==0x8863
1,wifi 广播一个Init包: PADI, code=0x09
Host-Uniq为主机唯一标识，类似于PPP数据报文中的标识域，主要是用来匹配发送和接收端的。
因为对于广播式的网络中会同时存在很多个PPPoE的数据报文
主要发表自己的host_uniq. （这个值是怎么生成的，随机数么，每个wifi模块的值是不相同的）
有时候，发了三个broadcast包，都没有人回应，真气死wifi模块了。 （每隔5秒钟发一次这种包）
10148 : 包号，host uniq 05040000 包长=60，
2,访问集中器的回应是： PADO, code=0x07, discovery offer
AC-Name的Tag（包含了访问集中器的名字 AC-Name: xu2_ACR_1 Host-Uniq: 05040000
Ac-Cookie是为了防止拒绝服务攻击（Denial of Service，简称DOS）。
访问集中器（AC）能够根据PADR的源地址来重新产生唯一的Tag_Value。使用这种方法，
AC可以确保PADI的源地址是可达的，并对该地址的并行会话数进行限制
主要是说：Ac_name , 和Ac_cookie. AC-Cookie: af5f1732c77f9860f718ec0bf7efd9cd
10149 : 包号 包长=65
3,wifi --->集中器 PADR :discovery request,
可能有多个响应服务器：主机向选中的AC单播一个PADR数据包。
目的地址域为AC的MAC地址，Code = 0x19，会话ID域必须置为0x0000
Host-Uniq: 05040000 AC-Cookie: af5f1732c77f9860f718ec0bf7efd9cd
当主机在指定的时间内没有接收到PADO，完整它应该重新发送它的PADI分组，并且加倍等待时间，这个过程会被重复期望的次数
10150 : 包号， 包长=60，
4. 集中器 ---> wifi PADS：PPPoE发现阶段最后一步。discovery session-confirmation
当AC在收到PADR报文时，就准备开始一个PPP的会话了。
它为PPPoE会话创建一个唯一的会话ID并用单播一个PADS数据包来给主机做出响应。
目的地址域为主机的MAC地址，Code域置为0x65，会话ID必须设置为所创建好的会话ID
Session ID 肯定不是0 了，
不带Ac_cookie, 但分配Session ID. Host-Uniq: 05040000
10152 : 包号， 包长=60，
以上的过滤protocol : PPPoED
在会话阶段发的包：
发现一个包： 集中器－－－＞wifi: code=0xa7: 活动发现终止(PADT) 包
差不多每隔30秒，wifi 发送 broadcast包给 集中器， 表示自己还活着，
但是，集中器 觉得很烦，就发送了一个code=0xa7的包。
因为，集中器刚刚开始是不发a7的包的，你都连接上了了，还发discovery的包干啥？
====后来发现这不是心跳包，这是每30秒发送一次broadcast包，而被拒绝的后的终止包。
AC-Name: xu2_ACR_1
AC-Cookie: 7e5a0a6d45816591903bdbaa1dfeb2bc
AC-Name: xu2_ACR_1
AC-Cookie: aa18669c5554c740fbe9c4d183fbddb2
AC-Name: xu2_ACR_1
AC-Cookie: 6030f5c1d3e6cc33be956e6244dea36d
AC-Name: 是一样的，但ac_cookie是不一样的。
10152 18:00:13.677821
（Link Control Protocol）
所有的发现阶段的以太帧，都要将ETHER_TYPE域的值设置为0x8863。
http://wenku.baidu.com/link?url=ewIHWf6kVYaomNynb29cHUFNeEgxNx4_ZT0rUC90FKa1-MsvoRy4eBzu1KfYqWA1jsuxY8aMI4S-dHeCNNfvOeH21bp9C-Gg6hzyXd7Y2Be
TAG_TYPE域占用16位，使用网络字节顺序。附录A包含了所有的标签类型（TAG_TYPE）及它们的标签值（TAG_VALUE）。
TAG_LENGTH域占用16位，它是网络字节顺序的无符号数值，指出标签值的所使用的字节（8位）数
5.1、 PPPoE活动发现初始(PADI) 包
主机发送PADI（PPPoE Active Discovery Initiation）包，
此时目标地址被设置为广播地址。CODE域设置为0x09，同时，SESSION_ID必须被设置为0x0000。
PADI包必须包含正确的、类型为服务名称（Service- Name）的标签，用于指出主机正在请求的服务。
也可以包含任意数量的其他标签类型。整个PADI包（包括PPPoE包头），必须不超过1484字节（8位），
以便有足够的空间用于中继代理增加中继会话ID（Relay-Session-Id）标签
PPPoE活动发现提议(PADO) 包
当访问集中器接收到它可以提供服务的PADI包，它通过发送一个PADO（PPPoE Active Discovery Offer）包来响应。
目标地址是发送PADI的主机的单播地址。CODE域被设置为0x07，同时，SESSION_ID必须被设置为0x0000。
PADO包必须包含一个AC名称（AC-Name）标签，其中有访问集中器的名称；
同时，必须包含一个服务名称（Service-Name）标签来标识PADI中的服务名称，同时可以包含
任意数量的其他服务名称（Service-Name）标签来指出该访问集中器提供的其他服务。
如果该访问集中器不能为这个PADI包提供服务，则它必须不能用PADO做出应答
PPPoE活动发现请求(PADR) 包
因为PADI是广播包，所以主机可能接收到多个PADO。主机需要审核这些PADO包，并且从中选择一个。
这个选择可以基于所提供的AC名称（AC-Name）或者服务。然后，主机发送PADR（PPPoE Active Discovery Request）
包给被选中的访问集中器。目标地址被设置为这个发送PADO的访问集中器的单播以太网地址。CODE域被设置为0x19，
同时，SESSION_ID必须被设置为0x0000。 PADR包必须包含一个正确的服务名称（Service-Name）标签，
该标签指出主机所请求的服务。同时可以包含任意数量的其他标签
PPPoE活动发现会话确认(PADS) 包
当访问集中器接收到PADR包时，它开始准备开始一个PPP会话。它为PPPoE会话创建一个唯一的会话ID（SESSION_ID），
并用PADS（PPPoE Active Discovery Session-confirmation）包回复给主机。目标地址域设置为发送PADR的主机的单播以太网地址。
CODE域设置为0x65，同时，SESSION_ID必须设置为刚为本次PPPoE会话创建的唯一值。
PADS包包含一个正确的服务名称（Service-Name）标签，该标签指出这个接收了PPPoE会话的访问集中器的服务。
同时可以包含任意数量的其他标签。
如果访问集中器不喜欢PADR中的服务名称，则它必须在回复的PADS中包含服务名称错误（Service-Name-Error）标签
（以及任意数量的其他标签）。这时，SESSION_ID必须被设置为0x0000
PPPoE活动发现终止(PADT) 包
这个包可以在会话建立之后的任意时刻发送，用于指出这个PPPoE会话已经被终止。
主机或者访问集中器都可以发送这个包。目标地址被设置为单播以太网地址，CODE域被设置为0xa7，SESSION_ID MUST必须设置为将被终止的会话的ID。
这个包不需要任何标签。 当接收到一个PADT（PPPoE Active Discovery Terminate）时，任何使用该会话的PPP通信都是不允许的。
在发送或者接收到一个PADT后，即使正常的PPP终止包也必须不再被发送。PPP端应该使用PPP协议本身来关闭一个PPPoE会话，
但PADT可以用于PPP不能使用的情况。
6、 PPP会话阶段
一当PPPoE会话开始以后，PPP数据就象任何其他PPP封闭一样被发送。所有的以太包都是单播的。ETHER_TYPE域被设置为0x8864。
PPPoE的CODE必须被设置为0x00。对于这个PPPoE会话，SESSION_ID必须不能被改变，并且必须是发现阶段指定的值。
PPPoE有效载荷包含一个PPP帧。该帧以PPP协议ID开头
LCP考虑
魔数LCP规则说明选项是被推荐的，而协议域压缩（PFC，Protocol Field Compression）选项则是不推荐的。
它的实现必须不请求以下任意的选项，并且，必须拒绝这些选项： Field Check Sequence (FCS) Alternatives
Address-and-Control-Field-Compression (ACFC), Asynchronous-Control-Character-Map (ACCM)
最大接收单元（MRU，Maximum-Receive-Unit）选项必须不超过1492。因为以太网有1500字节（8位）的最大有效载荷限制，
而PPPoE头有6字节（8位）并且PPP协议ID包含2字节（8位），所以，PPP的MTU必须不超过1492。
推荐访问集中器不定期的发送回音请求（Echo-Request）包给主机，以此决定这个会话的状态。
否则，如果主机不发送终止请求（Terminate-Request）包即终止一个会话，访问集中器将不能判断这个会话是否已经过时
当LCP终止时，主机和访问集中器必须停止使用这个PPPoE会话。如果主机希望开始另一个PPP会话，它必须返回到PPPoE发现阶段
(pppoes or pppoed) and !tcp and !icmp and !udp and eth.addr == 98:bc:57:46:db:25
pppoed and !tcp and !icmp and !udp and eth.dst==ff:ff:ff:ff:ff:ff
10154 18:00:13.6846 : 包序号。
二、会话阶段
假如：wifi模块 发了ppp lcp的echo request后，多长时间没有得到回应，就会认为 pppoe断开了，就会去重新发送 lcp的协商包。
隔多长时间去发送呢？
以下的协议都是 PPP LCP
1，10153：集中器－－－＞wifi: Configure Request; session id=1, LCP=0xc021, Code＝01（表示Configure Request,请求同意Option中的内容） 包长=60，
identifier=0x81: option: MRU=maximum receive unit=1492,password Authentication protocol =(0xc023), magic number=0f b1 bd 53
2,10154: wifi--->集中器： Configure Request; session id=1, LCP, Code＝01，identifier=0x01, option; magic number=de 59 d4 06.
3,10155集中器－－－＞wifi: Configure ACK,code=2(完全同意) magic number=de 59 d4 06 ： 这个magic是wifi生成的。
4,10527 : wifi--->集中器：code=1; Request: 这个包和10154的包，完全相同， 重复发送，为啥重复发送，吃多了?
5,10528: 集中器－－－＞wifi: ACK 和包 10155 完全相同， 又重复发。
6,10540： 集中器－－－＞wifi: Configure Request 和包10153 完全相同，重复，
这两个发包顺序怎么会挨着，按理说，你发一个，我回一个，你发我回；现在是你发两个，我才慢慢回，pppoe server真白痴。
难道是抓包工具的问题，抓包有延迟么？或者抓包把顺序给排乱了？
7，10542：wifi--->集中器：ACK code=2, MRU=1492,Authentication protocol=0xc023, magic number=0f b1 bd 53.
内容几乎和10153是完全相同的，就code不一样，
8，10543：wifi--->集中器：code=9(echo request): Identifier:0， magic number=de 59 d4 06 ===== 发这个包也没有啥意思？
验证服务器会定时向用户发送Echo-Request数据包，用户则会回应一个Echo-Reply数据包，它们的作用是测试连接是否正常，如果服务器多次没有收到用户的Echo-Request，就认为用户已经失去响应，并断开连接。
PAP: 认证过程：0xc023
9, 10544: wifi--->集中器：protocol=ppp PAP (0xc023): Protocol=Password Authentication (0xc023), code=1（Authentication request）: data= peer_id 是 ocnngbtest1 ,password=cqhhz.
10,10545:集中器－－＞wifi:LCP c021: code=10; echo reply,magic number=0f b1 bd 53. 仅仅是包10543的回应包。
11,10547:集中器－－＞wifi:protocol=ppp PAP (0xc023): code=2,Authenticate-ack. message ==login ok.
IPCP: 拿IP和DNS的过程：(0x8021)
12,10548:集中器－－＞wifi:code=1,Configuration Request: Identifier:(0x9b) IP Address=114.60.32.1, 发这个IP是干啥的，没有想通？
13,10550:wifi--->集中器： code=1,Configuration Request: Identifier =1 IP, DNS，second DNS, 这些内容都是空或者0，
14,10551:wifi--->集中器： code=2,Configuration ACK , Identifier:(0x9b) IP Address=114,60,32,1.
15,10552:集中器－－＞wifi:code=3,Configuration NAK, Identifier =1 ,IP=114.60.45.224,DNS=219.233.241.164, second dns=219...165.
16,10557:wifi--->集中器： code=1;request,identified=2, IP=114.60.45.224,DNS=219.233.241.164, second dns=219...165
17,10558:集中器－－＞wifi:code=2;ACK； identified=2, IP=114.60.45.224,DNS=219.233.241.164, second dns=219..
PPPoe就是用户拿到最终结果：IP地址和DNS就算，second NDS就算 PPPOE拨号成功了。完成了，
一般情况下，从pppoe开始到拿到IP ，5秒钟就结束了。
1,10705: wifi--->集中器：开始使用TCP，大家都开始用IP地址了： wifi的地址是： wifi--->集中器：114,60,45,224---》101.227.169.161.
集中器的端口是443， 为啥是443，
2.4 会话维持（Session Keep-alive）
设备主动发送Echo Request进行PPPoE心跳保活，若3次未得到服务器的响应，则设备主动释放地址。
发LCP Echo Request 的时候，魔术字字段要和之前通信的Configure_Request使用的魔术字字段保持一致。
有些设备或终端不支持主动发送 Echo-Request 报文, 只能支持回应Echo-Reply报文。
心跳包： 是 会话阶段的包， 都是 ppp LCP
ppp.protocol==0xc021 and eth.addr==98:bc:57:46:52:d2 每隔30秒钟发一次，
30秒之后的心跳包是：
16468：wifi--->集中器：echo request identified=０, Magic Number: 0x0fb1bd53
16469：集中器－－＞wifi ：Echo reply Magic Number: 0x0fb1bd53
16470： wifi--->集中器：echo request identified=１, Magic Number: 0xde59d406
16471：集中器－－＞wifi ：Echo reply identified=１ Magic Number: 0x0fb1bd53
上面四句话，不知道干啥，因为这四句话，在一秒钟之内完成的。
30秒之后是：
18468 wifi--->集中器：echo request
18469：集中器－－＞wifi ：Echo reply 感觉 wifi是主动的，难道pppoe就不主动么，这么懒。
30秒之后是：
23292：wifi--->集中器：echo request
23293：集中器－－＞wifi ：Echo reply
1,30932: wifi--->集中器： echo request Magic Number: 0xde59d406
2,30945：集中器－－＞wifi ：Echo reply,Magic Number: 0x0fb1bd53
若3次未得到服务器的响应，则设备主动释放地址，即 最长为90秒，就收回IP了，释放session ID了。
!tcp and !icmp and !udp and eth.addr == 98:bc:57:46:db:25
如果密码错误的话，会走下列流程：
24088, wifi--->集中器： Protocol: Password Authentication (0xc023) Code:=1: Identifier: 216， data = Peer-ID: ocnngbtest1, Password: dyrcj
24166,集中器－－＞wifi c023;Code: Authenticate-Nak (3).Identifier: 216，Message: Login incorrect
24167,集中器－－＞wifi c021 Code: Termination Request (5) Identifier: 175 (0xaf)
24168,wifi--->集中器： c021 Code: Termination Request (5)Identifier: 176 (0xb0) Data: 4661696c656420746f2061757468656e746963617465206f... 带这个data干啥的？ 吓唬人的么？
24169,wifi--->集中器：c021 Code: Termination Ack (6) Identifier: 175 (0xaf)
24170,集中器－－＞wifi c021 Code: Termination Ack (6) Identifier: 176 (0xb0)
24171,集中器－－＞wifi Code: Active Discovery Terminate (PADT) (0xa7)
如果用户名或者密码错误了，隔30秒钟就开始再发一次broadcast,LCP
PPP会话的建立，需要两端的设备都发送LCP（Link Control Protocol）数据包来配置和测试数据通信链路。
LCP报文可以分为三类：链路配置报文（LCP Configure Request，LCP Configure Reject，LCP Configure Ack和LCP Configure Nak）、链路终止报文和链路维护报文。
Ⅰ 协商阶段
LCP的Request主机和AC都要给对方发送，LCP协商阶段完成最大传输单元，是否进行认证和采用何种认证方式的协商。
LCP协商阶段的数据帧由三部分组成：以太网头，PPPoE头和PPP头。PPPoE Session的以太网类型域为0x8864。
PPP信息包括：Code＝01（表示Configure Request,请求同意Option中的内容）
02（表示Configure Ack，完全同意）
03（表示Configure Nak，同意部分Option中的内容，还需要再协商）
04（表示Configure Reject，完全不同意）
06（Terminate Ack，正常下网）
1. 当Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，
接收端将会给对端回一个Config-Ack报文并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内。
2. 当接收Config-Request报文的一端能识别发送端所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，
接收端将会给对端回应一个Config-Nak报文，该报文只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。
当接收端接收到Config-Nak报文后，会重新新发送Config-Request报文。这次的报文和上一次报文的区别在于那些被对端不认可的配置参数选项的内容被
替换成Config-Nak报文里面相应的内容。
3. 当接收Config-Request报文的一端不能识别所有发送端发送过来的配置参数选项时，此时接收端将会向对端回一个Config-Reject报文，
该报文中的数据域只携带那些不能识别的配置参数选项。当对端接收到Config-Reject报文后，会再次发送Config-Request报文，只是将不被识别的那些配置参数选项给删除了。
Ⅱ 认证阶段
会话双方通过LCP协商好的认证方法进行认证，如果认证通过了，才可以进行下面的网络层的协商。
认证过程在链路协商结束后就进行。但此时可能链路质量的协商还在进行。所以会延缓认证过程。
认证阶段包括：Challenge Packet Identifier ,Response Packet Identifier. Success Packet Identifier
和Failure Packet Identifier
认证报文包括：以太网头，PPPOE头，PPP头和CHAP头（采用的是Chap认证）。
以太网头和PPPOE头跟LCP中的相似。PPP头中，Protocol＝0xc223（Challenge Handshake Authentication）
认证通过要经过三个步骤：首先AC发送Challenge Packet Identifier，
然后客户端发送Response Packet Identifier，最后AC发送Success Packet Identifier。
认证失败要经过三个步骤：首先AC发送Challenge Packet Identifier，然后客户端发送两次Response Packet Identifier，
最后AC发送 Failure Packet Identifier。
Ⅲ IPCP协商阶段
用户和接入设备对IP服务阶段的一些要求进行多次协商，以决定双方都能够接收的约定。
如：IP业务阶段使用的IP压缩协议等。双方的协议是通过报文中包含的Option项进行协商的，
每一个Option都是一个需要协商的问题。最后双方都需要对方答复Configure_Ack的同意报文。
IPCP阶段的报文：以太网头，PPPoE头，PPP。以太网头和PPPOE头跟LCP阶段相同。
PPP中存放的是多个Option。Option格式与LCP的TLV相同。
Configure_Request：要求协商的Option
Configure_Nak：表示对收到的Option都可识别，但是一些不能够接收。
Configure_Ack：表示对收到的都能够接收。
Configure_Reject：收到的Option不能够接收。
达成一致后，进入数据包的真正传输阶段，即IP阶段。
用户和AC之间通信都开始使用对方的IP地址而不是MAC地址。
转自：http://blog.sina.com.cn/s/blog_4db83b6f01000apf.html
Ethernet II, Src: 98:ab:00:11:00:02 (98:ab:00:11:00:02), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Ethernet II, Src: AvaTechn_46:fc:ca (98:bc:57:46:fc:ca), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Ethernet II, Src: SvaTechn_46:db:ee (98:bc:57:46:db:ee), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Ethernet II, Src: SvaTechn_46:db:25 (98:bc:57:46:db:25), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Ethernet II, Src: SvaTechn_46:52:d2 (98:bc:57:46:52:d2), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
本文主要的分析的最后一个。
AC-Name: xu2_ACR_1
AC-Cookie: 7e5a0a6d45816591903bdbaa1dfeb2bc
AC-Name: xu2_ACR_1
AC-Cookie: aa18669c5554c740fbe9c4d183fbddb2
AC-Name: xu2_ACR_1
AC-Cookie: 6030f5c1d3e6cc33be956e6244dea36d
SvaTechn_46:fc:ca (98:bc:57:46:fc:ca
1,13678 包号：Ethernet II
http://blog.csdn.net/phunxm/article/details/9384123
4.Linux中的PPPoE拨号守护进程 pppd：Point-to-Point Protocol Daemon
pppd是一个后台服务进程(daemon)，是一个用户空间的进程，所以把策略性的内容从内核的
PPP协议处理模块移到pppd中是很自然的事了。pppd实现了所有鉴权、压缩/解压和加密/解密等扩展功能的控制协议
pppd只是一个普通的用户进程，它如何扩展PPP协议呢？
这就是pppd与内核中的PPP协议处理模块之间约定了，它们之间采用了最传统的内核空间
与用户空间之间通信方式：设备文件 设备文件名是/dev/ppp。通过read系统调用，
pppd可以读取PPP协议处理模块的数据包，当然，PPP协议处理模块只会把应该由pppd处理的数据包发给pppd。
通过write系统调用，pppd可以把要发送的数据包传递给PPP协议处理模块。
通过ioctrl系统调用，pppd可以设置PPP协议的参数，可以建立/关闭连接。
LCP 协议=0xc021
PAP 协议=0xc023
CHAP 协议=0xc223
IPCP 协议=0x8021
IP 协议=0x0021
编码 LCP包类型 含义
0116 Configure-request 提出链路配置的选项和特定的值
0216 Configure-ack 接受对方提出的选项
0316 Configure-nak 不接受某些选项
0416 Configure-reject 不识别某些选项
0516 Terminate-request 请求关闭连接
0616 Terminate-ack 接受关闭连接
编码字段用来说明CHAP包的类型。CHAP包的类型和编码如表2所示。
编码 CHAP包类型 含义
0116 Challenge 系统向用户发出查问值
0216 Response 用户向系统返回计算结果和用户名
0316 Success 认证通过，允许访问
0416 Failure 认证未通过，禁止访问