This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Socket API "send" hangs when sending multiple TCP messages

Hi, 

   I am developing an application that requires communication between two nrf52840-based devices. There is a scenario in my application where the devices needs to exchange multiple TCP packets, however after transmitting nearly 50 messages, send API hangs. The inter-message transmission interval is 70-200 ms. I am using TCP over IEEE 802.15.4 with POSIX names enabled. My application's message size 14-byte. I would be really thankful for your help. 

Best regards,

Omer

Parents
  • Hello, Omer!

    Are you able to provide any logs from the devices? I would also like information about which code your samples are based on, and whether you are using the nRF Connect SDK or the nRF5 SDK.

    Best regards,
    Carl Richard

  • Hi Carl, 

        Regarding logs - I am obtaining information by using printk and displaying the information on terminal. I am relatively new to Zephyr, therefore I do not know whether Zephyr stores some log files. If so, I would really appreciate if you could also tell me where those log files are stored. 

       Code Sample: I built my code using the socket client server example available at zephyr/samples/net/sockets. 

       I am using nRf Connect SDK. 

    Best regards,

    Omer

  • Thanks for the logs! I couldn't manage to find any obvious problems in them. Could you share the applications here so that I can have a look?

    This could possible be an overflow issue. Does it happen after the same number of messages every time?

    Best regards,
    Carl Richard

  • Thanks for your reply. Unfortunately, I will not be able to share my application code here due to restrictions.

    The problem nearly starts to happen after the same number of messages, but the number is not exactly the same very time. Can I suggest you to please use net/sockets echo client server example and transmit messages in an loop, you may reproduce the same problem?

    Best regards,

    Omer

  • Hi Carl, 

       I have tested echo-client/server example by transmitting data packets in a loop. I can now confirm that the blocking behavior is reproduced in the echo-client/server example as well. I have attached the source files and proj.conf file. Please note that I am using nRF Connect SDK Version 1.3.0, however I have also tested on over nRF Connect Version 1.5.0.  6472.prj.conf

    #include <zephyr.h>
    #include <errno.h>
    #include <stdio.h>
    
    #include <net/socket.h>
    #include <linker/sections.h>
    #include <shell/shell.h>
    #include <net/net_core.h>
    
    #define MY_PORT 4242
    #define PEER_PORT 4242
    
    void main()
    {
        printk("Starting the Process ... \n") ; 
    	struct sockaddr_in6 addr6, addr_peer;
    	int sock_id = 0 ; 
    	int ret = 0 ;  
    	char msg[] = "HELLO\n" ; 
        char msg1[100] ; 
    	
    	memset(&addr6, 0, sizeof(addr6));
    	addr6.sin6_family = AF_INET6;
    	addr6.sin6_port = htons(MY_PORT);
    	inet_pton(AF_INET6, CONFIG_NET_CONFIG_MY_IPV6_ADDR,
    			  &addr6.sin6_addr);
    	sock_id = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
    	if(sock_id == -1)
    	{
    		printk("Error in creating socket \n") ; 
    		return ; 
    	}
    	
    	ret = bind(sock_id, (struct sockaddr *) &addr6, sizeof(addr6)) ; 
    	
    	if(ret < 0)
    	{
    			printk("Error in Binding the Socket \n") ; 
    			return ; 
    	}
    	while(true)
    	{
    		(void) memset(&addr_peer, 0, sizeof(addr_peer)); 
    		addr_peer.sin6_family = AF_INET6;
    		addr_peer.sin6_port = htons(PEER_PORT);
    		inet_pton(AF_INET6, CONFIG_NET_CONFIG_PEER_IPV6_ADDR,
    			  &addr_peer.sin6_addr);
            ret = sendto(sock_id, msg, sizeof(msg), 0, (struct sockaddr *)&addr_peer, sizeof(addr_peer)) ;
    		if(ret < 0)
    		{
    			printk("Error in Transmitting the Message \n"); 
    			return ; 
    		}
    		else
    		{
    			printk("The message has been transmitted \n") ;
    			ret = recv(sock_id, (void*) msg1, sizeof(msg1), 0) ;
    			printk("%s\n" ,msg) ; 
    			/*stop_time = k_cycle_get_32();
    			cycles_spent = stop_time - start_time;
    			nanoseconds_spent = k_cyc_to_ns_ceil32(cycles_spent) ; //SYS_CLOCK_HW_CYCLES_TO_NS(cycles_spent);*/
    		}
    		memset(msg1, sizeof(msg1), 0) ; 
    		k_msleep(1000) ;
    	}
    	return ; 
    }
    #include <zephyr.h>
    #include <errno.h>
    #include <stdio.h>
    
    #include <net/socket.h>
    #include <linker/sections.h>
    #include <shell/shell.h>
    #include <net/net_core.h>
    
    #define MY_PORT 4242
    #define PEER_PORT 4242
    
    void main()
    {
    	struct sockaddr_in6 addr6, addr_peer;
    	int sock_id = 0 ; 
    	int ret = 0 ;  
    	char msg[100] ; 
    
    	(void)memset(&addr6, 0, sizeof(addr6));
    	addr6.sin6_family = AF_INET6;
    	addr6.sin6_port = htons(MY_PORT);
    	inet_pton(AF_INET6, CONFIG_NET_CONFIG_MY_IPV6_ADDR,
    			  &addr6.sin6_addr);
    	sock_id = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
    	if(sock_id == -1)
    	{
    		printk("Error in creating socket \n") ; 
    		return ; 
    	}
    	
    	ret = bind(sock_id, (struct sockaddr *) &addr6, sizeof(addr6)) ;
            addr_peer.sin6_family = AF_INET6;
            addr_peer.sin6_port = htons(PEER_PORT);
            inet_pton(AF_INET6, CONFIG_NET_CONFIG_PEER_IPV6_ADDR,
                      &addr_peer.sin6_addr);
    	
    	while(true)
    	{ 
    		/* Continously send message to a server after every 5 seconds */
    		ret = recv(sock_id, (void*) msg, sizeof(msg), 0) ; 
    		if(ret < 0)
    		{
    			printk("Error in Receiving a Message \n"); 
    			return ; 
    		}
    		else
    		{
    			printk("%s\n", msg) ; 
    			ret = sendto(sock_id, msg, sizeof(msg), 0, (struct sockaddr *)&addr_peer, sizeof(addr_peer)) ;
    			if(ret < 0 )
    			{
    					printk("Error in transmitting message \n") ; 
    			}
    		}
    	}
    	close(sock_id) ; 
    	return ; 
    }
     

  • Hello again, Omer!

    Apologies for the delayed answer and thanks for the additional information! It seems like this might be a bug on our side. I'll report this internally and will get back to you soon. 

    Best regards,
    Carl Richard

Reply Children
No Data
Related