I’m trying to create a very basic UDP client based on the example in Git FreeRTOS/FreeRTOS/tree/main/FreeRTOS-Plus/Demo/FreeRTOS_Plus_TCP_Echo_Qemu_mps2 (I tried to put a link here but the forum software “doesn’t allow new users to post links”) and this code snippet freertos . org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/Networking_Tutorial_Sending_UDP_Data.html (again sorry for the broken link)
I have code like this:
#include "FreeRTOS_IP.h"
#include "FreeRTOS_sockets.h"
/* skipped some boilerplate code here*/
static void vUDPSendUsingStandardInterface(void *pvParameters)
{
Socket_t xSocket;
struct freertos_sockaddr xDestinationAddress;
uint8_t cString[50];
uint32_t ulCount = 0UL;
const TickType_t x1000ms = 1000UL / portTICK_PERIOD_MS;
/* Send strings to port 10000 on IP address 192.168.0.50. */
xDestinationAddress.sin_address = FreeRTOS_inet_addr("192.168.0.50");
xDestinationAddress.sin_port = FreeRTOS_htons(10000);
/* Create the socket. */
xSocket = FreeRTOS_socket(FREERTOS_AF_INET4, /* Used for IPv4 UDP socket. */
/* FREERTOS_AF_INET6 can be used for IPv6 UDP socket. */
FREERTOS_SOCK_DGRAM, /*FREERTOS_SOCK_DGRAM for UDP.*/
FREERTOS_IPPROTO_UDP);
...
But when I try to compile this I get the following error:
Upon an initial review of your code, it appears to be well-structured. However, I have a minor concern regarding the include paths specified in your Makefile.
When comparing your Makefile with the FreeRTOS_Plus_TCP_Echo_Qemu_mps2 example, I noticed that the paths for FREERTOS_DIR_REL and FREERTOS_PLUS_DIR_REL seem to be different. Could you double-check if the include paths in your Makefile are correct? And sharing your complete project would be helpful for further analysis.
Great observation! In the project, all source code is in a directory named src. In this directory, I have all the .c and .h files for the project and the Makefile. I also have the whole FreeRTOS project as a submodule inside this src directory, meaning the paths relative to the Makefile should be okay.
# git submodule config
$ cat .gitmodules
[submodule "src/FreeRTOS"]
path = src/FreeRTOS
url = https://github.com/FreeRTOS/FreeRTOS.git
# what I run to get all submodules
$ git submodule update --init --recursive
I’ve would gladly submit the whole source code but I’m not able to upload any files, the forum says “Sorry, new users can not upload attachments.”.
Can you also let us know which version of FreeRTOS are you using?
sin_addr was updated to sin_address, so the FreeRTOS version will help us check if demos and FreeRTOS-Plus-TCP are following the same format.
After reviewing the details, it appears that the include file name is incorrect, which is causing an issue with properly including the API. To resolve this, we kindly request your assistance in applying the following changes:
Hi @vilhelm,
Could you try set sin_family in xDestinationAddress before calling FreeRTOS_sendto()?
Like this:
xDestinationAddress.sin_family = FREERTOS_AF_INET4; //or FREERTOS_AF_INET6 if the destination's IP is IPv6.
xDestinationAddress.sin_address.ulIP_IPv4 = FreeRTOS_inet_addr("192.168.0.50");
xDestinationAddress.sin_port = FreeRTOS_htons(10000);
memset( &xDestinationAddress, 0, sizeof( xDestinationAddress ) );
xDestinationAddress.sin_family = FREERTOS_AF_INET4; //or FREERTOS_AF_INET6 if the destination's IP is IPv6.
xDestinationAddress.sin_address.ulIP_IPv4 = FreeRTOS_inet_addr("192.168.0.50");
xDestinationAddress.sin_port = FreeRTOS_htons(10000);
xDestinationAddress.sin_len = ( uint8_t ) sizeof( xDestinationAddress );
and now I get various other messages:
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip miss using ac150001ip
0x20011d38->FreeRTOS_MatchingEndpoint 987: pxEasyFit: ARP ac150003ip -> ac150001ip
0x2000beb8->eARPProcessPacket 265: ipARP_REPLY from ac150001ip to ac150003ip end-point ac150003ip
0x2000beb8->FreeRTOS_InterfaceEndPointOnNetMask 597: FreeRTOS_FindEndPointOnNetMask[4]: No match for c0a80032ip
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip hit using ac150001ip
0x2000beb8->FreeRTOS_InterfaceEndPointOnNetMask 597: FreeRTOS_FindEndPointOnNetMask[4]: No match for c0a80032ip
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip hit using ac150001ip
I haven’t configured a dummy server on the destination IP yet, but I believe that it’s not what’s causing the issue currently.
As @aggarg mentioned if you are trying to have a client server communication, you can take reference from IPv6 demo , more detail here.
Let us know if you are facing some other issue.
… but the client seems to just seem to repeat these messages over and over:
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip miss using ac150001ip
0x20011d38->FreeRTOS_MatchingEndpoint 987: pxEasyFit: ARP ac150003ip -> ac150001ip
0x2000beb8->eARPProcessPacket 265: ipARP_REPLY from ac150001ip to ac150003ip end-point ac150003ip
0x2000beb8->FreeRTOS_InterfaceEndPointOnNetMask 597: FreeRTOS_FindEndPointOnNetMask[4]: No match for c0a80032ip
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip hit using ac150001ip
0x2000beb8->FreeRTOS_InterfaceEndPointOnNetMask 597: FreeRTOS_FindEndPointOnNetMask[4]: No match for c0a80032ip
0x2000beb8->eARPGetCacheEntryGateWay 1089: ARP c0a80032ip hit using ac150001ip
… and the UDP server is not getting any packets. The code I have is a lot more lightweight than the IPv6 demo you mentioned @moninom1, but I believe the code I have should be sufficient to send some packets over UDP?
The log above means your device received some ARP packets from network. It looks like somebody is sending something to IP 192.168.0.50 (0xc0a80032). That might not relate to the problem you’re facing directly. Could you help share the network environment you’re using? BTW, could you help check if firewall in your network path blocks the packets?
Sorry for the confusion. As you suggested, it was a firewall issue (not on the client, but on the UDP echo server)!
The network setup is rather complicated (and probably not how you’re supposed to do this for FreeRTOS). I’ve attached a figure summarizing how I compile and run FreeRTOS with my code.
So basically there is a TUN/TAP tunnel between the QEMU Arm Emulator and the Docker container, allowing the QEMU VM to access the network via Docker and via the host OS.
Thanks a lot for the help with everything, really appreciated it!
