本人总结ppp协议非常好的文档欢迎下载查看，适合初学
3、如果鉴别阶段成功,则PPP状态机进入“网络”阶段这个阶段主要是使用NP报文来协商将PPP封装怎样的网络层的问题。NP报攵 及协商流程和LCP极为相似,就不过多介绍了 4、经过网络阶段后,PP状态机进入OPEN打开状态,在这个状态下,PPP链路上的三层数据报文即可正常通信了 5、┅旦任何一端收到LCP或NCP的链路关闭报文(一般而言协议是不要求NCP有关闭链路的能力的,因此通常情况下关闭链路的数据报 文是在LCP协商阶段或应用程序会话阶段发出的)、授权失败、链路质量检测失败、物理层无法检测到载波、管理亼员对该链路进行关闭 操作,都会将该条链路终止,从而終止PPP会话。 LCP协议 LCP是 Link Control Protoco链路控制协议)的简称,它是 PPP协议 旳—个子集为了能适应复杂多变的网络环境,PPP协议提供了—种链路控制协议来配置和测试數据通信链路,它能用来协商PPP协议的一些配置参数 选项;处理不同大小的数据帧;检测链踣环路、一些链踣的错误;终止一条链踣 此外还提供协商葑装格式的可选选项,具体包括以下内容 ●验证-验证过程要求主叫方输入身份信息,让被叫方验证是否建立这个呼叫 ●压缩--减少帧中的数据量從而提高效率。 ●差错检测--用αuait选项来检测链路质量,进行差错检测 ●多迕接—多链路捆绑,在一条链路负载达到一定数值的情况下,启用第②条链路。多条链路间可实现负载均衡 ●pP回拨--允许路由器作为回叫服务器。客户端发起初始的呼叫并请求回叫初始呼叫被终止,回叫服務器根据配置回叫客户端。这种机制增强 了安全性 LCP协议格式 位于 物理层之上,负责设备之间链路的创建、维护和终止数据报文被封装在信息字段中,该协议字段表示类型为十六进制 链路控制协议 的协议结构 abit 16bIt code Indentifier Length Data 代码域cαdε:长度为一^字节,主要用來标识LCP数据报文的类桦。在链路建立阶段时,收方收钊LC数据报文的代码域尢法识别时,就会叵对端发 送一个LCP的代码拒绝报文(Code- Re jec报文) 域包括如下类型: 分区新分区的第页 标识域 Indentifier:一个字节,其目的是用来匹配请求和响应报文一般而言在进入链建立阶段时,通信双方无论哪一端都会连续发送几个配置请求报文 Config- Request报文),而这几个请求报攵的数据域Data可能是完全一样的,而仅仅是它们的标识域不同罢了。通常一个配置清求授文的ID(标识 域 Indentif er)是从0x01开始逶步加1的,当对端接收到该配置请求报文后,无论使用何种报文(回应报文可能是 Con ig-Ack、 Config-Nak和 Config- Reject 种报文中的一种)欢回应对方,妄求回应报文中的ID要与接收报文中的1D一致,当通信设备收到回应後就可以将该回应1D与发送时I的进行比较来决定下 步的操作 长度域 Length:两个字节长,表示总字节数(代码域+标志域±长度域艹数据域)。长度域所指礻了节数之外的了节将被当作填允节而忽略掉,而且该 域的内容不能超过MRL的值 数据域Data:内容根据不同的LCP数据报文的内容也是不一样的 LCP报文详解 下面说一下LCP包括的几种报文类型,不同的报文在标识域中所填充的内容也不同。 LCP报文主要分为 1、链路氈置报文 主要用来建立和配置一条链蕗 2、链路终止报文, 主要用来终止一条链路 3、雏路缝护报文,主要用来护和调试链路 链路配置报文 链路配置报文主要用来建立和配置一条链蕗,包括: Config- Request, Config-Ack, Config-Nak和 Config- Reject四种报文。 链路配报文与其它两类报文有着明显的区别,它主要是用来协链路的配置参数选项的,因此这神报文的数据域还要槜带许哆配置参数选项的,而另 外两类报文中部分报文的格式会稍有不同(请参见RFC1661),下图表明了数据配置选项的报文格式: 代码域标识域长度战数据域 类型域长度域数据域 类型域l字节长;长度域1字节,表示当前LCP配置选项的总长度(类型域+长度域+数据域)ε Rcqucst报文时,会在剩下的三种类型的报文中选择一種米响应对方的请求报文,到底选择哪种报文来响应对方需依据以下两个条 分区新分区的第页 件 A、能不能完全识别配置参数选项的类型域峩们知道一个 Config- Request报文中会同时携带多个配置参数选项,而对于一个支持PPb议的通信设备也不 定会支持上表中所有列出的配置选项,即使支持,乜可能茬实际应用中关刁揮某些选项功能。(例如:当使用PPP协汉通信的一端可能将一些无用的配置选项 都关闭了,而仅支持0x01和0x03两个型置参数选项,因此当對方发送的 Config request报文中含有0x04配置选项时,对于本端而言这个配置参数选功就木法识 别,也即是不支持这个配置参数选项的协商) B、如果能支寺完全識別配置参数选项,能不能认可( onfig- Request报文中配置参数选項效琙中的内窣(例如:当一端发送魔术字配置参数选项中的魔术字 为全0,而对端认为应该为其咜值,这种情况就属于不支持配置参数选项中的内容)。 所以依据上面的两个条件,我们就可以明确在回应对方配置请求报文时,采用何种报文回應 A、当接收(nfig-Reqμest报文的端能识別笈迳过来的所有配置参数选项且认可所有配置参数选项数据域的内容时,接收端将会給对端叫个 Config-Ack报 文,并将配置請求报文中的配置参数选呗原封不动的放置在Cωnig-Δωk报文的数据域内(根据协议旳规定是不可改变配置参数选項的顺序)当配置请求报文 的發送端收到 Contig-Ack报后,则会从当前阶段进入到下一个阶段。 假设点对点通信的一端发送了一个 Conf-g- l报文,报文内容如下: TEPF03C 3067E 下面结合LCP报文格式说明报文的具體内容 注意:说明中省略了FCS字段(后面的说明也是如此)。 7EFF0各C0 Config- Request报文 标识坛通常从 PPP数据域(本例中 字符转义字符0x17和0x19将被转 义。在同步链申,采用比特填充防止 01开始 是LCP包)总长度长伪标志码,另外,P链洛的控制字符 度23字 没有意义,因此不转义这一参 数的协商漫有必要 7E FF 03 c021 信息数据cRc(2B)7E 代码域标识域长喥域数据域 LCP报文格式 类型域长度域数据域 (PPP协议域为C021) 上图02表示LCP配置选项0x02,字符转义。 分区新分区的第页 7EFF0C02l000A000 CBD03067E 魔术字 协议螵压缩,表示PPP的协议域可以破 哋址和控制城缩,多链路捆绑 压縮成个子节,如PPP报文承载的是 LcP报文其亢整的 P协误数据(0021),可以破压缩为21 PPP头为FF03c021, 以节约带宽,但现在大多为高速链路 在进荇压缩后,变 这一参数的协商也漫什么必要 为c021 7EFF03c021 信息/数据cRc(2B)7E 代码域标识域长度域数据域 类型域长度域数据域 上图05表示LCP配置选项表中的0x05,魔术字以此类推,蓝色部分都表示LCP配置选项表中类型值。 当对端正确接收到了该报文后,应该发送个 Corfig-Ack报文,报文内容如下: 7EFF03C0 cB Q20802[D 03067E 唯一改变的内容就是代码 域(02表示昰 Config Ack报文 B、当接收 onfig- Request报文的端能识别发送端A所发荙过来的所有配置参数选项,但对部分配置参薮选項数据域中的为容不认可时,接收端B将会给对端 A叵应一个 Config-Na报文(注意,是能够识别,只是对部分参数内容不认可,所以不是 Config- Re ject报文)该报文中只携带不认可的配置参数选项,而 这些配置参数选项的数據内容为本端希望的值。然后,当A收到 Config Nak报文后,会重新发送 Con=ig Request报文,而这个 Config Request报文与上一次所 发送的 Config- 该数据报文中有下划线的配置参数选项的内容为對端不认可的 当对端B正确妾收到了该报文后,发现类型域为0x02的忾置参薮选項可识別,但诿配置参教选项数据域的内容不认可,应发送个Cπnfig-Nak报文苴该报文中 将携带希望的配置参数选项内容,报文内容如下: Request报文的一端B不能识别所有的发送端A发送过来的配置参数选项时,此时接收端B将会向對端A回一个 Config- Reject报文, 该报文中的数据域只携带那些不能识别的配置参数选项。当对端A接收到 Config- Reject报文后,同样会再次发送一个 Config- Request报文,这个配置 请求报文與上一次发送的区别在于将不可识别的那些配置参数选项给删除了 对于PP的两个端点而言,两者是独立完成各自的配置参数选项的协商过程的 鏈路终止报文 Terminate- Reply报文,同时等待对端Δ先将链路断开后,再完成本端的所有断开的操作 lP的链路终止报文的数淢与链路配置报文汋数据域不样,链蕗终止报文中无霱携带各配置参数选项。对于链路终止报文也同样需要I致,当接收到 Terminate- Reply报文才会做链路终止操作 链路维扩报文 除上述两种报文類型以外,剩余的所有报文类型均归属链路维护报文 (1)当接收端发现LC报文的代码域code是一个不合法的值时,将会向发送端回应一个Code- Reject报文,在回应报文巾会将所拒绝报文的全部内容附加上 (注:code只有在LCP协义头中才存在) 2)当接收端发现所接收到的PP数据呗的协议域 Protocol是一个不合法的值时,将会向发送端囙应一个 Protocol-Rcct报文,发送端收到该拒绝报文后将 停止发送该种协议类型的数据报文了(注: Protocol只有在PP协议头中才存在) Protocol- Re ject报文只能在LCP的状态机处于 Opened状态时小鈳被处担,而在其它状态接收到该报文将被丢弃在 Protocol- Reject报文的数据域内将携带所 拒绝报文的协议类型和报文内容。 (3)Echo- Request报文和Echo- Reply报文主婓来检测双向鏈路上自环的问题,除此之外还可附带做一些链路质量的测试和其它功能当LCP状态机处于 Opened状态时,如果接收到了Echo- Recues t,就需向对端叵送一个Echo- Reply报文。否則在其它LCP状态下,该类型的报义会被丢究 这种类型数据报文的长度域后不是直接跟数据域,而是要插入4个字节的 Magic- Number(魔术字),该魔术宇是在CF的onfg- Request.的配置參数选项协商 时获得的 魔术字 最后说一下魔术字的含义,这是在链路建立过程中比较重要的一个参数,这个参数是在 Config- Request里面被协商的,主要的作鼡是防止环路,如果在双方 不协商魔术字的情况下,某些LCP的数据报文需要仅用魔术宁时,那么只能是将魔术了的内容填允为全0;反之,则填允为配置參数选项协商后的结果。 分区新分区的第页 魔术宇在目前所有的设备当中都是需要进行协商的,它被放在 Config- Request的配置选項参数中进行发送,而且需偠由自身的通信设备独立产生,协汉为了謹 免双方可能产生同样的魔术字,从而导致通信出现不必要的麻烦,因此要求由设备采用一些随机方法產生一个独一无二的魔术字一般来说魔术字的选择会采 用设备的系列号、网络硬件地址或时钟。双方产生相同魘术字的可能怛不能说是沒有的,但应尽量避免,通常这种情况是发产在相同厂商的设备进行连时 因为一个厂商所生产的设备产生魔术字的方法是一样的 我们知道魔術了产生的作用是用来帮助检测链路是昋冇在环路,当按收端B收到一个 Config- Request报文时,会将此报文与上一次所接收到(应该是上一次发 送出〕的 Config- Req lest诖行匕綬,如果两个报文口所含的魇术宇不致的诟,表明链路不存在环路。但如果致的话,接收端B认为链路可能存在环路,但 不一定存在环路,还需进一步確认此时接收端B将发送一个 Config-Nak报文,并在该报文中携带一个重新产生的魔术字,而且此时在未接收到任何 Config Request或 Config-Nak报文之前,接收端B也不会发送任何的 Config- Request報文。这时我们假没可能会有以下两种情况发生 1.链路实际不存在环路,而是由于对方A在产生魔术字时与接收端B产生的一改,但实际这种情况出現的概率是很小的当 Config-Nak被对端A接收到后,A应该 发送一个 Config- Request报文(此报文中的魔术字为接收到的Nak报文中的),当B接收到后,与上次的 Config- Request比较,由于接收端B已经茬上一次的Nak 报文中产生了个不同的魔术字,此时接收端B收到的( onfig- Request报文中的魔术宇与上次B发出旳( onfig- Request配置请求报文中不样,所以接收端B可 断定链路不存茬环路。 2.链崆实际上确实仔在抔路,一段时间后 Config-Nak报文会返回到发送该报文的同一端B这时接收端B比较这个 Config-Nak报文与上一次发出去的 Config-Nak 报文一样,因此链路存在环路的可能性又增大了。我们知道当一端收到了一个 Config-Nak报文时,又会发送一个 Config- Request报文(该报文中的魔术字与 Config-Nak中的一致),这样又回到了最初嘚状态,在这条链路上就会不断的出现 Config- Request、 Config-Nak报文,因北这样局而复始下去,接收端就会 认知P链仔在环路的可能性在不断增加,当达到一定数量缴时,就鈳认为此链嵱仔在坏路(江意,不是第一次受到相冋的魇术字就判断有环路的) 但在实际应用中根据不同设备实现PP协议的方法,我们在链路环路檢测时可采用两科方法。第一种机制就是如上面所述的,这个过程不断地重复,最终可能 会给LCP状态叽发一个υo事件,这时可能会使CP的状态机又回箌初始化阶段,又开始新一轮的协商当然刈于某些设备还会采用第二和机制,就是不产生任 何事件去影响当前lC°的状态机,而是停留在请求发送状态。但这时认为链路有环路的端设备需要不断的向链路上发送Fchm- Request报文来检测链路环路是 否被解除,当接收端孜到Echo-eply报文时,就认为链路环路被解除,从而就可能进行后续的PP凶过程 好了,基本上通过篇PP困谈,我们可以比较彻底的∫解PP协议的工作机制和特点,其实,会者不难,协议都是人制订的,只囿简单易用的协议才会最终保 留下来,就像TCP/IP打败0sI一样。所以,只要静下心来,没有什么高深的可能这3篇文章里面有部分个人理解错误的地方,希朢大家可以多提意见,大家共 同进步 协议 协议的数据报文是在网络阶段被交换的,在这个阶段所需的一些配置参数选项协商完后,就可以进行网絡层的通信,也即是在点对点的链路上可以开始 传送网络层的数据报文了 协议主要包括 等,但我们在实际当中最常遇见的也只有协议了,如果对戓其它的一些网络控制协议有兴趣,则可参见 下面我们主要介绍 控制协议 控制协议主要是负责完成网络层协议通信所需配置参教的选项协商,負责建立,使能和中止P模块。在运行的过程当中,主要是完成点对点通信 设备的两端动态的协商地址lPCP包在PPP没有达到网终层协议阶段以前不能進行交捩,如果有PCP包在到达此阶段前到达会被拋弃。 协议格式 代码域标识域长度域数据域 类型域长度域数据域 代码域1字节长,标识域1字节长,长喥域2字节长 分区新分区的第页 类型域l字节长;长度域1字节,表示当前LCP配置选项的总长度(类型域+长度域+数据域) 的数据的报文同的数据报文非常類似,不同之处有两点: 是在网络层协议阶段协商配置参数选项,字段为而协议则是在链路建立阶段协商配置参数选项的,字段为 代码域字段。其包括十几种报文,而只包括种报文,但它的报文类型只是数据报文的一个子集(只有代码蜮从到这七种报文: ),而且实际的数据报文交换过程中 该使鼡|P地址配置0x03如果接收到的配置请求中包括P地址或P地址选项,此选项不应该在配置请求中包括这个选项。只有因为IP地址 选项而收到配置拒绝時,或接收到的配置未确认中包括P地址选项作为附加选项时,才发送这一选项 IP- Compression- Protocol0x02,用来提供协商使用指定的压缩协议,默认不使用压缩选项。选项嘚格式如下 类型(1字节川长度(1字节川P压缩协议(2字节) 数据 2 24 要使用的压缩协议 根据协议指定的内容 P压缩协议域指明要使用的压缩协议,协议编号與PP协议域中的协议编号相同。 目前支持的协议有 Van Jacobson Compressed TCP/IP[29],编号为002D(16进制) P- Address0x03,P地址配置。P- Address用来协商本地使用的P地址该选项允许请求发送者提供自己的P地址(静态)或请求对方给 自己分配P地址(动态),在后一种情况下,请求者发送一个全为0的P地址,对方在一个NAK数据帧中给出请求者的P地址。 我们依据两端設备的配置选项可将lPCP的协商过程分为: 静态”和“动态” 我们在下面会具体描述这两个过程。 以下就具体介绍一下控制协议的静态和动态嘚两个过程,实际上两者的区分是在于互连设备地址的获取过程 静态协商 静态协商,也即是不协商。点对点的通信设刍两端在协商之前已配置好了地址,所以就无须在网络层协议阶段协商地址,而双方唯一要做的就是告诉 对方自身的地址 在控制协议完成整个配詈的过程时,最理想嘚情况将会看到前述的四种报文,而无其它报文再被发送。 如果当配置请求中所携带的网络层配置参数选项类似于配置参数选项协商过程一樣,可能会有对方不识别的配置参数选项或不被对方所认可的配置参数选 项的内容 这样在这个阶段的协商过程中可能还会看到其它的一些報文 在静态协商时,如果的 报文中只含有地址配置参数选项时(实际中可能还会附带其它配置参数选项,这些配置参数选项的协商与阶 段的一样,洏我们这里只提到了地址配置参数选项),无论是发送方还是接收方都同时发送 报文,其中配置选项中只含有各自的地址 当对端收到该报文后,会發送一个 报文;这个目的是告诉对端我已经知道了你的地址,对路由器而言会增加一条到对端接口的主机路由 分区新分区的第页 刚进入网络层協议阶段时 的状态机是的,但当完成了上述的整个过程后,的状态机改变为 双方也就可以开始网络层数据网的传送 协议中并未规定点对点两端嘚地址必须在同一网殿。当一端接收到 报文后,它从报文的配置参数选项中可获知对端的地址,但并不 与本端的地址进行比较我们也知道,一般而言点对点的两端应该是在一个网段。但如果双方的地址不在一个网段,也无条件向对方回应 报文 因此说点对点通信的两端如果是手动設置每一端的地址时,无须双方地址在同一网段 例 假设在网络层协议阶段开始协商配詈参数选项(这里只举协商地址的配音参数选项地的过程),發送方设詈地址为 接收方设置 地址为 发送方发送 报文内容如下 7EFF0A017E 在这个例子中我们能看见明显的改变之处在于协议域字段由原先的 ()改变为 (中嘚),下划线的部分表示本端的地址 当对端正确接收到了该报文后,应该回应一个 报文,报文内容如下 7EPPA80001|E 同样的接收方给发送方也发送一个 Config- Request报文内容洳下,但此时报文中P地址配置参数选项的值为本端的P地址() 7EFF0A02|7E 发送方回应一个 Config-Ack报文给接收方,报文内容如下: 7EFO860007E 动态协商 动态协商是端配置为动态获取IP哋址,另·端通过手动方式配置Ⅳ地址,且允许给对端分配T地址。 这个过程实际上可与窄带拨号上网的过程相一致,如果我们想用计算机上网,均会咹装一个拨号适配器,而且计算机中的拨号网络适配器是采用动态获取IP地 址的方式 这个例子与上一个例子相似,也就是在IPCP的 Config- Request报文中只携带IP地址的配置参数选项。如果是配置参数选项中含有其它配置参数选项,则可能会 遇刭其它旳一些情况(如不识别配置参数选项的代码域或不认可配置参数选项的内容,但对于这些情况的处理方法和LCP配置参数选项的处理方法一致) 左这种情况下,发送方连续发送了两次 Config- Request报文,才能完成发送方的协商过程。而接收方仍然只需要发送一次 Config- Request即可完成本端的协 商过程 由于发送方没有置I地址(而是动态获取I地址),所以在IPCP的 Config Request报文的1地址配參数配置选项中的IP址址填充全0(也即是0.0.0.0) 当接收方收到该配置请求报文后会检测P地址的内容,如果发送为全0,则认为对端的这个IP地址不是我所希塑嘚值,这样就回应一个 Config-Nak报文,并将 希望分配给对方的IP地址填充到 Config-Nak报文内。这时当接收方收到 Config-Nak报义后,就会重新发送一个 Conf:g- Request报文,这个报文中的IP地址配 置选项为对方在Nak报文中所提供的 接收方IP地址的配置过程与静态时的一样,只需发送一个 Config-Request报文即可,当收到发送方的 Config-Ack报文,就表示接方的IP地址配置唍成 例 假设IG在网络层协议阶段开始协商配置参数选项(这里只举协宦地址的配置参数选项地的过程),发送方没冇配置IP地址,而接收方配置了IP地址为 192.168.0.2,接收方可给发送方分配IP地址(192.168.0.1),发送方发送给接牧方的 Config- Reques报文内容如下 7EFF0A7E 有下划线的部分表示本端的P地址。当接收方端正确接收到了该报文后,應该回应一个 Config-Nak报文,报文内容如下 分区新分区的第页

PPP（Point- to-Point Protocol点到点协议）是为在同等单元の间传输数据包这样的简单链路设计的链路层 协议这种链路提供全双工操作，并按照顺序传递数据包设计目的主要是用来通 过拨号或專线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案

1. LCP协商，协商内容包 括除1661中所萣义的选项之外还要考虑OA和OE中规定的内容。
2. LCP协商过 后就到了Establish阶段开始PAP或CHAP认证。PAP为两次握手认证口令为明文。PAP认证过程如下：发送ppp用戶名是什么同口令到认证方认证方 查看是否有此用户，口令是否正确然后发送相应的响应。CHAP为三次握手认证口令为密文（密钥）CHAP认證由认证方发送一些随机产生的报文，交给被 认证被认证方用自己的口令字用MD5算法进行加密，传回密文认证方用自己保存的口令字及隨机报文用MD5算法加密，比较二者的密文根据比较结果返回 响应的响应。
3. 认证成功即进 行Network阶段协商（NCP）在IP接入中主要是IPCP协商（如IP地址和哋址的协商等）。任何阶段的协商失败都将导致链路的拆除
4. 协商成功，则 链路建立成功可以开始传输网络层数据报文。

pppd是一个后台服務进程(daemon)是一个用户空间的进程，所 以把策略性的内容从内核的PPP协议处理模块移到pppd中是很自然的事了pppd实现了所有鉴权、压缩/解压和加密/解密等扩展功能的控制协议。

pppd是一个普通的用户进程pppd 与内核中的PPP协议处理模块之间采用最传统的内核空间与用户空间之间通信方式：设備文件;设备文件名是/dev /ppp。通过read系统调用pppd可以读取PPP协议处理模块的数据包，当然PPP协议处理模块只会把应该由pppd处理的数据包发给 pppd。通过write系统調用pppd可以把要发送的数据包传递给PPP协议处理模块。通过ioctrl系统调用pppd可以设置PPP协议的参 数，可以建立/关闭连接

在pppd里，每种协议实现 都在獨立的C文件中它们通常要实现protent接口，该接口主要用于处理数据包和fsm_callbacks接口，该接口主要用于状态机的状态切 换数据包的接收是由main.c: get_input统一處理的，然后根据协议类型分发到具体的协议实现上而数据包的发送则是协议实现者根据需要调用output函数完成的。

chat是pppd所带一个辅助工具 chat鼡来与GSM模组建立会话。它的实现比较简单它向串口发送AT命令，建立与GSM模组的会话以便让PPP协议可以在串口上传输数据包。

当应用程序发送数据时内核根据IP地址和路由表，找到ppp网络接口然后调用ppp_start_xmit函数，此时控制就转移到PPP协议处理模块了 ppp_start_xmit调用函数ppp_xmit_process去发送队列中的所有数據包，ppp_xmit_process又调用

1.用 户数据发送过程如下所示：

2.pppd的控制协议数据发送过程：

在ppp_input函数中数据被分成两路，一路是控制协议数据包放入pch->file.rqb队列，茭给pppd处