FreeRTOS+TCP: payload notification to Application

Libraries
1

Hello community,

I am new to FreeRTOS and also +TCP. I have succeeded in porting for transmission messages from Application to ETH PHY by using FreeRTOS+TCP.

currently, I am working on receving path and have some doubts :slight_smile:

  1. How to send/notify the received IP package and UDP/TCP/ARP payload from FreeRTOS+TCP to Application.
  2. Can I change TTL during runtime that depends on which state/purpose of each Application ?

Thanks for your attention and have a nice day!
TA.

2

Hi @CugTATr,
Welcome to FreeRTOS community!

FreeRTOS-Plus-TCP supports FreeRTOS_select() for users to get notifications. Or you can refer to ipconfigUSE_CALLBACKS, which provides callback approaches for applications.

Unfortunately, FreeRTOS-Plus-TCP doesn’t support TTL runtime configurations. For now, it uses build time comfigurations. Refer to TCP_IP_Configuration and search for “TIME_TO_LIVE”.

Thank you.

2 Likes
3

You wrote:

  1. How to send/notify the received IP package and UDP/TCP/ARP payload from FreeRTOS+TCP to Application.

Have you used another TCP/IP stack already? FreeRTOS+TCP is mostly compatible, except the that API names start with FreeRTOS_, suck as FreeRTOS_sendto().

There are loads of examples, in which a “payload” is being sent or received.

You also mention ARP: that protocol is only used by the IP-task. Users rarely have to worry about that.

1 Like
4

Thanks for your feedback! I think ipconfigUSE_CALLBACKS is what I am looking for.

5

Thanks for your reply! I will take a look at your given link
At first when looking at [Hook/Callback API](https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/API/eApplicationProcessCustomFrameHook.html) I did not find a callback for dedicated UDP or TCP.

Honestly, this is my first time working closely with TCP/IP stack. I have a little bit of experience at user level but very abstract layer (Autosar standard) so lots of things need to be investigated and learned. Thanks for your help!

6

Welcome!

And you can also take a look on documentations like Receiving Data Using a TCP Socket or FreeRTOS_Plus_TCP_Echo_Posix demo code.

7

eApplicationProcessCustomFrameHook()

This call-back is at a very low level. It can not be used for normal frames like IP or ARP.

I did not find a callback for dedicated UDP or TCP.

There are protocol specific application hooks described in this long post.

Hereabove, @ActoryOu gave you good references that explain how sockets are normally used.

As a client: socket(), bind(), connect(), send(), recv(), shutdown(), closesocket().

Or as a server: socket(), bind(), listen(), accept().

I would recommend using these primitives first. A second step would be to use callbacks, or “application hooks”.

1 Like
8

Appreciate your detailed feedback!

May I ask a question regarding destination IP? How does the Application know the destination when sending either UDP/TCP ?

Background: before integrating FreeRTOS+TCP, we had done a simple application that handles ARP/UDP, the application communicates directly to ETH PHY to transmit/receive messages. We identified destination (IP, MAC) by collecting ARP data. I saw that FreeRTOS+TCP requires IP (FreeRTOS_sendto, FreeRTOS_send) when sending message.

9

There are two common methods.

First, you must know the destination IP address and hardcode it into the program before compiling.
Second, DNS(domain name server) service provide ability to query IP address via string with DNS server. For example, I can query IP address of www.google.com by nslookup on windows powershell.

PS C:\> nslookup www.google.com
Server:  UnKnown
Address:  xxxxx (my DNS server address)

Non-authoritative answer:
Name: forcesafesearch.google.com
Addresses:  2001:4860:4802:32::78
            216.239.38.120
Aliases:  www.google.com

In FreeRTOS-Plus-TCP, we provide FreeRTOS_gethostbyname() for user to execute DNS query.

Thank you.

1 Like
10

Thanks for your quick feedback!

I think both of your methods would not help my case.

My board will run as a server and will not know any clients to talk with (of course my board will have a fixed IP/Subnet). Hardcode destination is not possible. Besides, since the board is a standalone unit and will respond a data upon what the client requests, no further DNS query will be executed.

That is the reason why in the previous project, I was using ARP which requests from client (client should know the server’s IP) to collect destination IP/MAC (of client) before sending UDP message.

Thank you!

11

Hi @CugTATr

For demo purpose we generally communicate between the board which can run as server and PC to which the device is connected can work as client & vice versa
Here is an example of a demo doing this : IPv6 Demo

Can you please let us know what is your use case here when you say you are not aware of the destination IP address?

12

My board/controller is playing the role of server with a fixed IP address. The PCs on the network (with varied ranges and un-detectable IPs before compiling) will communicate with board/controller through UDP for query data. Only one PC communicates at a time . From previous project, we got destination IP/MAC address by collecting from ARP which was sent from PC before receiving query from client PC.

I hope that the explanation is clear for our use case.
Thanks for your help!

13

Ok, let me rephrase what you are writing to make sure we are in sync:

  1. All of what happens in the future steps requires an unrouted single-segment LAN.
  2. Clients with possibly varying IP addresses know the server’s static IP address and send UDP requests to that server.
  3. The server must respond to the clients via UDP but may have to deal with moving targets (ie clients with changing IP addresses). Note that if that was NOT the case (ie the server responses can rely on constant IP addresses of each client at least for a request-response cycle, you can simply decode the client’s IP address from the request packet and use it as the destination of the response packet (preferred and standard solution).
  4. In order to identify the client, your non-FreeRTOS server retrieves the IP address/MAC mapping using nmap or something similar and subsequentially uses that MAC address to determine the current IP address of the client to respond to.

Correct? If yes, no, I do not think you can use that strategy on FreeRTOS +TCP.

1 Like
14
  1. Yes.
  2. Yes.
  3. Almost yes. The IP address of the client will be constant at least for a request/response cycle. Additional information is that PORT is fixed on both the server and the clients.
  4. Non-FreeRTOS project used ARP for decoding of IP and MAC of the clients before starting request/response.

Sorry for my bad English and unclear description.

15

After reading the whole text, I miss the concept of UDP broadcasting. Your board can address all devices on the subnet, without knowing any individual IP address.

You can bind a UDP socket to the address 0.0.0.0 and a fixed port, say 10501. Then you can send packets to a broadcast address, either like 192.168.1.255*, or 255.255.255.255. Now also the other devices can send a broadcast packet to 255.255.255.255 port 10500.

*The actual broadcast address depends on the network address and mask, it can also be 192.168.1.255

Once a broadcast packet is responded, you can use the unicast address of the peer to have a private conversation.

ARP: it is a very original solution to use ARP for device detection, but there are easier and more “compatible” ways. UDP broadcast is one of them.

Yet another way is using mDNS or LLMNR, which is also supported in both directions on FreeRTOS+TCP. Those protocols are based on UDP/broadcast as well.

For instance, I call my board “STM32F_02” and I can do:

C:\Users\Hein>ping -4 STM32F_02

Pinging STM32F_02 [192.168.2.11] with 32 bytes of data:
Reply from 192.168.2.11: bytes=32 time<1ms TTL=128
Reply from 192.168.2.11: bytes=32 time<1ms TTL=128
1 Like