第一次在逻辑分析仪上盯着那一串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、地址字段、控制字段、信息字段（可选）、帧校验序列 FCS（16 位或 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, init=0xFFFF, poly=0x1021) -> 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是 LCP，0x8021是 IPCP，0x0021是 IPv4，0x0057是 IPv6，0xC023是 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号是主 DNS，131号是次 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 接对方 TX，TX 接对方 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表示 LCP，01是配置请求，01是标识符，00 0A是长度 10 字节，05 06 00 00 05 DC是选项——选项类型05是 Magic Number，长度06表示这个选项共 6 字节，后面 4 字节是随机数0x000005DC。最后两字节是 FCS。

对端如果同意，回的帧里代码是02（配置确认），标识符与请求一致，内容原样带回。如果对端不接受 MRU 之类的参数，会看到代码03（配置否认）并附带建议值。抓包时按标识符把请求和响应配对，就能清楚看到每一轮协商在谈什么、卡在哪个选项上。

实操中我建议准备一张"协议字段速查表"，随时对照：

4.3 IPCP协商与数据面验证

LCP 进入 Opened 之后，如果没配认证，就直接进 IPCP。IPCP 的流程和 LCP 几乎一样，只是选项不同。发起方通常先发一个 IP 地址为0.0.0.0的配置请求，表示"请你告诉我该用什么地址"；对端回配置否认，附带一个建议地址；发起方拿着新地址重新请求，直到确认。

协商完成后，用ip addr查看链路接口，应该能看到分配到的地址和点对点对端地址。这时候最直接的验证是互相 ping 一下。如果 ping 不通但接口状态是 UP，优先查三件事：路由表里有没有到对端的路由（点对点接口通常会自动加一条主机路由）、MTU 是否一致、防火墙有没有拦。

这里有个经验：点对点链路上的 MTU 默认是 1500，但串口链路的实际可靠传输能力受 MRU 和线路质量影响。如果业务数据大于协商的 MRU，PPP 会做分片，但分片会增加出错概率。在低速串口上，我一般会把 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[i+j] << 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 一份可以直接照着走的排查速查表

注意：排查时一次只改一个变量。我见过有人同时换线、改波特率、改配置，链路好了也不知道是哪一项起的作用，下次再出问题还是抓瞎。把改动记录在本子上，是现场工程师的基本功。

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 层甚至一根地线上。把抓包工具用好，把状态日志打全，把参数表备在手边，剩下的就是耐心地一层一层往下剥。