DLMS/COSEM 蓝皮书解读（三十二）：PPP setup（class_id = 44）—— 拨号链路上的 LCP/IPCP 协商与 PAP/CHAP/EAP 认证配置
系列说明：本系列基于 DLMS UA《Blue Book（蓝皮书）第 16 版 · 第 2 部分》，一个接口类一篇。第 31 篇讲了
MAC address setup（class_id = 43），它给出链路层身份（EUI-48）。本篇的PPP setup（class_id = 44）回答"在一条串行/拨号链路上，怎么用 PPP 协议协商出 IP"——LCP、IPCP、认证三件事。
上篇回顾：第 31 篇
MAC address setup存的是链路层地址；PPP 拨号场景里，这个地址之上还要跑 LCP（链路控制）、IPCP（IP 控制）、PAP/CHAP/EAP（认证）。本篇把这三组协商参数全部建模到一个 COSEM 对象里。
0. 为什么需要这个类 —— "猫 → 串口 → PPP 拨号 → 拿到 IP"这条链路怎么建模
很多电表不是直接插网线的，而是"猫（modem）→ 串口 → PPP 拨号 → 拿到 IP"。PPP（Point-to-Point Protocol）在这条链路上要完成两件事：
- LCP（Link Control Protocol）：跟对端协商链路参数（最大包长、是否压缩、是否认证、回拨……）。
- IPCP（IP Control Protocol）：协商网络层参数（本端/对端 IP、IP 压缩……）。
PPP setup就是把这一堆协商选项的"配置值"建模成一个 COSEM 对象。蓝皮书对版本有个说明：
蓝皮书原文（NOTE，开头）：
“Compared to earlier editions, this specification provides improvements in presenting the attributes. As this does not constitute technical changes, the version of the IC remains 0.”
即本版只是"把属性写得更清楚"，没有技术改动，版本仍是 0。
蓝皮书原文（Overview）：
“There shall be an instance of this IC for each network interface of a physical device.”
每接口一个实例，老规矩。
1. 类蓝图
1.1 属性表（version = 0）
| # | 属性名 | 读写 | 数据类型 | Short name | 说明 |
|---|---|---|---|---|---|
| 1 | logical_name | static | octet-string | x | 对象实例名（OBIS） |
| 2 | PHY_reference | static | octet-string | x + 0x08 | 指向底层物理层对象 |
| 3 | LCP_options | static | LCP_options_type | x + 0x10 | LCP 协商选项数组 |
| 4 | IPCP_options | static | IPCP_options_type | x + 0x18 | IPCP 协商选项数组 |
| 5 | PPP_authentication | static | PPP_auth_type | x + 0x20 | 认证参数 |
没有方法（Specific methods 栏为空）。
三个"选项"属性全是
static——PPP 是链路建立前就定好的，不是运行时变的。
2. 属性逐条拆解
2.1PHY_reference
蓝皮书原文：“References another object by its logical_name. The object referenced contains information about the specific physical layer interface, supporting the PPP layer.”
指向承载 PPP 的物理层对象（比如Modem configuration27、IEC HDLC setup23、或对应串口对象）。它和IPv4 setup的DL_reference是同一类"下层引用"思路。
2.2LCP_options：链路层协商
LCP_options_type ::= array LCP_options_type_element LCP_options_type_element ::= structure { LCP_Option_Type: unsigned, LCP_Option_Length: unsigned, LCP_Option_Data: CHOICE { structure [2] -- for Callback-data boolean [3] -- for ProtF-Compr and AdCtr-Compr double-long-unsigned[6] -- for ACCM and Mag-Num unsigned [17] -- for FCS-Alternatives long-unsigned [18] -- for MRU and Auth-Prot } }蓝皮书原文（NOTE 1）：“In all cases, as specified in IETF STD 51 / RFC 1661, the LCP_Option_Length field includes the total length of all three fields: LCP_Option_Type, LCP_Option_Length and LCP_Option_Data.”
支持的LCP_Option_Type（原文逐条）：
| Type | 名称 | 说明 / 取值 |
|---|---|---|
| 1 | MRU（Maximum-Receive-Unit） | 本端可收最大包；默认 1500 字节 |
| 2 | ACCM（Async-Control-Character-Map） | 异步链路控制字符透明化协商 |
| 3 | Authentication-Protocol | 认证协议，见下 |
| 5 | Magic-Number | 检测环路/异常 |
| 7 | PFC（Protocol-Field-Compression） | 协议字段压缩 |
| 8 | ACFC（Address-and-Control-Field-Compression） | 地址/控制字段压缩 |
| 9 | FCS-Alternatives | 备选 FCS 格式。bit1=Null FCS, bit2=CCITT 16-bit FCS, bit4=CCITT 32-bit FCS |
| 13 | Callback | 回拨，callback_data结构见下 |
Authentication-Protocol（Type = 3）可选值（重点）：
蓝皮书原文：
“By default, authentication is not required. The value indicates the authentication protocol used on the given PPP link. Possible values are: 0x0000 – No authentication protocol is used, 0xc023 – The PAP protocol is used, 0xc223 – The CHAP protocol is used, 0xc227 – The EAP protocol is used.”
Callback（Type = 13）结构：
蓝皮书原文（
callback_data）：
“callback-active: boolean (default: false), callback_data_length: unsigned, callback_operation: unsigned, callback_message: octet-string”
callback_operation取值：(0) 由用户认证决定位置, (1) 拨号串, (2) 位置标识, (3) E.164 号码, (4) X.500 可分辨名, (5) 未分配, (6) CBCP 协商时确定。
2.3IPCP_options：网络层协商
IPCP_options_type ::= array IPCP_options_type_element IPCP_options_type_element ::= structure { IPCP_Option_Type: unsigned, IPCP_Option_Length: unsigned, IPCP_Option_Data: CHOICE { array [1] -- for Pref-Peer-IP (each IP addr = double-long-unsigned) boolean [3] -- for GAO and USIP double-long-unsigned [6] -- for Pref-Local-IP long-unsigned [18] -- for IP-Comp-Prot } }支持的IPCP_Option_Type：
| Type | 名称 | 说明 / 取值 |
|---|---|---|
| 2 | IP-Comp-Prot | IP 压缩协议：0x0000 不压缩（默认）, 0x002d Van Jacobson Compressed TCP/IP, 0x0003 ROHC, 0x0061 IP Header Compression |
| 3 | Pref-Local-IP（Preferred-Local-IP-Address） | 本端期望 IP（NOTE 2：RFC 里此选项名为 “IP-Address”） |
| 20 | Pref-Peer-IP（Preferred-Peer-IP-Addresses） | 对端 IP 列表；配合 GAO/USIP 使用 |
| 21 | GAO（Grant-Access-Only-to-Pref-Peer-on-List） | 是否只接受列表内对端 IP；默认 FALSE |
| 22 | USIP（Use-Static-IP-Pool） | 是否给对端分配列表内 IP |
蓝皮书原文（NOTE 3，重要）：
“Option types 20, 21 and 22 have been specified for the purposes of DLMS/COSEM; they are not specified in [RFC 1332].”
即Type 20/21/22 是 DLMS/COSEM 自己扩展的，不是标准 IPCP，专门用来做"白名单接入控制"。当GAO = TRUE，设备只接受对端 IP 在 Pref-Peer 列表里的连接；当USIP = TRUE，服务端尝试把列表里某个 IP 分给对端。
2.4PPP_authentication：认证参数
PPP_auth_type ::= CHOICE { null-data [0] -- used when no authentication is required structure [2] -- PAP_login or CHAP_algorithm or EAP_params }三种认证结构：
PAP_login：{ user-name: octet-string, PAP-password: octet-string }
CHAP_algorithm：{ user-name: octet-string, algorithm_id: unsigned }
algorithm_id取值：0x05 CHAP with MD5（默认）, 0x06 SHA-1, 0x80 MS-CHAP, 0x81 MS-CHAP-2。
蓝皮书原文（NOTE 1）：“When CHAP is used, a ‘secret’ is also required to verify the ‘challenge’ sent by the client. This ‘secret’ is not accessible in the PPP setup object.”——CHAP 的 secret 不在这个对象里，要去别处（通常安全存储/密钥对象）取。
EAP_params：{ md5_challenge (Type 4): boolean, one_time_password (OTP, Type 5): boolean, generic_token_card (GTC, Type 6): boolean }
3. 方法
无（Specific methods 栏为空）。PPP 协商完全靠五个属性配置驱动。
4. 实战举例
示例 1：GPRS 模块 PPP 拨号（PAP 认证）典型配置
| 属性 | 值（示例） |
|---|---|
PHY_reference | 指向 Modem configuration 实例（27） |
LCP_options | [{Type=1, MRU=1500}, {Type=3, Auth-Prot=0xc023}] |
IPCP_options | [{Type=3, Pref-Local-IP=动态}] |
PPP_authentication | structure: PAP_login{user-name="card", PAP-password="1234"} |
以上为工程示意、非蓝皮书原文；实际 APN/账号/密码依运营商与对象列表。
示例 2：带白名单的静态 IP 池（GAO + USIP）
IPCP_options包含：
{Type=20, Pref-Peer-IP = [192.168.100.10, 192.168.100.11]}{Type=21, GAO = TRUE}（只接受列表内对端）{Type=22, USIP = TRUE}（给对端分配列表内 IP）
于是只有 IP 在列表里的主站能拨进来，且会被分到固定 IP。
依据 NOTE 3 + Type 20/21/22 语义。
示例 3：LCP 选项 Type=3（Auth-Prot=CHAP）的 A-XDR 骨架
structure (tag [2]=0x02): unsigned (tag [17]=0x11) = 0x03 // LCP_Option_Type = 3 unsigned (tag [17]=0x11) = 0x04 // LCP_Option_Length = 4 long-unsigned (tag [18]=0x12) = 0xC223 // Auth-Prot = CHAPA-XDR 字节为工程示意，非蓝皮书原文。
示例 4：CHAP 认证结构
PPP_auth_type = structure [2]: structure: CHAP_algorithm{ octet-string = "meter01" // user-name unsigned = 0x05 // algorithm_id = MD5 }工程示意；提醒 secret 不在本对象（见 NOTE 1）。
示例 5：关闭认证（null-data）
PPP_auth_type = null-data [0]用于可信专线/测试环境，生产不建议。
示例 6：SN 短名读取
base namex：LCP_options=x+0x10，IPCP_options=x+0x18，PPP_authentication=x+0x20。
工程示意。
示例 7：FCS-Alternatives（Type=9）按位组合
若想用 CCITT 32-bit FCS：LCP_Option_Data的 FCS 字段 = bit4 =0x04（逻辑或值）。bit1=Null(bit1=1? 原文写 bit 1 Null FCS, bit 2 CCITT 16-bit, bit 4 CCITT 32-bit）——注意这是按位标志，bit 编号 1/2/4 即值 1/2/4。
工程示意。
示例 8：Callback 回拨
LCP_options含{Type=13, callback_data = {callback_active=TRUE, callback_data_length=11, callback_operation=3 (E.164), callback_message="138xxxx"}}—— 拨入后让对端按指定号码回拨，增强安全。
工程示意。
示例 9：PPP 协商时序（LCP → IPCP → 认证 → 建链）
以下为工程示意、非蓝皮书原文；展示三阶段协商如何对应到本类属性。
[设备] -- LCP Configure-Request ---> [对端] 读 LCP_options(本类) [设备] <-- LCP Configure-Ack ------ [对端] 协商 MRU/压缩/Auth-Prot [设备] -- 认证(CHAP/PAP) ----------> [对端] 读 PPP_authentication [设备] <-- 认证成功 ----------------- [对端] [设备] -- IPCP Configure-Request ---> [对端] 读 IPCP_options(Pref-Local-IP) [设备] <-- IPCP: 分配对端 IP ------- [对端] Pref-Peer-IP / USIP 生效 [设备] == 链路 UP，可传 IP 数据 =====================注意：LCP 的 Auth-Prot(默认不认证)、IPCP 的 GAO/USIP 白名单，都是本类属性在协商阶段被引用。
示例 10：与Modem configuration(27) 配合部署清单
| 步骤 | 对象 | 动作 |
|---|---|---|
| 1 | Modem configuration(27) | 设comm_speed、AT 初始化串（拨*99#触发 GPRS） |
| 2 | 本PPP setup(44) | PHY_reference指向 27；设 LCP/IPCP/认证 |
| 3 | IPv4 setup(42) | DL_reference指向本 44（或 TCP-UDP setup），use_DHCP_flag视运营商 |
| 4 | 应用层 | Push setup(40)/SMTP setup(46) 复用上述 IP 链路 |
部署清单为工程示意，非蓝皮书原文。
5. 工程上容易踩的坑
- 版本仍是 0：本版只是"写法改进"，没有新字段，别去找 v1。
- CHAP 的 secret 不在这个对象：
PPP_authentication只存algorithm_id+user-name，真正校验用的 secret 在别处（密钥/安全对象），排查"CHAP 失败"别只盯 44 对象。 - Type 20/21/22 是 DLMS 私扩展：标准 PPP/IPCP 工具不一定认，部分通用协议栈要特殊处理；GAO/USIP 默认 FALSE，不配就是"任意对端可连"。
- Auth-Prot 默认不设 = 不认证：
LCP_options里没有 Type=3，或PPP_authentication = null-data，链路就不认证——生产环境务必显式配 PAP/CHAP。 PHY_reference指错物理层：PPP 跑在哪条串口/猫上，必须指对底层对象，否则拨号起不来。- MRU 默认 1500：链路 MTU 受限（如某些 PLC/串口）时要显式调小，否则大包被丢弃。
- Pref-Local-IP（Type=3）在 RFC 里叫 “IP-Address”：对接标准 IPCP 实现时注意名字差异（NOTE 2），但 Type 号一致。
- 三个选项属性都是 static：PPP 是建链前定好的，运行时 SET 通常无效，要在出厂/配置阶段设好。
- EAP 的三种 flag：
md5_challenge/one_time_password/generic_token_card是并列 boolean，要按需开，别全 TRUE 导致协商失败。
6. 小结 & 下期预告
PPP setup（class_id = 44）用五个属性把"拨号建链"配齐：LCP 协商链路参数（MRU/ACCM/认证/Magic/FCS/回拨）、IPCP 协商 IP（本端/对端/压缩 + DLMS 私扩展的 GAO/USIP 白名单）、PPP_authentication管 PAP/CHAP/EAP。版本仍是 0，无方法，三个选项属性均 static。
下一篇（第 33 篇）：GPRS modem setup（class_id = 45）—— GPRS Modem 的 APN、PIN 与 QoS 配置。本篇把拨号链路上的 LCP/IPCP/认证配好了；下一篇在 PPP 之上再配一层蜂窝 Modem 参数——接入点 APN、SIM 解锁 PIN、以及 default/requested 两层分组 QoS，正好接上第 26 篇Auto connectmode 100–103 的常连接场景。
