Subscriptions, why can't these two nodes see each other? (CON-1110) #891
Comments
github-actions
bot
changed the title
|
I am able to successfully establish a subscription between two ESP based nodes. So this is a problem talking to a Linux based node? I don't know, I was just using the Linux node for testing, actual target is ESP based. |
|
Looks like the error occurs when the ESP32 is sending the Sigma3 message to the Linux themostat and the error code is 0x3000001 (LwIP error ERR_MEM). Since the heap is enough in the log, I guess that the Wi-Fi TX buffer might be not enough. Could you try to increase the Wi-Fi Dynamic TX buffer in menuconfig? |
|
That's my SDK config. I have 16 static TX buffers. Note that if I point the same node at an ESP based device it works. |
|
May you add some logs at wlanif.c:109 so that we can know whether the lack of Wi-Fi TX buffer causes this issue? Note that the 16 TX buffers could be not enough for Matter since Matter uses UDP and it may deliver frames faster than WiFi layer can transmit. If you are worry about the memory usage, you could switch to dynamic TX buffer so that you can have more buffer number. |
|
How do you do dynamic TX buffers in a system with PSRAM? Enabling PSRAM disables the dynamic TX option in menuconfig. Shouldn't chip throttle when wifi runs out of TX buffers? It can't work under the assumption that it can put as many UDP packets into wifi as it wants. Of course, today when I rebuilt everything, it initially works against Linux and fails in a different place. Did not hit this.... |
|
This is not the first time I have seen behavior like this. When testing groups sometimes I will lose connectivity to various nodes until I reboot them. You get the same failure -- out of packet buffers. I think this is because something happened down in a wifi stack somewhere and the nodes stopped seeing each other. |
|
Maybe when there is wifi interference TX buffers are being leaked? The failed transmits are not getting put back into the pool? |
You can select
Yes, for Matter over UDP, the failure -- out of packet buffers is more likely to be encountered when the network is complicated, as the Matter will post more packets to Wi-Fi TX radio. As you see in the log, we will not treat this failure as a critical issue since the Matter has re-transfer mechanism. I guess this might be improved when TCP is introduced to Matter in Matter1.4(or later).
I don't think so. If there are some buffers leaked, the usable buffers will be less and less and we will have no buffer for Wi-Fi TX. At least we didn't see the situation when the chip has no buffer to use anymore. |
|
I am recompiled and running with dynamic TX buffers limit 32. I used to not be able to do that but I have been adding CAP mallocs all over. Looking at my debug output there is obviously still some stuff I can move into PSRAM. These allocs are in code I didn't write, I have been systematically forcing all of my allocs into PSRAM. So is there a magic tool which can track these allocations and tell me which lines in the code are doing the worst of it? I have turned on heap tracking before but it generates many thousands of events most of which are just noise (tiny allocs and frees). I have plenty of PSRAM free to use for heap tracking. What I'd like to do is turn on this magic tracking and then make a call which would tell me the line number which made every internal alloc over 100 bytes. I don't care about tracking all of the alloc/frees, I just want to do a snapshot in time and know who made made every internal alloc over 100 bytes and to filter out the PSRAM ones of which there are thousands. What about the CHIP task? 54,272 bytes there which I am sure could go into PSRAM. |
My commissioner node can talk to both nodes, why can't they see each other?
esp-matter node
target node, linux running the themostat example
The text was updated successfully, but these errors were encountered: