第一次在逻辑分析仪上盯着那一串0x7E反复出现的时候我才真正意识到很多现场问题根本不是配置错了而是对数据链路层的帧结构理解不到位。事情起因很简单一位做工业网关的朋友设备串口接上一台老式路由器链路死活起不来日志里只有干巴巴的几行LCP timeout。他一开始怀疑是线序接反、波特率不匹配换线、换板、降速折腾了两天。最后把抓到的数据拉出来一看问题出在帧里——对面发来的 PPP 帧地址字段是固定0xFF他那边按 HDLC 标准实现了地址寻址直接把帧当成不是发给我的丢掉了。这就是 HDLC 和 PPP 这对老搭档最典型的坑它们长得像血统也有渊源但行为细节差得不少。HDLC 是面向比特的通用数据链路层协议强调的是帧定界、透明传输、差错检测和流量控制这一整套机制PPP 则是从 HDLC 的无编号信息帧形态演化出来、专门服务于点对点链路的协议族除了帧封装还额外背了一整套链路协商、身份认证、网络层参数配置的流程。你会在串口专线、工业现场总线、宽带拨号接入、路由器广域网口、某些嵌入式设备的调试口上反复遇到它们。这篇文章写给三类人看一是刚接触底层通信、被帧结构和状态机绕晕的初学者二是现场调试时只能靠日志猜问题的工程师三是需要在自研设备里实现一套轻量点对点链路协议的开发者。我会从帧结构讲到协商流程再落到可以照着做的抓包与解析步骤最后把几个反反复复踩过的坑摊开讲清楚。1. 先搞清楚HDLC和PPP到底在解决什么问题1.1 从两个设备之间怎么说话这个原始需求说起数据链路层要干的事情说白了就三件把上层交下来的数据切成一帧一帧、保证帧边界能被对方准确识别、在传输出错时能发现并且丢掉坏帧。听起来简单但真做起来麻烦全在边界两个字上。假设你在一条串口线上连续发送两个字节0x7E 0x01和0x7E 0x02接收方怎么知道第一个0x7E是帧开始标志而不是数据的一部分如果把数据里天然存在的0x7E当成标志处理帧就被截断了如果一律不当标志又没法定界。HDLC 给出的答案是用一个特殊的比特序列01111110作为帧标志同时在发送端做比特填充——只要数据里出现连续五个1就强行插入一个0接收端再按相反规则删掉。这样数据区里永远不会出现和标志位相同的比特模式定界问题就解决了。这个思路直接影响后面所有实现细节。比如你在写驱动时如果只按字节处理而不做比特级填充/去填充遇到特定数据模式就会莫名其妙丢帧而且这种问题往往只在传输特定内容时才复现排查起来极其折磨人。我曾经见过一个团队因为填充逻辑写在中断里、临界区没保护好导致高波特率下偶尔少删一个0整帧 CRC 校验失败最后是靠长时间压测加计数器统计才定位到的。HDLC 的另一个设计取向是通用。它的地址字段可以扩展成多字节控制字段区分信息帧、监控帧、无编号帧支持连续发送多个帧而不等确认滑动窗口也支持捎带确认。这套机制在早期低速、高误码的链路上非常有效代价是实现复杂度高。很多嵌入式场景其实用不到这么多功能于是就有了简化版本——PPP 就是其中影响最大的一个。1.2 为什么工程现场总看到它俩成对出现PPP 在设计时明确声明自己借用 HDLC 的帧格式具体做法是固定地址字段为0xFF、控制字段为0x03也就是 HDLC 里的无编号信息帧命令。这么一来PPP 既继承了 HDLC 成熟的帧定界和 FCS 校验机制又抛掉了地址寻址和滑动窗口这些在点对点链路上没意义的东西腾出位置塞进了自己的协商协议。所以你在抓包时看到的 PPP 帧本质上就是一个被裁剪过的 HDLC 帧标志、地址、控制、协议类型、信息、校验、标志。区别在于 HDLC 的控制字段位置在 PPP 里变成了协议字段用来标识上层载荷是 LCP、IPCP、IPv4 还是 IPv6。这个字段位置的重叠是很多初学者看协议文档时最容易懵的地方——同样两个字节在 HDLC 里是控制信息在 PPP 里是协议号。工程上为什么两者总是同时出现因为分工不同。设备厂商在做私有串口链路时往往直接拿 HDLC 的帧格式当基础因为简单、开销小、不需要协商而在需要承载 IP、需要动态分配地址、需要身份校验的场合PPP 就是标准答案。你去看路由器广域网口的配置串口封装类型里 HDLC 和 PPP 通常是并排的两个选项选哪个取决于对端设备支持什么、是否需要认证。这个选择在后面第 6 节会展开讲。2. HDLC帧结构逐字节拆解2.1 标志字节与透明传输比特填充的真相一个标准 HDLC 帧从前往后依次是标志0x7E、地址字段、控制字段、信息字段可选、帧校验序列 FCS16 位或 32 位、结束标志0x7E。注意首尾标志可以是同一个——连续发送多帧时前一帧的结束标志同时充当后一帧的开始标志这在带宽紧张的低速链路上是实打实的节省。真正需要掰开讲的是比特填充。规则很明确发送端在地址、控制、信息、FCS 这几个字段的比特流里只要检测到连续五个1立刻插入一个0接收端在去填充时检测到连续五个1后面跟一个0就把这个0删掉。这样做的直接结果是标志序列01111110六个连续1夹两个0在填充后的数据流里不可能自然出现。这里有个容易被忽略的细节FCS 字段本身也要参与填充。也就是说校验值算完之后还得把校验值一起做比特填充再发出去。我见过有实现是先填充数据、再算 CRC、然后把 CRC 原样附在后面不做填充结果就是某些校验值里恰好含连续六个1接收端把它当成了帧标志整帧提前截断报 CRC 错误。这种 bug 的隐蔽性在于它跟数据内容强相关同样的代码跑不同的业务数据可能几万帧才出一次。还有一个实操陷阱接收端去填充时如果遇到连续七个及以上的1按照标准应该视为异常终止abort直接丢弃当前帧并回到搜索标志的状态。但有些简化实现只处理了五连一后删零对七连一没有特殊判断结果就是链路受干扰时错误帧不会被及时清掉反而被拼进下一帧造成连锁错误。调试时如果看到错误计数暴涨但单帧内容看起来正常可以往这个方向查。2.2 地址与控制字段不只是填个值地址字段在标准 HDLC 里是 8 位起步最低位是扩展位为0表示后面还有地址字节为1表示这是最后一个地址字节。所以在点对点场景里地址字段通常就是一个字节0x01或0x03最低位为1表示地址到此结束。命令帧和响应帧的地址方向是有约定的主站发给从站用从站地址从站回给主站用主站地址或者从站自己的地址具体看实现约定。控制字段才是 HDLC 的灵魂。它用最低两位注意是低位区分帧类型最低位为0是信息帧 I 帧格式是0加发送序号 N(S) 加轮询位 P/F 加接收序号 N(R)最低两位为01是监控帧 S 帧用来做确认、请求重传、请求暂停最低两位为11是无编号帧 U 帧用来建链、断链、报告异常。序号通常是 3 位模 8 循环也有扩展成 7 位模 128 的版本。滑动窗口带来的好处是吞吐量。在一条误码率不低、往返时延又不小的链路上如果每发一帧就停下来等确认效率会低得可怕。HDLC 允许连续发若干帧接收方用 N(R) 一次性确认。但这也意味着发送端必须维护发送缓冲区和重传队列实现复杂度立马上去了。很多自研的轻量协议干脆放弃窗口退化成发一帧等一帧在低速场景下反而更稳。注意如果你在做自研设备对接标准 HDLC 设备控制字段的位序千万不要想当然。有些文档写的是最高位在前但实际在线上传输时是低比特先发实现里如果按常规的字节位序去解析得到的帧类型判断会完全错位。建议先用一串已知的建链帧做对拍验证。2.3 FCS校验算错一位就整帧丢弃HDLC 的 FCS 默认用 16 位 CRC生成多项式是x^16 x^12 x^5 1也就是常说的 CRC-CCITT多项式值0x1021初始值通常取全1最后结果取反后按低位在前、高位在后的顺序发送。32 位版本用的是另一个多项式用于对误码更敏感的高速链路。CRC 校验本身不难难在两端约定必须完全一致多项式、初始值、是否取反、字节内比特顺序、字节间发送顺序任何一项对不上算出来的值就永远不匹配。这类问题在现场表现为帧结构看起来完全正确、长度也对但接收端就是报 CRC 错。我的习惯是接手一个新链路时先拿一个已知内容的短帧手工算一遍把计算结果和抓包里的 FCS 字节逐位对比确认算法参数对上了再往下做业务。下面这段 Python 代码是我常用的 CRC-CCITT 计算和 HDLC 帧解析工具现场排查时直接改改就能用def crc16_ccitt(data: bytes, init0xFFFF, poly0x1021) - int: crc init for b in data: crc ^ (b 8) for _ in range(8): if crc 0x8000: crc ((crc 1) ^ poly) 0xFFFF else: crc (crc 1) 0xFFFF return crc def hdlc_parse(frame: bytes): # frame 应包含首尾 0x7E且已完成比特去填充 if len(frame) 6 or frame[0] ! 0x7E or frame[-1] ! 0x7E: return None body frame[1:-1] if len(body) 4: return None addr, ctrl body[0], body[1] payload, fcs_rx body[2:-2], body[-2:] fcs_calc crc16_ccitt(body[:-2]) fcs_rx_val fcs_rx[0] | (fcs_rx[1] 8) return { addr: addr, ctrl: ctrl, payload: payload, fcs_ok: (fcs_calc ^ 0xFFFF) fcs_rx_val, }这段代码里有两个容易出错的地方值得强调。第一CRC 的最终结果要不要取反不同实现不一样标准 HDLC 是发送前对 CRC 寄存器取反代码里我用fcs_calc ^ 0xFFFF做了对应第二FCS 在线上的字节顺序是低字节在前所以拼回数值时要先取fcs_rx[0]再左移。这两点只要错一个fcs_ok就永远是 False很多人在这一步卡住后开始怀疑线路其实是算法参数问题。3. PPP到底在HDLC上加了什么3.1 固定头部与Protocol字段多出来的两字节信息量PPP 帧的固定结构是标志0x7E、地址0xFF、控制0x03、协议字段两字节、信息字段、FCS 两字节、标志0x7E。地址和控制是写死的FF 03这个组合在抓包里几乎是 PPP 的标志性特征看到它就基本能确定是 PPP 而不是其他串口协议。协议字段是关键。它标识信息字段里装的是什么0xC021是 LCP0x8021是 IPCP0x0021是 IPv40x0057是 IPv60xC023是 PAP 认证0xC223是 CHAP 认证。这个字段最低位为1表示这是网络层协议为0表示是链路控制协议用于区分控制面和数据面。抓包时优先看这个字段一眼就能知道当前链路处于协商阶段还是已经可以传业务数据。另外 PPP 有一个可选的地址控制字段压缩选项协商成功后可以把固定的FF 03省掉每帧节省两个字节。在低速链路上这个优化有意义但会让人看抓包时突然发现帧头少了东西第一次遇到容易懵。协议字段压缩同理能把两字节压成一字节。3.2 LCP协商链路能不能起来全靠它LCP 是 PPP 链路控制协议负责在最开始把两端的链路参数谈拢。它的报文结构是代码一字节、标识符一字节、长度两字节、若干选项。代码取值里1到4分别是配置请求、配置确认、配置否认、配置拒绝5和6是终止请求和终止确认9和10是回声请求和回声应答。协商过程是这样的一端发出 Configure-Request里面列着自己希望对方接受或自己愿意接受的选项对方如果全部同意回 Configure-Ack如果有不认识的选项回 Configure-Reject 并把不认识的选项列出来如果认识但值不接受回 Configure-Nak 并给出建议值。发起方根据回应调整参数重新发请求直到收到确认链路才进入 Opened 状态。常见选项包括最大接收单元 MRU默认 1500、认证协议、Magic Number用来检测链路环回、协议字段压缩、地址控制字段压缩。Magic Number 这个设计很巧妙两端各自生成一个随机数发给对方如果收到的 Magic Number 和自己发出去的一样说明链路自己绕回来了直接判定环回并断开。现场如果遇到链路刚起来几秒就断、反复重连可以优先怀疑这个。注意LCP 的标识符字段要求请求和对应的响应必须一致重传时标识符不变。有些实现对超时重传时重新生成标识符导致对端回的 Ack 匹配不上链路卡在 Req-Sent 状态出不来。调试这类问题时抓包看标识符是否一一对应比看代码快得多。3.3 认证与NCP从能通到能上网还差几步LCP 谈完之后如果协商里约定了认证就进入认证阶段。PAP 是明文两次握手简单但不安全CHAP 是三次握手的挑战应答用 MD5 之类的散列做校验安全性好一些。认证失败会导致链路直接关闭日志里通常是authentication failed。认证通过后进入网络层协议阶段最典型的是 IPCP用来协商 IP 地址、DNS 地址、IP 压缩等参数。IPCP 的报文格式和 LCP 一样只是选项不同3号选项是 IP 地址129号是主 DNS131号是次 DNS。两端通过 Configure-Request/Nak/Ack 把地址谈拢然后链路才算真正可用。整个状态机走下来大概是Initial → Starting → Req-Sent → Ack-Rcvd/Ack-Sent → Opened → 认证 → 网络层协商 → 数据转发。链路断开时倒着走回去。理解这个状态机对排查问题帮助极大因为每一类故障都会把链路卡在某个特定状态看到状态基本就锁定范围了。4. 实操串口上跑一条PPP链路并逐帧验证4.1 环境与参数准备最省事的实验环境是两台 Linux 主机用 USB 转串口对接或者一台主机用两个串口做自环不过自环跑 PPP 会被 Magic Number 检测出来需要关掉环回检测选项这一点后面细说。串口参数必须两端一致波特率先用 9600 稳妥起步数据位 8无校验1 位停止位硬件流控关掉。别一上来就上 115200低速下更容易观察出问题也更容易定位。物理连接上RX 接对方 TXTX 接对方 RX地线必须共地。这一步看着像废话但我见过太多次只接了两根信号线、地线悬空结果链路时通时不通还伴随大量 CRC 错误——共模电压漂移导致的误码接上地线立刻消失。配置串口可以用stty命令先确认参数stty -F /dev/ttyUSB0 9600 cs8 -cstopb -parenb -crtscts raw这里raw很重要它关掉了终端的行缓冲和特殊字符处理否则0x7E、0x11这类字节可能被终端层吞掉或改写你抓到的数据就不是链路上真实的数据了。我在第一次做串口抓包时就是因为忘了raw对着缺失的字节查了半天驱动。4.2 抓包与LCP握手解读启动 PPP 守护进程之后第一件事是把链路上原始字节抓下来。最简单的方式是用一个只读的旁路程序打开串口把收到的字节按十六进制打印同时不做任何应答——注意这种方式会抢数据只适合单向观察双向场景下还是用逻辑分析仪或者在协议栈上层打日志更稳妥。一个典型的 LCP 配置请求帧长这样十六进制已去填充7E FF 03 C0 21 01 01 00 0A 05 06 00 00 05 DC XX XX 7E拆开看7E标志FF 03地址控制C0 21表示 LCP01是配置请求01是标识符00 0A是长度 10 字节05 06 00 00 05 DC是选项——选项类型05是 Magic Number长度06表示这个选项共 6 字节后面 4 字节是随机数0x000005DC。最后两字节是 FCS。对端如果同意回的帧里代码是02配置确认标识符与请求一致内容原样带回。如果对端不接受 MRU 之类的参数会看到代码03配置否认并附带建议值。抓包时按标识符把请求和响应配对就能清楚看到每一轮协商在谈什么、卡在哪个选项上。实操中我建议准备一张协议字段速查表随时对照协议字段值含义阶段0xC021LCP 链路控制链路建立0xC023PAP 认证认证0xC223CHAP 认证认证0x8021IPCP 网络层配置网络层协商0x0021IPv4 数据数据转发0x0057IPv6 数据数据转发4.3 IPCP协商与数据面验证LCP 进入 Opened 之后如果没配认证就直接进 IPCP。IPCP 的流程和 LCP 几乎一样只是选项不同。发起方通常先发一个 IP 地址为0.0.0.0的配置请求表示请你告诉我该用什么地址对端回配置否认附带一个建议地址发起方拿着新地址重新请求直到确认。协商完成后用ip addr查看链路接口应该能看到分配到的地址和点对点对端地址。这时候最直接的验证是互相 ping 一下。如果 ping 不通但接口状态是 UP优先查三件事路由表里有没有到对端的路由点对点接口通常会自动加一条主机路由、MTU 是否一致、防火墙有没有拦。这里有个经验点对点链路上的 MTU 默认是 1500但串口链路的实际可靠传输能力受 MRU 和线路质量影响。如果业务数据大于协商的 MRUPPP 会做分片但分片会增加出错概率。在低速串口上我一般会把 MTU 主动降到 576 甚至更低宁可多几个包也别让单个包传输时间过长、被干扰打断。4.4 用脚本自动解析帧序列手工对着十六进制看几十帧还行上百帧就撑不住了。我的做法是写一个小脚本把抓到的字节流按标志位切帧、去填充、校验、翻译输出成表格。下面这段代码在上面的解析函数基础上增加了比特去填充和逐帧遍历def bit_destuff(raw: bytes) - bytes: bits [] ones 0 for byte in raw: for i in range(8): bit (byte i) 1 if ones 5 and bit 0: ones 0 continue bits.append(bit) ones ones 1 if bit else 0 out bytearray() for i in range(0, len(bits) - 7, 8): v 0 for j in range(8): v | bits[i j] j out.append(v) return bytes(out) def split_frames(stream: bytes): frames, cur [], bytearray() for b in stream: cur.append(b) if len(cur) 2 and b 0x7E and cur[-2] ! 0x7E: if len(cur) 3: frames.append(bytes(cur)) cur bytearray([0x7E]) return frames注意这里的比特序HDLC 在线路上是低比特先发所以取比特时要(byte i) 1重组时也要v | bits[ij] j。这个细节如果搞反去填充后的数据看起来就是一堆乱码但 CRC 又能过——因为两端都反了恰好自洽。这种情况最容易迷惑人直到要对接第三方设备时才暴露。5. 典型故障排查链路卡住时的分层定位法5.1 先看物理层和串口参数别急着怀疑协议链路起不来八成问题在下面两层。我的排查顺序是先确认电平标准和线序再确认波特率、数据位、校验、流控四项参数最后才看协议层。电平这块RS-232 和 RS-485 完全是两回事串口转换器接错不仅不通还可能损坏接口芯片。线序上 TX/RX 交叉接、地线共地这两条必须满足。参数不一致的典型表现是抓到的数据全是乱码而且乱得有规律——比如每个字节的比特被移位了。这种情况不用怀疑协议实现先把两端的波特率误差算一遍。晶振精度差的设备在 115200 下误差可能超过 3%勉强能通但误码率高。我一般建议先用 9600 验证逻辑再把速率往上提每提一档跑一段时间压测观察 CRC 错误计数。流控也是个坑。硬件流控 RTS/CTS 如果一端开一端关发送方可能在接收方缓冲满的时候继续狂发导致丢字节。软件流控 XON/XOFF 更危险因为0x11和0x13会被当成控制字符从数据流里剥离如果 PPP 数据里恰好出现这两个字节帧就被破坏了。所以在 PPP 链路上流控要么两端都关要么都用硬件流控绝对不要用软件流控。5.2 LCP阶段卡住的几种典型情况链路停在 LCP 不动日志里反复出现超时说明配置请求发出去没有响应或者响应了但匹配不上。先看物理层是否真的收到数据收到但不是 PPP 帧说明对端没跑 PPP 或者协议字段不对收到 PPP 帧但代码是04配置拒绝说明某个选项对端不认识需要把选项精简掉收到03配置否认说明参数不接受看它建议值改过来。还有一种隐蔽情况两端都在发配置请求都在等对方先回应结果互相发03否认陷入死循环。标准流程里其实有规定双方可以同时打开各自独立完成自己的协商看到对方请求就回确认不必看自己是否已经完成。如果实现里加了我还没谈完就先不理你的请求这类自作聪明的逻辑就会死锁。Magic Number 检测环回导致的反复断开也归在这一类。如果实验环境是自环必须把环回检测关掉否则 LCP 一进 Opened 就被判定为环回立刻断开。生产环境出现这个现象说明链路在某处被物理短接了要去查配线架和跳线。5.3 认证与MTU相关的坑认证阶段失败先确认用户名密码是否一致再看 PAP 还是 CHAP。PAP 是明文传的抓包能直接看到CHAP 的挑战值是随机数只能看认证结果码。常见错误是 CHAP 的散列算法两边不一致或者密码里含有特殊字符导致配置文件解析出错。MTU 和 MRU 的问题更隐蔽。如果一端的 MRU 协商成 1500另一端实际只能收 576大包过来就会被丢弃且不报错表现为小包能通、大包丢。排查方法是逐步 ping 不同大小的包找到临界值再回去看协商日志里 MRU 选项的值。这个思路和排查路径 MTU 问题是一样的只不过发生在链路层。5.4 一份可以直接照着走的排查速查表现象优先怀疑快速验证完全收不到任何字节线序、电平、串口未打开用回环短接头自测收发收到乱码波特率、数据位、时钟误差降速到 9600 重试收到数据但不是 PPP 帧对端未启 PPP、协议字段错看帧头是否 FF 03LCP 反复超时选项不兼容、标识符不匹配精简选项至只留 MRU链路起来几秒就断Magic Number 判定环回查物理链路是否短接卡在认证阶段凭据不一致、算法不匹配临时切 PAP 验证小包通大包不通MTU/MRU 不匹配逐步 ping 找临界值CRC 错误持续增长干扰、地线悬空、填充逻辑错换线、共地、单帧对拍注意排查时一次只改一个变量。我见过有人同时换线、改波特率、改配置链路好了也不知道是哪一项起的作用下次再出问题还是抓瞎。把改动记录在本子上是现场工程师的基本功。6. 一些踩过的坑和工程取舍6.1 什么时候用HDLC、什么时候用PPP判断标准其实很清晰链路两端是固定设备、参数预先约定、不需要动态分配地址和认证用 HDLC 就够了开销小、实现简单、启动快链路需要承载 IP、需要按需分配地址、需要身份校验、需要和标准设备互通那必须上 PPP。路由器广域网口封装类型选 HDLC 还是 PPP本质上就是这个取舍。有个容易被忽略的点是互通性。HDLC 虽然标准存在但各家在控制字段位序、地址约定、窗口大小上的实现差异不小跨厂商对接经常出问题PPP 因为协商机制的存在参数可以在运行时谈拢互通性反而更好。所以如果链路两端是不同厂商的设备优先选 PPP把不确定性交给协商流程解决。我自己的实践是内部自研设备之间、链路质量可控的场合用精简版 HDLC 帧格式去掉窗口和地址扩展只保留标志、控制、载荷、FCS代码量能压到几百行跑在单片机上也毫无压力。对外对接、走公共网络、需要认证的场合老老实实上 PPP别自己造轮子。6.2 现场调试的几个硬经验第一永远保留一份原始字节流的抓包。协议解析出问题的时候解析器的输出可能会误导你只有原始字节是真相。我习惯在调试口上挂一个只收不发的监听程序把原始流按二进制存盘事后可以反复回放分析。第二把状态机的状态打印出来。很多实现只在出错时打日志正常状态迁移不打导致链路卡住时你根本不知道它停在哪一步。加上状态迁移日志配上时间戳排查效率能提升一个数量级。第三低速链路不要迷信大 MTU。串口速率低意味着单帧传输时间长传输时间越长被干扰打断的概率越大。把 MTU 降下来让每帧尽快传完配合合理的重传整体吞吐反而可能更高。这个结论我在几条 9600 波特率的工业链路上反复验证过。第四注意 FCS 的字节序和比特序。这两个参数是看起来最简单、错起来最难查的典型。接手新链路时先用一帧已知数据把 CRC 对拍一遍确认参数再往下做。这一步花十分钟能省下后面两天的排查。第五自环测试要先关环回检测。这是个纯工程细节但每个第一次做自环实验的人都会被它坑一次。知道这条能少走一段弯路。这套东西说到底不复杂难的是把每个细节都对齐。帧定界靠比特填充透明传输靠标志唯一性差错检测靠 CRC 参数一致链路建立靠状态机严格按序推进。任何一个环节差一点表现出来都是链路不通但根因可能在第 2 层、第 1 层甚至一根地线上。把抓包工具用好把状态日志打全把参数表备在手边剩下的就是耐心地一层一层往下剥。