网络相关

​ 可以实现，网卡 IP 为 192.168.4.2，终端（PC / 手机）接入模块 AP 属 5 网段，由终端（PC / 手机）发送的数据会经模块内部会转发至 192.168.4.1，二者可互 ping 通，从而实现跨网段通信。

进入 Light-sleep 后，APB 和 USB PHY 时钟都会关闭，USB 相关控制器无法继续正常工作，因此 USB 网络连接中断是由底层硬件机制决定的，无法在保持 USB 网络不断开的同时进入浅睡眠。

可选方案如下：

1. 改用 Wi-Fi + Light-sleep 的组合方案。
2. 使能 CONFIG_USJ_NO_AUTO_LS_ON_CONNECTION 选项，在 USB 连接存在时不进入睡眠，但这会增加功耗。
3. 更换 4G 接口方案，改用 UART 通信而不是 USB。

参考文档：
https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32s3/api-guides/usb-serial-jtag-console.html#id7

如果日志类似如下：

E (1490825) USBH_CDC: usbh_cdc_send_custom_request(1024): CTRL transfer failed
E (1490825) usbh_rndis: usbh_rndis_query_msg_request(103): Failed to send query message
E (1490835) usbh_rndis: usbh_rndis_get_connect_status(153): Failed to query OID_GEN_MEDIA_CONNECT_STATUS
W (1490835) usbh_rndis: Failed to get connect status

这是 ESP 端通过控制端点定时查询 4G 模组连接状态时，4G 模组没有正确回应导致的。部分 4G 模组不支持这种查询方式。

理论上这类日志不影响实际通信。后续官方可能会把该查询改成可选项；当前如需规避日志，可以临时注释掉对应报错处的代码。

该问题通常是工程 main/idf_component.yml 中没有限制 esp_hosted 版本，构建时自动解析到较新的 2.12.8 版本导致的。

该版本在当前工程环境下启动 ESP-Hosted 时，对 SDIO mempool 所需内存的分配需求更高或限制更严格，导致 sdio_mempool_create() 内存申请失败并触发断言。

处理方法是将工程 main/idf_component.yml 中的 esp_hosted 版本固定为 2.7.2，再重新执行清理和构建。

HTTP 是请求-响应型协议，需要由客户端发起请求并由服务端返回响应，不适合直接实现持续、双向的透明数据传输。

如需实现透传类控制，建议根据传输距离和网络环境选择 BLE 或长连接 TCP。如果业务必须使用 HTTP，则需要在应用层设计轮询、长轮询或其他消息交互机制，但这已经不属于直接透传。

原因分析：

该现象由 ESP-WIFI-MESH 的架构设计决定。根节点是 ESP-WIFI-MESH 网络与外部 IP 网络之间的唯一接口，因此 PC 等外部设备只能直接与根节点通信，无法直接访问子节点。

解决方案：

可改用 ESP-MESH-LITE 方案。ESP-MESH-LITE 的每个节点均启用 lwIP 协议栈，可独立调用 Socket、HTTP 等网络接口，因此子节点的 HTTP 服务可被访问。

原因分析：

timeout_ms 是单次网络操作的超时阈值，例如 TCP/TLS 连接建立（esp_transport_connect）和单次数据写入（esp_transport_write）。从客户端初始化到 esp_http_client_read_response 包含域名解析、TCP 握手和 TLS 握手等多个步骤，各步骤分别计时。

解决方案：

只要每个网络操作步骤的耗时均未超过 350 ms，就不会触发超时。因此，整个流程的总耗时可以超过 350 ms，不能将 timeout_ms 理解为整个 HTTP 请求流程的总超时时间。