DHCP报错ffffffff，可能是因为内存不足？[WIFI-2436]

[xiehang]

好的。从 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 这句 log ，第一个数值是 tx data buffer alloc 数量，第二个是 free 数量， 第四个是 fail 数量。

你可以在复现问题后，停掉测试 case，看看多久可以恢复。

[XHYZN_Marshall]

好的。从 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 这句 log ，第一个数值是 tx data buffer alloc 数量，第二个是 free 数量， 第四个是 fail 数量。

你可以在复现问题后，停掉测试 case，看看多久可以恢复。

感谢，我正在测试解决方法：当问题复现时重启AP。

另外当STA没有收到DHCP的Offer，其会一直卡在哪里无法自行退出连接状态，这是否属于BUG？

[XHYZN_Marshall]

好的。从 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 这句 log ，第一个数值是 tx data buffer alloc 数量，第二个是 free 数量， 第四个是 fail 数量。

你可以在复现问题后，停掉测试 case，看看多久可以恢复。

早上好。问题已有改善。我在问题复现后使用esp_wifi_stop();关闭了AP+STA后等1秒重启，发现结果有些好转，即是问题复现后不会长时间保持不能被连接的状态，过一会之后就能被连接了。但从Logs看，调用esp_wifi_stop();之后并不能马上清空txq softap接口的包？

现在程序修改为：当发现UDP返回错误码12时，会调用esp_wifi_stop()关闭后，再重新开启ap+sta。从Log来看，似乎在62707的位置就已经出现了buffer溢出，但未引发其他问题，到了87376行才出现了UDP错误12。因此我这个依靠UDP返回12错误来判断txq已满，似乎不是特别的有效。因此有没有一些库函数可以查询剩余可用txq,或者是像wifi event一样触发事件？另外是否有库函数可以调用直接清空txq？

以上加粗字体是期望解决的问题。谢谢！

Logs见附件

20200610093122-Log_Server.txt

(5.87 MiB) Downloaded 897 times

20200610093119-Log_Client.txt

(5.91 MiB) Downloaded 964 times

[xiehang]

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，上层是可以修改他的行为的，比如设置超时退出。

[XHYZN_Marshall]

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，上层是可以修改他的行为的，比如设置超时退出。

了解，谢谢。关于第4点，如果超时之后，想要退出，能否使用esp_wifi_disconnect这个函数中断连接？

[xiehang]

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

[XHYZN_Marshall]

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

目前看起来成效比较理想，起码不至于一直连不上。在经历数次的AP重启后，还是能够恢复正常的AP功能的

[XHYZN_Marshall]

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

经过50+小时压力测试OK，问题close，感谢这一周多来的支持！

[xiehang]

好的，问题解决就好。

[XHYZN_Marshall]

好的，问题解决就好。

谢谢，能否请教一下，lmac和hmac的区别是什么？