1. 初识 errfTCP 连接异常时的“紧急联络员”如果你用过 lwIP 做嵌入式网络开发肯定对那一堆回调函数不陌生。tcp_recv收数据tcp_sent通知发送成功tcp_poll定期来打个招呼。但tcp_err注册的这个errf回调可能是你最不想见到却又不得不认真对待的一个。它就像是 TCP 连接里的“紧急联络员”平时默默无闻一旦连接出了大问题它就会立刻跳出来通知你“喂出事了赶紧来收拾残局”我刚开始用 lwIP 那会儿最头疼的就是 TCP 连接莫名断开或者对端突然“失联”程序里的资源比如内存、socket 描述符却还傻傻地占着不放时间一长系统就崩了。后来才明白处理好errf回调是写出健壮网络应用的关键一步。简单来说errf回调是 lwIP 协议栈在 TCP 连接发生不可恢复的错误时通知应用程序进行错误处理和资源清理的唯一官方通道。它的函数原型长这样typedef void (* tcp_err_fn)(void *arg, err_t err);你通过tcp_err(pcb, my_err_callback)把这个函数注册进去。当灾难降临协议栈会调用它并告诉你错误码err。这里有个至关重要的细节当errf被调用时对应的tcp_pcb控制块已经被协议栈释放了这意味着你在回调函数里不能再碰这个pcb指针否则就是访问野指针程序崩溃没商量。你的任务是根据err错误码去清理你自己应用层关联的资源比如释放你为这个连接分配的内存、关闭文件句柄、更新状态机等。那么什么情况下这位“联络员”会出动呢主要就是三大场景连接被对方复位RST、连接意外关闭、以及协议栈内部主动放弃连接。下面我们就钻进源码看看这些场景下errf是如何被触发的以及我们该怎么应对。2. 场景一收到 RST 标志连接被强制复位这是最常见的一种异常。想象一下你的设备作为客户端去连接一个服务器如果服务器那边对应的端口根本没打开或者连接建立后服务器进程突然崩溃服务器端的 TCP 协议栈就会给你发一个RSTReset标志位置位的报文意思就是“别废话了这连接不存在赶紧断了念想”。在 lwIP 源码tcp_input()函数里处理输入报文时会调用tcp_process()。如果检测到收到的报文带有 RST 标志并且序号Sequence Number是合法的防止恶意 RST 攻击就会设置recv_flags中的TF_RESET标志并返回ERR_RST。// 简化后的 tcp_input 函数片段 err_t err tcp_process(pcb); if (err ! ERR_ABRT) { if (recv_flags TF_RESET) { /* 连接被远端复位了 */ TCP_EVENT_ERR(pcb-state, pcb-errf, pcb-callback_arg, ERR_RST); tcp_pcb_remove(tcp_active_pcbs, pcb); tcp_free(pcb); } }看到没TCP_EVENT_ERR这个宏就是触发errf回调的“开关”。这里传递的错误码是ERR_RST。调用完你的错误处理函数后协议栈紧接着就把pcb从活动链表里摘掉并释放了。所以在你的errf回调里如果之前用tcp_arg()给这个pcb绑定了一个自定义的数据结构指针比如叫conn_ctx现在就是你把它free掉的最佳时机。实战踩坑记录我曾经遇到一个设备做 TCP 客户端频繁重连服务器。偶尔网络闪断服务器发的 RST 报文可能晚到。如果客户端在errf回调里只是简单地把conn_ctx置 NULL而没有真正关闭底层 socket 或释放资源就会导致资源泄漏。后来我改成在回调里设置一个“连接已死”的标志位并在应用层的主循环里检查这个标志再执行一系列安全的清理动作问题就解决了。这提醒我们errf回调的执行上下文是协议栈的内部中断或任务不宜做太复杂、耗时的操作设置标志、发信号量通知应用层任务来处理是更稳妥的做法。3. 场景二连接意外关闭ERR_CLSD这个场景有点微妙它处理的是“非优雅关闭”。正常情况下TCP 通过四次挥手FIN/ACK来关闭连接。但有时候对方发了 FIN 过来我方应用层却“忘了”调用tcp_close()来回应。协议栈不能无限期等待这时候就会触发ERR_CLSD。具体逻辑在tcp_input()里当连接处于LAST_ACK状态表示我方已经发了 FIN在等对方最后一个 ACK时如果收到了对方对这个 FIN 的 ACK连接按理就该彻底关闭。但如果此时pcb-flags里没有设置TF_RXCLOSED表示应用层还没关闭接收方向协议栈就认为这是个“意外”需要通知应用层。// 简化后的代码 if (recv_flags TF_CLOSED) { if (!(pcb-flags TF_RXCLOSED)) { TCP_EVENT_ERR(pcb-errf, pcb-callback_arg, ERR_CLSD); } tcp_pcb_remove(tcp_active_pcbs, pcb); memp_free(MEMP_TCP_PCB, pcb); }ERR_CLSD这个错误码明确告诉你连接已经关闭了但可能不是通过你预期的路径。在实际项目中我常用这个回调来检测对端是否“不告而别”。比如一个长连接的心跳包突然停了随后可能就会触发这个错误。在处理时除了释放资源我还会记录日志用于分析连接不稳定的原因。4. 场景三协议栈内部放弃连接ERR_ABRT这是最复杂的一类错误码是ERR_ABRTAbort。它不是由外部报文直接引起的而是协议栈内部各种超时、重传失败、资源耗尽等机制最终导致连接被“放弃”。触发点主要有两个tcp_abandon()函数和tcp_slowtmr()慢定时器。4.1 由 tcp_abandon 触发的放弃tcp_abandon()函数是连接放弃的核心执行者。它会把pcb从相关链表移除按需释放数据缓冲区并可选地发送 RST 报文通知对端。最后它会调用TCP_EVENT_ERR并传入ERR_ABRT。那么谁会让tcp_abandon出手呢连接建立失败在tcp_listen_input()中当处于 LISTEN 状态的 PCB 收到 SYN 报文会创建一个新的 PCB 来响应 SYNACK。如果这个响应报文SYNACK组装失败比如内存不足就会调用tcp_abandon(npcb, 0)放弃这个尚未完全建立的连接。资源紧张时的“牺牲品”在tcp_alloc()函数里当需要为新连接分配 PCB 而内存不足时协议栈会尝试“杀掉”一些现有连接来腾空间。它会先找 TIME_WAIT 状态的连接tcp_kill_timewait不行再找 LAST_ACK 或 CLOSING 状态的tcp_kill_state最后甚至找优先级最低的活跃连接tcp_kill_prio。对于 LAST_ACK/CLOSING 状态的连接tcp_kill_state会调用tcp_abandon(inactive, 0)来放弃因为这两种状态本身也快结束了不发送 RST 也不会造成数据丢失。应用层主动中止当你调用tcp_abort(pcb)时它内部就是调用了tcp_abandon(pcb, 1)。这个1表示要发送 RST 报文。这里有个非常重要的坑tcp_abort的注释明确警告如果你是从其他 TCP 回调函数比如recv,sent,poll里调用tcp_abort你必须确保该回调函数返回ERR_ABRT。否则协议栈在回调返回后可能还会去访问已经释放的pcb导致内存错误。我吃过这个亏在recv回调里发现数据异常直接tcp_abort但忘了返回ERR_ABRT结果程序随机崩溃查了好久。4.2 由 tcp_slowtmr 触发的超时放弃tcp_slowtmr()是 lwIP 的慢定时器每 500ms 触发一次负责重传和连接超时管理。它就像一个冷酷的“守夜人”检查所有活跃连接是否还“活着”。如果遇到以下情况它就会标记这个连接需要移除pcb_remove并在清理流程中调用TCP_EVENT_ERRSYN_SENT 状态发起连接后SYN 报文重传次数超过TCP_SYNMAXRTX默认 6 次还没收到 SYNACK。其他状态数据报文重传次数超过TCP_MAXRTX默认 12 次。坚持定时器Persist Timer当对方通告窗口为 0 时我方会启动坚持定时器定期发送窗口探测报文。如果探测超过TCP_MAXRTX次仍无响应。FIN_WAIT_2 状态超时我方主动关闭并进入 FIN_WAIT_2 后如果迟迟收不到对方的 FIN 报文超过TCP_FIN_WAIT_TIMEOUT默认 20 秒。SYN_RCVD 状态超时作为服务器收到 SYN 后进入此状态如果迟迟收不到客户端的 ACK超过TCP_SYN_RCVD_TIMEOUT默认 20 秒。LAST_ACK 状态超时等待最后一个 ACK 超时超过2 * TCP_MSL默认 120 秒。保活机制Keep-alive超时如果使能了 SOF_KEEPALIVE 选项在 ESTABLISHED 或 CLOSE_WAIT 状态下长时间默认超过 2 小时 10 分 48 秒没有数据往来保活探测也失败。当tcp_slowtmr判定一个连接需要被清除时它会先调用tcp_pcb_purge(pcb)释放这个 PCB 上所有排队的数据缓冲区unsent,unacked,ooseq等然后从tcp_active_pcbs链表移除最后调用TCP_EVENT_ERR通知应用层。5. 实战编写健壮的 errf 回调函数知道了原理我们来动手写一个真正有用的errf回调。核心原则就一条快速、安全地清理应用层资源并通知主程序更新状态。假设我们为一个 TCP 连接定义了一个上下文结构体typedef struct { int id; void *custom_data; volatile uint8_t is_closed; // 标志位用于通知主循环 // ... 其他应用数据 } my_conn_ctx_t;在建立连接时我们这样设置my_conn_ctx_t *ctx (my_conn_ctx_t*)malloc(sizeof(my_conn_ctx_t)); // ... 初始化 ctx tcp_arg(pcb, ctx); // 将上下文绑定到 pcb tcp_err(pcb, my_tcp_err_callback); // 注册错误回调那么错误回调函数可以这样实现void my_tcp_err_callback(void *arg, err_t err) { my_conn_ctx_t *ctx (my_conn_ctx_t *)arg; if (ctx NULL) { return; } // 1. 记录错误类型和日志注意这里不能调用可能阻塞或很耗时的函数 printf([TCP ERR] Connection ID %d aborted with error: %d\n, ctx-id, err); // 2. 设置连接已关闭标志。因为 pcb 已释放绝不能再用 tcp_close() 等操作它。 ctx-is_closed 1; // 3. 如果有关联的定时器、信号量等资源在这里标记它们需要被清理。 // 例如设置一个全局事件标志或放入一个待清理队列。 // 注意不要在这里直接 free(ctx) // 因为协议栈可能在中断上下文调用此回调直接 free 不安全。 // 应该由主循环或专门的任务在检测到 is_closed 标志后进行安全的释放。 }在你的主程序循环或任务中需要定期检查所有连接的ctx-is_closed标志void my_app_task(void) { for (int i 0; i MAX_CONN; i) { if (g_conn_ctx_pool[i] g_conn_ctx_pool[i]-is_closed) { my_conn_ctx_t *ctx_to_free g_conn_ctx_pool[i]; g_conn_ctx_pool[i] NULL; // 执行安全的清理工作关闭文件、释放内存等。 if (ctx_to_free-custom_data) { free(ctx_to_free-custom_data); } free(ctx_to_free); printf(Freed resources for connection ID %d\n, i); } } }这种“回调里标记主循环里清理”的模式在嵌入式实时系统中非常经典它平衡了中断响应速度和资源操作的安全性。6. 进阶结合 NETCONN/Socket API 的错误处理如果你用的是 lwIP 的NETCONN API或Socket API错误处理机制被封装得更上层一些。以 NETCONN 为例当你创建一个netconn连接时底层会自动设置好对应的errf回调在setup_tcp()函数里注册的是err_tcp。err_tcp这个内部回调函数做了几件关键事将netconn结构内部的pcb指针置为 NULL因为底层 PCB 已经没了。保存错误码到conn-pending_err。标记连接邮箱已关闭 (NETCONN_FLAG_MBOXCLOSED)。向conn-recvmbox和conn-acceptmbox这两个邮箱发送错误消息。如果上层有线程正阻塞在netconn_recv()或netconn_accept()上这个错误消息会唤醒它们并使这些 API 返回对应的错误。所以对于使用 NETCONN/Socket 的开发者你通常不需要直接处理errf。你只需要检查netconn_recv(),netconn_accept(),netconn_write()等函数的返回值或者通过netconn_geterror()来获取错误信息。当这些 API 返回类似ERR_CONN,ERR_CLSD,ERR_ABRT等错误时就表示底层连接已经出问题errf已经被触发过了。此时你应该关闭并删除netconn对象然后重建连接。理解errf的底层触发机制能让你在使用高层 API 时更清楚这些错误码的来源在调试网络问题时也能更快地定位到是应用层逻辑问题还是协议栈底层的超时、复位等机制导致的连接中断。