Network stack not recovering form Filled Buffers.

RE: Network stack not recovering form Filled Buffers.

Amanda Hsieh — Tue, 15 Oct 2024 16:14:09 GMT

Hi,

There’s no error handling for zsock_recvfrom () , one possibility is that the socket starts to report errors for whatever reason and is stuck in an error loop.

The logic in the stack is pretty simple, if the received packet matches one of the open ports, it’s queued for the target net_context/socket, otherwise, it’s dropped. Some suggestions I could have are:

check net conn command to see if there are no stray ports open accumulating packets,
or in the customer’s receive thread, set a socket timeout for receive (enable CONFIG_ET_CONTEXT_RCVTIMEO and set setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, ...) on a socket), to see, if the zsock_recv() function reports no data (-EAGAIN returned via errno) or whether it’s some higher-priority thread busy-looping for instance, preventing the receiver thread from running.

But generally, I’m afraid it’d be really hard to help much here, I’ve heard of no cases of network packets being not freed which were not application errors. If we had a bug in the stack somewhere, I’m pretty sure it’d be reported on upstream Zephyr already. Debugging issues like this require a holistic approach, ideally with a debugger involved, I’m not able to give clear and certain answers based on a few code snippets only.

-Amanda H.

RE: Network stack not recovering form Filled Buffers.

StijnGerbrandaKadex — Mon, 14 Oct 2024 07:29:53 GMT

Hi, sorry for the late response.

I feel like the issue is something else. I only open one socket that I keep open. After receiving from the network stack with zsock_recvfrom, I send the data into a FIFO buffer. This buffer does not seem to fill up, and the receiving thread keeps running. As far as I can see, it gets stuck on zsock_recvfrom.

Even if the buffer were to fill, the other threads should be able to empty it over time, and some messages should be processed, right? I have tested this with multiple priority settings, and the results seem the same.

I need to recover from a filled buffer and prevent it from filling up and being unable to empty.

The Receive Thread:

	while (true /*ret >= 0*/) 
	{
		LOG_INF("\x1B[0;35m" "receiving" "\x1b[0m");
		ret = zsock_recvfrom(socketVal, (void*)(&(recv_data.buffer[0])), sizeof(recv_data.buffer), 0x00, (struct sockaddr *)(&(recv_data.sender_addr)), (socklen_t *)(&(recv_data.sender_addr_len)));
		if (ret > 0) 
		{	
			// NET_INFO("UDP |Count: %d Data received: %s, Buffer Size: %u", Count, recv_data.buffer, recv_data.buffer_size);
			// LOG_INF("UDP "/*|Count: %d Data received: ", Count%s", , recv_data.buffer*/);
			Count++;
			recv_data.buffer_size = ret;
			if (recv_data.buffer_size >= sizeof(recv_data.buffer))
			{
				LOG_ERR("Wrong buffer size!");
				k_sleep(K_SECONDS(1));
			}

			Message message;

			ret = handleEthernetInput(&(recv_data.buffer[0]), recv_data.buffer_size, &message);
			if (ret != 0)
			{
				LOG_ERR("Protocol not correct");
				return;
			}
		}
	}

RE: Network stack not recovering form Filled Buffers.

Amanda Hsieh — Wed, 02 Oct 2024 17:23:36 GMT

Hi,

There’s nothing special about the driver code you shared, it looks ok. The only explanation I can think of is that you are confused about:

[quote user=""]And the network stack function zsock_recvfrom does not output any messages.[/quote]

This looks like a prefect example of data being stacked up at the application layer, with the application not consuming it. But it’s hard to say for sure, w/o seeing the full picture (full app in this case). Perhaps you have some dangling socket left open which accumulates data over time.

Regards,
Amanda H.