upload img to qiniu

design_doc/solution_record.md

@@ -194,3 +194,31 @@ m/offset_method/distance_method：标记本次用的算法路径（triangle / ye
 你现在的“环数计算”实际依赖关系
 最好路径（快+稳）：三角形 → dx,dy（单应性） + distance_m（PnP）
 兜底路径：圆/椭圆靶心 → dx,dy（基于黄心半径比例/透视校正） + distance_m（黄心半径估距）
+
+12. 4g模块上传文件：
+
+Upload images from MaixCam to Qiniu cloud via ML307R 4G module's AT commands. The HTTP body requires multipart/form-data with real CR/LF bytes (0x0D 0x0A) in boundaries.
+Methods Tried
+#	Method	AT Commands	Result	Root Cause
+1	Raw binary, no encoding	MHTTPCONTENT with raw bytes + length param	ERROR at first chunk	CR/LF in binary data terminates AT command parser
+2	Encoding mode 2 (escape)	MHTTPCFG="encoding",0,2 + \r\n escapes	Server 400 Bad Request	Module sends literal text \r\n to server, NOT actual 0x0D 0x0A bytes. Multipart body is garbled
+3	Encoding mode 1 (hex)	MHTTPCFG="encoding",0,1 + hex-encoded data	CME ERROR: 650/50	Firmware doesn't properly support hex mode for MHTTPCONTENT
+4	No chunked mode	Skip MHTTPCFG="chunked"	CME ERROR: 65	Module requires chunked mode to accept MHTTPCONTENT at all
+5	Single large MHTTPCONTENT	All data in one command (2793 bytes)	+MHTTPURC: "err",0,5 (timeout)	Possible buffer limit; module hangs then times out
+6	Per-chunk HTTP instance (OTA style)	CREATE→POST→DELETE per chunk	Not feasible	Each instance = separate HTTP request; Qiniu needs complete body in single POST
+Conclusion: AT HTTP layer (MHTTPCONTENT) is fundamentally broken for binary uploads.
+The Solution: Raw TCP Socket (MIPOPEN + MIPSEND)
+Bypass the AT HTTP layer entirely. Open a raw TCP connection and send a hand-crafted HTTP POST:
+plaintext
+AT+MIPCLOSE=3                                    // Clean up old socket
+AT+MIPOPEN=3,"TCP","upload.qiniup.com",80        // Raw TCP connection
+AT+MIPSEND=3,1024  →  ">"  →  [raw bytes]  →  OK  // Binary-safe!
+AT+MIPSEND=3,1024  →  ">"  →  [raw bytes]  →  OK
+AT+MIPSEND=3,766   →  ">"  →  [raw bytes]  →  OK
+// Response: +MIPURC: "rtcp",3,<len>,HTTP/1.1 200 OK...
+AT+MIPCLOSE=3
+Why it works:
+MIPSEND enters prompt mode (>) — after the >, the AT parser treats ALL bytes as data, including CR/LF
+We construct the complete HTTP request ourselves (headers + Content-Length + multipart body) with real CRLF bytes
+
+Key bug found during integration: _send_chunk() wrapped calls in self.at._cmd_lock, but self.at.send() also acquires the same lock internally — threading.Lock() is not reentrant, causing deadlock. Fixed by removing the outer lock (the network_manager.get_uart_lock() already provides thread safety).Trade-off: UART is locked during the entire upload, so heartbeats pause. For small JPEG files (~2-80KB), this is 5-20 seconds — acceptable if server heartbeat timeout is generous

design_doc/todo.md

@@ -24,8 +24,8 @@ r = hardware_manager.at_client.send(f'AT+MSSLCFG="auth",{ssl_id},0', "OK", 3000)
 这些在 config.py 是明文：
 SERVER_IP = "stcp.shelingxingqiu.com"SERVER_PORT = 50005HTTP_URL = "http://ws.shelingxingqiu.com"HTTP_API_PATH = "/home/shoot/device_fire/arrow/fire"
 注意：即使你把它们藏进 .so，攻击者仍可能通过抓包/观察 DNS/SNI/流量拿到域名或 IP，所以“隐藏”只能降低静态分析风险，不能替代鉴权/签名。
-2.2 WiFi 凭证落盘位置
-你会把 SSID/密码写到 /boot/wifi.ssid 和 /boot/wifi.pass（network.py/wifi.py 都有）。拿到设备存储就能读到明文密码，这属于设备侧安全问题。
+
+
 2.3 日志/调试信息泄露
 你仓库里 .cursor/debug.log* 已经记录了完整的 AT+MIPOPEN ... host:port 等信息；如果这些被打进包或被用户导出，也会泄露通信细节。
 你发布包里“真正会被带走的敏感内容”
@@ -37,5 +37,9 @@ files:  - app.yaml  - at_client.py  - camera_manager.py  - config.py  - hardware
 把“password=device_id+.” 改为真正的 per-device secret（设备出厂烧录，服务端保存；或服务端下发公钥，设备用私钥签名）
 所有上报/控制命令加签名 + nonce/timestamp + 服务端防重放（别人抓到一次包也不能复用）
 OTA 包必须做签名校验（设备端内置公钥，下载后验签通过才应用）
-TLS 必须做证书校验/最好做 pinning（至少别用 auth=0）
-如果你告诉我：你们服务端目前能不能改协议（例如新增签名字段、下发 challenge、做 OTA 签名），我可以按“最小改动但提升最大安全”的顺序，帮你规划一套从现状平滑升级的方案。
+
+如果你告诉我：你们服务端目前能不能改协议（例如新增签名字段、下发 challenge、做 OTA 签名），我可以按“最小改动但提升最大安全”的顺序，帮你规划一套从现状平滑升级的方案。
+
+
+
+https://wiki.sipeed.com/maixpy/doc/zh/pro/compile_os.html