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

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Thu Jun 04, 2020 10:50 am

xiehang wrote:
Thu Jun 04, 2020 8:59 am
我在申请内存的地方添加了一些打印,你可以帮我在复现下这个问题吗
使用方法:
把 2020-06-04_164108.zip 解压,把 2020-06-04_164108/esp32 目录下所有 .a 文件放到 esp-idf/components/esp32/lib 目录下就可以。
OK!我已经得到了一些Debug

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Fri Jun 05, 2020 1:19 am

xiehang wrote:
Thu Jun 04, 2020 8:59 am
我在申请内存的地方添加了一些打印,你可以帮我在复现下这个问题吗
使用方法:
把 2020-06-04_164108.zip 解压,把 2020-06-04_164108/esp32 目录下所有 .a 文件放到 esp-idf/components/esp32/lib 目录下就可以。
你好,我已经复现问题,并且得到一些额外的debug,我将它们上传上来。

20200603054705-Log_Server.txt
(6.3 MiB) Downloaded 1003 times
问题开始复现于29173行
20200603054709-Log_Client..txt
(6.97 MiB) Downloaded 948 times
问题开始复现于25247行

xiehang
Posts: 26
Joined: Mon Mar 18, 2019 8:57 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby xiehang » Fri Jun 05, 2020 6:51 am

我们的 TX data buffer 默认配置是 32 个。
从 log 判断,在出问题的点上,TX data buffer 已经用了 32 个,导致发送 DHCP offer 时申请不到 TX data 类型的 buffer。
而系统的 TX mgmt buffer 还可以使用,所以 WiFi 的连接是正常的。
你可以配置 TX data buffer 数目为 64 ,试试能不能 Fix 这个问题。
配置方法: menuconfig ---> Component config ---> WiFi ---> Max number of WiFi dynamic TX buffer
另外,“softap + sta” 除了连接 AP,和每 2.5s 发送一个 广播包,还有其他的业务吗?
连接 “softap + sta" 的 sta 有几个,它们有其他操作吗?

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Fri Jun 05, 2020 7:53 am

xiehang wrote:
Fri Jun 05, 2020 6:51 am
我们的 TX data buffer 默认配置是 32 个。
从 log 判断,在出问题的点上,TX data buffer 已经用了 32 个,导致发送 DHCP offer 时申请不到 TX data 类型的 buffer。
而系统的 TX mgmt buffer 还可以使用,所以 WiFi 的连接是正常的。
你可以配置 TX data buffer 数目为 64 ,试试能不能 Fix 这个问题。
配置方法: menuconfig ---> Component config ---> WiFi ---> Max number of WiFi dynamic TX buffer
另外,“softap + sta” 除了连接 AP,和每 2.5s 发送一个 广播包,还有其他的业务吗?
连接 “softap + sta" 的 sta 有几个,它们有其他操作吗?
好的谢谢,我将会实时修改为64,但是这可能不是问题的诱因。因为这可能是因为某些地方没有释放已经关闭的连接,导致TX data buffer越来越多。

连接softap+sta 的 sta最多只有2~3个sta。

softap+sta除了连接AP,每秒发送2.5s广播包,还有其他业务:

1.还有一个TCP Server.
这个TCP Server,是被EPS32_Client的TCP_Client连接的。整个流程是,ESP32_Client连接到ESP32_Server的AP之后,将会收到ESP32_Server的IP地址(上述的2.5s广播包即是广播ESP32_Sever的IP地址。),然后使用这个IP地址去连接ESP32_Server,建立连接之后会每隔约5秒钟发送一个几十个字节的数据包。
当TCP_Client断开后,TCP_Server将会shutdown(socket)后close(socket)并且这两个操作是在TCP返回-1之后才进行的。关闭socket后隔一小会后重新create、bind socket。TCP Server未曾报出有关内存不足的错误。

我们的业务支持任何一方断电重启后,都能够自动与另一方重新建立连接,因此我们才需要做这个循环断电的压力测试。

值得注意的是,如果从一开始就关闭了UDP广播,那么DHCP将会一直正常,不会出现本主题提出的问题。

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Sat Jun 06, 2020 8:36 am

xiehang wrote:
Fri Jun 05, 2020 6:51 am
我们的 TX data buffer 默认配置是 32 个。
从 log 判断,在出问题的点上,TX data buffer 已经用了 32 个,导致发送 DHCP offer 时申请不到 TX data 类型的 buffer。
而系统的 TX mgmt buffer 还可以使用,所以 WiFi 的连接是正常的。
你可以配置 TX data buffer 数目为 64 ,试试能不能 Fix 这个问题。
配置方法: menuconfig ---> Component config ---> WiFi ---> Max number of WiFi dynamic TX buffer
另外,“softap + sta” 除了连接 AP,和每 2.5s 发送一个 广播包,还有其他的业务吗?
连接 “softap + sta" 的 sta 有几个,它们有其他操作吗?
你好,我将TX data buffer修改为64之后问题仍然存在,以下是Log
20200604130456-Log_Server.txt
(11.17 MiB) Downloaded 955 times
问题出现于第61429行
20200604130458-Log_Client.txt
(10.71 MiB) Downloaded 1031 times
问题出现于第52316行

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Mon Jun 08, 2020 1:48 am

xiehang wrote:
Fri Jun 05, 2020 6:51 am
我们的 TX data buffer 默认配置是 32 个。
从 log 判断,在出问题的点上,TX data buffer 已经用了 32 个,导致发送 DHCP offer 时申请不到 TX data 类型的 buffer。
而系统的 TX mgmt buffer 还可以使用,所以 WiFi 的连接是正常的。
你可以配置 TX data buffer 数目为 64 ,试试能不能 Fix 这个问题。
配置方法: menuconfig ---> Component config ---> WiFi ---> Max number of WiFi dynamic TX buffer
另外,“softap + sta” 除了连接 AP,和每 2.5s 发送一个 广播包,还有其他的业务吗?
连接 “softap + sta" 的 sta 有几个,它们有其他操作吗?
你好。原本测试方案中,ESP32_Server还会去连接一个外部的路由器且路由器时65秒开10秒关循环。

我在周六的时候使ESP32_Server不再去连接那个路由器,同样会出现那个问题,在这种情况下业务是:

1.ESP32_Client通电

2.ESP32_Client连接ESP32_Server的AP

3.ESP32_Client收到ESP32_Server的UDP广播包(内容是IP地址)

4.ESP32_Client使用收到的IP地址去连接ESP32_Server的TCP_Server

5.ESP32_Client运行50秒后断电

6.EPS32_Server在TCP返回-1后,shutdown、close套接字

7.ESP32_Client断电10秒后通电,返回第1步

xiehang
Posts: 26
Joined: Mon Mar 18, 2019 8:57 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby xiehang » Mon Jun 08, 2020 2:20 am

我猜测这个可能和休眠有关,你可以关掉休眠试试吗?
开机后在 esp_wifi_connect() 之前 调用 esp_wifi_set_ps(WIFI_PS_NONE); 试试。

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Mon Jun 08, 2020 3:26 am

xiehang wrote:
Mon Jun 08, 2020 2:20 am
我猜测这个可能和休眠有关,你可以关掉休眠试试吗?
开机后在 esp_wifi_connect() 之前 调用 esp_wifi_set_ps(WIFI_PS_NONE); 试试。
可以试试,但是个人猜测内存问题不太可能是休眠引起的,如果方便的话请帮我看看内存相关的问题,因为我看不到esp_wifi_internal_tx函数的具体实现过程。 一次复现时间要花几个小时,项目已经严重落后进度。非常感谢

xiehang
Posts: 26
Joined: Mon Mar 18, 2019 8:57 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby xiehang » Mon Jun 08, 2020 3:34 am

还有一个问题,”softap + sta“ 发送 广播包,是以那个接口发送的?
目前怀疑 sta 发送 null data 给 softap 进入休眠, softap 把 广播包缓存在 TX data 列表里面,但是 sta 掉电后导致 缓存的包 一直没有释放。

XHYZN_Marshall
Posts: 35
Joined: Mon May 25, 2020 2:12 am

Re: DHCP报错ffffffff,可能是因为内存不足?[WIFI-2436]

Postby XHYZN_Marshall » Mon Jun 08, 2020 5:49 am

xiehang wrote:
Mon Jun 08, 2020 3:34 am
还有一个问题,”softap + sta“ 发送 广播包,是以那个接口发送的?
目前怀疑 sta 发送 null data 给 softap 进入休眠, softap 把 广播包缓存在 TX data 列表里面,但是 sta 掉电后导致 缓存的包 一直没有释放。
谢谢。您的回复给了我一些灵感,但我不清楚我的猜测是否正确。

我们在发送广播包的时候分为两种情况。

①如果SoftAP+STA已经连接上路由器,那么它会广播自己AP的IP地址,此时猜测应该是通过AP接口广播;以及作为STA的IP(由路由器分配),此时猜测通过STA接口广播。例如:

(18:00:00:000):广播IP地址 192.168.10.1 (自己AP的IP)
(18:00:02:500):广播IP地址 192.168.100.102 (STA的IP)
(18:00:05:000):广播IP地址 192.168.10.1 (自己AP的IP)
...

②如果SoftAP+STA没有连接路由器,那么它只会会广播自己AP的IP地址。例如:
(18:00:00:000):广播IP地址 192.168.10.1 (自己AP的IP)
(18:00:02:500):广播IP地址 192.168.10.1 (自己AP的IP)
...

UDP相关的发送代码如附件所示,请帮我检查是否存在着:想使用不同接口广播数据,仅使用第77行到第97行的代码行不?还是需要重启套接字?
ESP32_Server的UDP.c
(3.48 KiB) Downloaded 912 times

Who is online

Users browsing this forum: No registered users and 200 guests