好的，问题解决就好。

可以，应用层的行为，根据你们的场景来做就可以。

1，调用 esp_wifi_stop() ,会清空 hmac txq 中的包，lmac txq 中的是不会被清的。stop 之后大约 5s ，lmac txq 才会被清掉。 2，没有可以查询 txq 状态的 API。 3，TX data buffer 是用来发送 数据帧 的，发送 数据帧 都会用到它，不局限于 UDP，所以检查 UDP 返回 12 并不是特别有效。 底层没有什么判断方法，对于底层来说， no memory 是一种正常的现象。建议在 dhcp offer 发送失败返回 no memory 后重启 softap。 4，无法自行退出连接状态，这不属于 bug，上层是可以修改他的行为的...

好的。从 log 看，出问题之后，系统还在发包，只是发包速度很慢，导致 txq 队列阻塞。即生产者速度大于消费者。 txq 释放的条件：1，数据包发送成功。 2，disconnect 事件产生，会清除 txq 中 sta 接口的包。3， softap stop 会清除掉 txq 中 softap 接口的包 4，老化，会把长时间不能发送出去的包清除掉。 目前怀疑是 对端断电，导致 txq 中 TCP 包不能成功发送出去，长时间堵塞在 txq 中，等老化后才能释放 buf，导致后面的 DHCP offer 申请不到 buf。 buf tx: 12804/12740/4294967232/105 这...

你说的 没抓到的情况，应该是 “softap + sta” 的 sta 发出去的包没有抓到，应该是把它过滤掉了。同一块板子，softap 和 sta mac 地址是不一样的。

”softap + sta “ 的sta 都有那些操作？

你这个抓包好着呢，抓包时也存在抓包卡露包的情况。
抓包按照 mac 地址过滤就可以，一般是用 sta mac 和 softap mac 就可以。两个 mac 地址条件设为 or 。

好的，我先分析下抓包。大量 UDP 和 TCP 没有抓到是说测试中还有大流量的收发吗？

Hi ，有完成抓包吗？这个问题现在怎么样了？

是的，抓无线包。