super_agent_bot
b5671e8c02
fix(net/udp): 收包剥头只看芯片宣布的字节数，与 udp_mode 无关（#73）
真机第一轮（2026-11-04 08:16，阶段 16 台架）把本轮最大的一条设计错误照了出来：
TC-NET-1603 在客户端形态下发 48 字节应答，板子读到的是 `n=56`、首字节 `0x38`
——56 正是信息头的长度字段，也就是**头还在**，而我把它的 8 字节当成了载荷。
设计时按手册 §9.2.4 读出一句"客户端模式不带信息头"，就以为运行时把 DesIP 从
全 F 改成具体对端会让头消失。真机给的定案是：**加不加 8 字节信息头，是在
OPEN_SOCKET 那一刻由当时的 DesIP 定死的**，之后再改 DesIP 只改发送去向与芯片
的收包源过滤，不改收包帧格式。本层 `net_bind` 一律以 DesIP=0xFFFFFFFF 开
Socket，所以对本层的 UDP socket 而言头恒在、恒剥。
- `net_udp_datagram_read` 的剥头条件由 `udp_mode == SERVER && avail >= 8` 改为
**只看 `avail >= 8`**；源地址一律从信息头里取——头里的源 IP/端口是本包的真实
来源，比"我把包发给了谁"这本账更准（NAT 后的时间服务器就是两种地址不一致的
那种）。
- 不足 8 字节的残包保持既有定案（TC-NETSOCK-440o）：无从判头，整包按载荷交付，
源地址退到对端记账。这也是 `net_udp_src_from_peer()` 如今唯一的读者。
- `udp_mode` 语义收窄为"芯片的对端过滤 + 发送去向"，**不描述收包帧格式**；
`net_types.h` 的 UDP 形态块、两个模式宏的注释、`net_sendto` / `net_recvfrom`
的函数说明一并按定案改写。字段本身没动，仍复用原有的 2 字节 padding，RAM 零增长。
产品构型 Keil 构建 0 Error 0 Warning，`Code=249120 RO=29836 RW=2052 ZI=149996`，
与改造前的产品基线同尺寸。判据文字与真机证据见同批的测试、文档提交。
2026-11-04 09:15:17 +08:00
..
2026-10-30 07:16:07 +08:00
2026-10-30 07:16:07 +08:00
2026-11-04 09:15:17 +08:00
2026-11-02 14:46:42 +08:00
2026-10-29 20:59:36 +08:00
2026-10-30 13:03:12 +08:00
2026-10-30 07:16:07 +08:00
2026-11-02 03:33:51 +08:00
2026-11-02 22:19:58 +08:00
2026-10-30 13:03:12 +08:00
2026-10-30 07:16:07 +08:00
2026-09-01 16:07:00 +08:00
2026-10-10 10:17:00 +08:00
2026-10-30 07:16:07 +08:00