Fix: compilation error when only IPv4 is enabled (IPv6 disabled). - #265
Open
sqqdfny wants to merge 17 commits into
Open
Fix: compilation error when only IPv4 is enabled (IPv6 disabled).#265sqqdfny wants to merge 17 commits into
sqqdfny wants to merge 17 commits into
Conversation
…from_description() 的 addrstring[] 溢出导致死机的问题。 2.修复: src/agent.c/agent_set_remote_description() 的 remote_ufrag/remote_upwd 有可能溢出(没有结束符)的问题。 3.修复: src/address.c/addr_to_string() 清空 buf 的 bug 。
- src/agent.c agent_process_stun_request()/agent_connectivity_check()
- src/ice.c ice_candidate_from_description()
- src/peer_connection.c peer_connection_loop()
2.修复: peer_connection_datachannel_send() 的 sid 固定使用 0 的问题
- src/peer_connection.c peer_connection_datachannel_send()
- src/sctp.c sctp_incoming_data()
…CK 统一使用该宏替换 magic number
2.修改: sctp_incoming_data() 循环防护——length 初始化清零；chunk 长度 < sizeof(SctpChunkCommon) 时 break 防死循环；
数据块按 4 字节对齐推进 pos
3.修改: peer_connection.c COMPLETED 状态 agent_recv 改为单次最多 16 个数据报的 burst 循环，
避免单帧 SACK 突发撑爆 UDP 接收队列
…等消息的处理，修复长时间连接异常的问题。
- peer_connection: 初始化 state 为 NEW，SCTP 关联失败时触发CLOSED，close/超时统一使用 STATE_CHANGED 宏通知状态变更
- sctp: 新增 HEARTBEAT/ACK、SHUTDOWN/ACK/COMPLETE、ERROR、FORWARD_TSN 等 chunk 完整处理，ABORT 时置位association_failed，
修复 cookie_echo 空指针，修复 chunk 循环边界计算，create_association 初始化失败标志位
- sctp.h: 新增 association_failed 字段
- 移除旧的 LOG_REDIRECT 条件分支，LOG_PRINT 重命名为 LIBPEER_LOG_PRINT，通过 #ifndef 允许外部覆盖
…ndidate
修复 Android 手机浏览器 WebRTC MJPG 推流失败的问题。
问题:
QEMU 做 WiFi AP 时，Android Chrome 在 SDP answer 中给出的 ICE candidate
是蜂窝数据接口 IP（10.65.209.x）而非 WiFi 分配的局域网 IP。
设备端发往这个不可达 IP 的 STUN binding request 全部 FAILED，
ICE 永远卡在 checking 状态。
根因:
agent_process_stun_request() 收到浏览器发来的 valid STUN binding request
后只回复 response，不标记 candidate pair 为 SUCCEEDED，也不从 source
address 创建 peer-reflexive candidate。违反 RFC 8445 §7.2.5.3.2。
修复 (3 个文件):
1. address.c — 实现 addr_equal() 桩函数
- 之前始终返回 1 (TODO 未实现)
- 改为对 AF_INET 比较 s_addr, AF_INET6 用 memcmp
2. agent.c — agent_process_stun_request() 新增两阶段匹配
- Phase A: 收到 STUN request 时，用 addr_equal 匹配 source
address 到已有 remote candidates，匹配成功则标记 pair 为 SUCCEEDED
- Phase B: 匹配失败时，从 source address 创建 PRFLX remote
candidate + candidate pair（已验证可达的真实 WiFi 地址）
- 现有 mDNS fallback 路径（candidate_pairs_num==0）完全不变
- agent_connectivity_check() 新增 SUCCEEDED 状态提前返回，
确保被 inbound STUN 标记 pair 能正确定向 PEER_CONNECTION_CONNECTED
3. ice.c — 补全 PRFLX 候选类型
- ice_candidate_type_preference: PRFLX = 110 (RFC 5245,
HOST=126 和 SRFLX=100 之间)
- ice_candidate_to_description: 添加 prflx 类型字符串
sctp_incoming_data() 处理 SCTP_DATA chunk 时，SACK 确认包构造在 共享输出缓冲区 sctp->buf 中，随后调用 sctp->onmessage() 回调。 若回调内部通过 peer_connection_datachannel_send() → sctp_outgoing_data() 发送数据（如 pong 响应），sctp_outgoing_data() 会覆写 sctp->buf。 回调返回后，代码将被覆写的缓冲区（现包含 pong 数据而非 SACK） 再次发送给对端。 浏览器 SCTP 栈收到损坏的"SACK"，无法确认原始 ping 已送达， 触发重传 → 开发板再次收到 ping → 再次发送 pong → 再次收到损坏 SACK → 形成无限循环（表现：浏览器发一次 ping，持续收到无数 pong）。 修复：在 DATA_CHANNEL_PPID_DOMSTRING / _BINARY 分支中，将 SACK 的 发送移到 onmessage 回调之前，发送后置 length = 0 防止重复发送。 DCEP OPEN 分支（PPID_CONTROL）不调用 onmessage，不受影响。 同时修复 sctp_outgoing_data() 中 chunk->sid 被硬编码为 htons(0) 的缺陷，使其正确使用传入的 sid 参数。
…，也不发送 STUN Binding 的问题。 - 创建 SDP 时，如有多个 "m=" 行，比如说同时启用 video/audio/datachannel，需要把 "a=candidate" 放到第一个 "m=" 行之后。
根因：mbedtls 3.x 的 ssl_export_keys_cb 回调签名为 void 无返回值，
若 DTLS Server 的 HELLO_VERIFY_REQUIRED 重试循环中第一次 srtp_create
成功但第二次 srtp_add_stream 失败（srtp_create 内部显式置 *session=NULL），
错误被静默吞噬。DTLS 握手报成功但 srtp_in 为 NULL，
PEER_CONNECTION_COMPLETED 状态下收到 RTCP 包触发 Load Access Fault。
修复（dtls_srtp.c）：
- dtls_srtp_init: 显式清零 srtp_in/srtp_out，防 HELLO_VERIFY_REQUIRED
重试时旧 session 被覆写泄漏
- dtls_srtp_reset_session: srtp_dealloc 后置 NULL，消除悬垂指针
- 四个加解密函数 (decrypt_rtp/rtcp, encrypt_rtp/rtcp): 调用前加
srtp_in/srtp_out 空指针守卫，防御所有路径的空指针崩溃
- srtp_create 失败日志等级 LOGD→LOGE
修复（peer_connection.c）：
- PEER_CONNECTION_CONNECTED → dtls_srtp_handshake 成功后检查
dtls_srtp.state != DTLS_SRTP_STATE_CONNECTED，若密钥派生回调
静默失败则标记 PEER_CONNECTION_FAILED，触发上层 webrtc_loop_task
自动 cleanup + 重建
修复 Chrome 播放 /webrtc-h264 流时画面仅顶部约 1/4 正常、帧率极低、 疑似只有 I-frame 被解析的问题。 根因：rtp_encoder_encode_h264 对一帧内的每个 slice NAL 单独递增 RTP timestamp 并置 marker=1。源流 x264 slices=3，一帧 3 个 slice 被接收端 按 timestamp 归为 3 个独立"帧"：slice 0（画面顶部）单独可解，slice 1/2 跨 slice 引用宏块必然解错；仅 IDR 首 slice 干净，GOP 间隔 2s 呈现为 "只有 I-frame 被解析"。 修复： - h264 single/FU-A 编码路径 marker 仅帧末 NAL 末包置位（is_last）， 整个 access unit 共享同一 RTP timestamp，循环结束后仅递增一次 - NAL 起始码剥离改为按 4 字节起始码精确剥离（删除原剥尾部 0x00 循环） - 默认媒体时钟步进改为 90000/15（原硬编码 90000/30，源为 15fps） - 新增 rtp_encoder_set_timestamp_increment() 与 peer_connection_set_video_timestamp_increment()，供上层按实际 pts 动态调整媒体时钟（webrtc_h264.cpp 调用） - 帧级取证日志默认关闭（#if 0） 验证：320x240@15fps slices=3 源流经 RTP/SRTP 推流，aiortc 客户端 解码 dump 帧与源视频逐字节一致（Y-PSNR 99dB）；AU 结构 P 帧 [1,1,1]、IDR [7,8,5,5,5] 同 timestamp，IDR 间隔精确 180000（2s GOP）； 3 次 PLI 均触发 IDR 缓存重发（idr_resends=3），恢复延迟 <1s。
- 加密后 RTP 包原样缓存（含 SRTP auth tag），重发保持原 seq/ts/ssrc， 规避明文重加密被发送侧 rdbx 以 pkt_idx_old 拒绝的路径；接收侧重放 窗口对真丢失包放行、对竞态重复包丢弃 - 解析 RTCP RTPFB (fmt=1) generic NACK：FCI 取 PID + 16bit BLP 位图， 仅响应本地视频 SSRC（pc->vrtp_encoder.ssrc）的丢失包 - ring 为 struct 末尾柔性数组（nack_ring[0]），槽位数由新增 config.nack_ring_packets 决定：0 = 禁用（不缓存、不重传、不占内存）； 非 0 必须为 2 的幂，create 时校验，非法直接失败 - 同余槽位以 seq 匹配实现窗口语义：seq 滑出 ring 后槽位内容必不匹配， 天然失效，无需显式清槽 - calloc 总大小溢出守卫（SIZE_MAX / sizeof(nack_ring_entry_t)）， 防 RV32 下 32 位 size_t 计算回绕越界写 - 新增 peer_connection_get_nack_retransmits() 统计接口
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My environment is RISC-V + FreeRTOS + LWIP. To save resources, my project enables only LWIP_IPV4. However, the current libpeer code causes compilation errors when only IPv4 is enabled. Therefore, I added a CONFIG_USE_IPV6 macro to guard all IPv6‑related variables and API calls when LWIP_IPV6 is not defined.
Additionally, I fixed several compilation warnings.