I am using the SimpleTCPEchoServer.c present in FreeRTOS_Plus_TCP_Echo_Posix, made below modifications to make the application work as server :
a) Initialize the network same as done for client by calling prvMiscInitialisation() & FreeRTOS_IPInit(ucIPAddress, ucNetMask, ucGatewayAddress, ucDNSServerAddress, ucMACAddress);
b) Start the scheduler
c) In main.c invoke vStartSimpleTCPServerTasks( mainECHO_SERVER_TASK_STACK_SIZE, mainECHO_SERVER_TASK_PRIORITY ); from void vApplicationDaemonTaskStartupHook( void )
d) In SimpleTCPEchoServer.c changed the line xBindAddress.sin_port = FreeRTOS_htons( xBindAddress.sin_port ); to xBindAddress.sin_port = FreeRTOS_htons(9292); as I want to listen on port 9292 because previously it showed Socket 7 → [0.0.0.0]:0 State eCLOSED->eTCP_LISTEN. Also adding prints after FreeRTOS_listen( xListeningSocket, xBacklog ); it shows Listening on 0.0.0.0:19492.
What does [0.0.0.0]:0 or [0.0.0.0]:19492 mean does it create any internal port for binding purpose?
e) ipconfigUSE_DHCP as 0 as it is server do did not want to enable DHCP server.
with above changes when execute the application I see below prints :
Trace started.
The trace will be dumped to disk if a call to configASSERT() fails.
The trace will be dumped to disk if Enter is hit.
Seed for randomiser: 1750842071
Random numbers: 00001481 00002DEF 000069EE 00003FF9
FreeRTOS_IPInit
FreeRTOS_AddEndPoint: MAC: 44-41 IPv4: a00020fip
prvIPTask started
FreeRTOS_bind: requested port 9292 and assigned port is 9292
Socket 9292 → [0.0.0.0]:0 State eCLOSED->eTCP_LISTEN
Listening on 0.0.0.0:19492
xNetworkInterfaceOutput: 0x55d86b61be80:0x7f101001b70e
I tried to also execute a client application on same system but it is not able to connect with the server. Can you please point is anything missing at server side or what shall be done to test between Server & Client.
Though the SimpleTCPEchoServer.c file is present as part of the demo, the server tasks need to be started explicitly when the network is up.
You can take a look at the vApplicationIPNetworkEventHook_Multi in the FreeRTOS_Plus_TCP_Minimal_Windows_Simulator demo here to see how it’s done. In the case of posix demo this function is present in the SimpleTCPEchoServer.c, so that function can be invoked from the vApplicationIPNetworkEventHook_Multi of posix demo. This is similar to how the TCP demo client task is started once the network is up in the posix demo. [refer]
@tony-josi-aws
I am invoking the server tasks from main.c.
Please find attached patch for the server tasks (Few of the prints added in SimpleTCPEchoServer.c, main.c are made for debug purpose) . freertos_tcp_posix_server.patch (11.9 KB)
At client side I just modified FreeRTOSConfig.h for configECHO_SERVER_ADDR as “192.168.1.111” , configIP_ADDR0-ADDR as “192.168.1.111” & TCPEchoClient_SingleTasks.c echoECHO_PORT as 9292. Both Client and Server are running on same machine.
One thing to note is that the posix demo uses the FreeRTOS+TCP’s libslirp virtual network interface, and libslirp works by creating a NAT’d virtual network. This means the guest (posix demo) has a private IP address within a virtual network. The host (PC where you run the demo) acts as a router/NAT device, translating the guest’s private IP to the host’s public IP when communicating with the outside world. When you run the echo server demo, the client applications running outside of the NAT’d network won’t be able to reach the guest by default. Each separate instance of posix demo runs on its own virtual network even though the assigned address/libslirp DHCP provided address seems to be in the same subnet.
Although currently not present in the implementation, it should be possible to modify the libslirp network interface implementation to add port forwarding to the port at which the echo server is running (slirp_add_hostfwd), so that traffic arriving at a specific address and port on the host is forwarded to a specific address and port on the guest; by default, that is not implemented.
I have tested the concept with the following modifications:
Libslirp port forwarding - libslirp_network_interface.patch (2.1 KB) This patch needs to be applied on the FreeRTOS+TCP submodule for the server demo application.
TCP client can now connect to the host PC’s IP address and host forwarded port as the server’s IP and port. (Example patch to match the network interface modification patch - tcp_client.patch (1.5 KB))
@tony-josi-aws
Thank you for your response. With the patch ( libslirp_network_interface.patch) provided I am able to connect Client with Server both running on same machine.
At the server side we should be able to see the same text when we tried to connect posix_demo_client application with “sudo nc -l -p” or that needs to be implemented in SimpleTCPEchoServer.c? Attaching the server & client side logs for reference (client_logs.zip, server_logs.zip). client_logs.zip (1.7 KB) server_logs.zip (780 Bytes)
Also, I tried to print the data received after FreeRTOS_recv but nothing gets printed. So I checked FreeRTOS_accept and it seems it is stuck at accept.
Yes, currently the default implementation doesn’t log the received contents in the server implementation. You can use a thread-safe logging call in the prvServerConnectionInstance function, probably after the lBytes = FreeRTOS_recv( xConnectedSocket, pucRxBuffer, ipconfigTCP_MSS, 0 ); line, logging the contents of pucRxBuffer.
In the prvEchoClientTask, lMaxLoopCount is set as 1, so there will be only one iteration of sending and receiving data per each client connection.
If its still not working share how you have added logging inside the prvServerConnectionInstance
@tony-josi-aws It was observed that the server application used to get stuck at xConnectedSocket = FreeRTOS_accept( xListeningSocket, &xClient, &xSize );. So, I changed the static const TickType_t xReceiveTimeOut = portMAX_DELAY; to static const TickType_t xReceiveTimeOut = pdMS_TO_TICKS(4000); and then was able to see the debug prints kept in prvServerConnectionInstance. But I still see prints “Received 4294967274 bytes” at server side even though the client application sends data in some specific bytes. So, I believe the issue of application stuck at accept got resolved due to the timeout factor but still the server is not receiving the data correctly from client. Please correct me if my changes are wrong. Sharing the patch of SimpleTCPEchoServer.c and the logs for server. I also created a tap interface to connect between client and server on same machine but the issue still persists of successful connection. Also, is there any more configuration to be done at any side (ex: FreeRTOSConfig.h etc)? echo_server_logs_custom_changes.zip (870 Bytes) echo_server_custom_changes.patch (4.8 KB)
@tony-josi-aws It seems I am still observing the connection issue between Client and Server. I tried the server_logging.patch where I am using the port no as the one where the packets will be forwarded from 5050 → 50 based on the ( libslirp_network_interface.patch). Below changes are done for Server Application -
a) Applied patch libslirp_network_interface.patch)
b) Modified xReceiveTimeOut in prvConnectionListeningTask() from portMAX_DELAY to pdMS_TO_TICKS(4000) as it was observed that application was stuck in FreeRTOS_accept(). Currently it is disabled to it is stuck at printf(“Before FreeRTOS_accept\n”); as per my (echo_server_custom_changes.patch).
c) Tried to use physical eno1 interface with IP assigned as 192.168.1.111. In Client FreeRTOSConfig.h configured the Server IP address & config IP address as 192.168.1.111, configNETWORK_INTERFACE_TO_USE as the number allocated for eno1 and echoECHO_PORT
as 5050. At server side, FreeRTOSConfig.h is same as client one and FreeRTOSIPConfig.h has ipconfigIPv4_BACKWARD_COMPATIBLE = 1 & ipconfigUSE_DHCP = 0.
d) Created TAP interface and instead of using 192.168.1.111 and eno1 interface replaced as 192.168.42.1 as server IP address and 192.168.42.2 as Client IP address.
With these modifications still my server application is stuck at FreeRTOS_accept and does not match the logs which you shared. Can you please explain your setup configuration? Is TAP interface required?
No, my setup is both server and client runs with DHCP enabled; server has the patch libslirp_network_interface.patch, client is connecting to the host IP address (your PC’s IP address) and the forwarded port which is 5050 in the patch.
I don’t have this change. FreeRTOS_accept is supposed to block until there is an incoming TCP connection on the xListeningSocket, once it gets a connection, it again blocks for the next connection.
@tony-josi-aws Understood, so you mean apart from the xReceiveTimeOut all changes are same in your setup also? Is it possible for you to share your FreeRTOSConfig.h for server and client?
@tony-josi-aws Based on this input I was able to validate the communication between Client and Server. My observation has been there is no role of FreeRTOSConfig.h at server side when making changes for port and IP directly in SimpleTCPEchoServer.c
Thanks for your support.
Thanks I recheck everything and applied your patches, Now I am able to Connect Sever-Client and log signals also,
Server Side Logs-
Trace started.
The trace will be dumped to disk if a call to configASSERT() fails.
The trace will be dumped to disk if Enter is hit.
Starting echo server demo
Seed for randomiser: 1751380884
Random numbers: 000046F0 00001985 00000AF9 00005835
FreeRTOS_IPInit
FreeRTOS_AddEndPoint: MAC: 44-41 IPv4: ac13c325ip
vTaskStartScheduler
vIPSetDHCP_RATimerEnableState: Off
prvCloseDHCPSocket[44-41]: closed, user count 0
TCP port forwarding 0.0.0.0:5050 → 10.0.2.15:50 added successfully.
vDHCPProcessEndPoint: enter 0
DHCP-socket[44-41]: DHCP Socket Create
prvCreateDHCPSocket[44-41]: open, user count 1
prvInitialiseDHCP: start after 250 ticks
vDHCP_RATimerReload: 250
vDHCPProcessEndPoint: exit 1
vDHCPProcessEndPoint: enter 1
vDHCPProcess: discover
vDHCPProcessEndPoint: exit 2
xNetworkInterfaceOutput: 0x5701df7a4640:0x7ceac001c31e
vDHCPProcessEndPoint: enter 2
vDHCPProcess: offer a00020fip for MAC address 44-41
vDHCPProcess: reply a00020fip
vDHCPProcessEndPoint: exit 3
xNetworkInterfaceOutput: 0x5701df7a46a0:0x7ceac001c31e
vDHCPProcessEndPoint: enter 3
vDHCPProcess: offer a00020fip for MAC address 44-41
vDHCPProcess: acked a00020fip
IP Address: 10.0.2.15
Subnet Mask: 255.255.255.0
Gateway Address: 10.0.2.2
DNS Server Address: 10.0.2.3
prvCloseDHCPSocket[44-41]: closed, user count 0
vDHCP_RATimerReload: 43200000
vDHCPProcessEndPoint: exit 5
xNetworkInterfaceOutput: 0x5701df7a4760:0x7ceac001b7ae
Socket 50 → [0.0.0.0]:0 State eCLOSED->eTCP_LISTEN
xNetworkInterfaceOutput: 0x5701df7a4820:0x7ceac001b7ae
pxEasyFit: ARP a00020fip → a000202ip
ipARP_REPLY from a000202ip to a00020fip end-point a00020fip
Gain: Socket 50 now has 1 / 20 child me: 0x7ceac001c5f0 parent: 0x7ceaa0000b90 peer: 0x7ceac001c5f0
prvSocketSetMSS: 1460 bytes for a000202ip port 36064
Socket 50 → [10.0.2.2]:36064 State eCLOSED->eSYN_FIRST
prvWinScaleFactor: uxRxWinSize 2 MSS 1460 Factor 0
Socket 50 → [10.0.2.2]:36064 State eSYN_FIRST->eSYN_RECEIVED
xNetworkInterfaceOutput: 0x5701df7a47c0:0x7ceaa8000b9e
TCP: passive 50 => 2.2.0.10 port 36064 set ESTAB (scaling 0)
Socket 50 → [10.0.2.2]:36064 State eSYN_RECEIVED->eESTABLISHED
prvAcceptWaitClient: client 0x7ceac001c5f0 parent 0x7ceaa0000b90
xNetworkInterfaceOutput: 0x5701df7a4940:0x7ceaa8000b9e
==>>>>>>>>>>>>>>>RX LEN : 25
==>>>>>>>>>>>>>>>RX DATA: Hello from Ubuntu Client!
xNetworkInterfaceOutput: 0x5701df7a49a0:0x7ceac00235ee
Socket 50 → [10.0.2.2]:36064 State eESTABLISHED->eLAST_ACK
xNetworkInterfaceOutput: 0x5701df7a4a00:0x7ceaa8000b9e
vTCPStateChange: Closing (Queued 0, Accept 0 Reuse 0)
vTCPStateChange: me 0x7ceac001c5f0 parent 0x7ceac001c5f0 peer (nil) clear 0
vTCPStateChange: xHasCleared = 0
Socket 50 → [10.0.2.2]:36064 State eLAST_ACK->eCLOSE_WAIT
Client Side Logs -
Connected to FreeRTOS server at 127.0.0.1:5050
Message sent: Hello from Ubuntu Client!
Echo received: Hello from Ubuntu Client!