Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 25, 2017

Hello,

This is my first post on forum so first of all I want to say "Thank You" for the great job that you are doing with the FreeRTOS operating system. I started to use it due to the available features and excellent documentation provided.

I have a problem with server implementation from SimpleTCPEchoServer.c - in few words, does not respond to ping (and also arp) requests but even so at each 30 seconds it sends a "Gratuitos ARP" over the network.

Here are the details: FreeRTOS v9.0 FreeRTOS Plus TCP version 160919 Custom hardware based on ARM Cortex M7 (Atmel ATSAME70Q21) LogiLink USB to Ethernet adapter connected to PC - IP address 192.168.0.3 No DHCP (static IP - 192.168.0.2) No DNS

The initial software application contained FreeRTOS (without TCP/ IP Stack) and Atmel's Ethernet driver. This version responded to arp and ping requests thus I can exclude any hardware or network configuration issues. Then I added +TCP and the SimpleTCPEchoServer.c but no answers from board.

What can be wrong?

Regards, Andrei


Simple TCP Echo server - does not respond to ping

Posted by rtel on January 25, 2017

The first thing to do will be to make sure the MAC is receiving interrupts for incoming packets, then if it is, follow the packet's path into the the stack to see how far it gets.

First though, I'm curious about the following from your post:

The initial software application contained FreeRTOS (without TCP/ IP Stack) and Atmel's Ethernet driver. This version responded to arp and ping requests thus I can exclude any hardware or network configuration issues.

If it didn't contain the TCP/IP stack, but did respond to ARP and Ping, what was responding to ARP and Ping. Was there a different stack in use that you removed? Or is there something in the hardware itself responding?


Simple TCP Echo server - does not respond to ping

Posted by heinbali01 on January 25, 2017

And in addition to Richards questions:

Sometimes the simplest things are the most complex. As far as I know we never provided a +TCP driver for ATSAME70Q21. Where did you get your driver? There may be many causes. Like Richard asks, do you ever get a DMA reception (RX) interrupt? Did you allow for broadcast messages in your EMAC?


Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 25, 2017

Yes, MAC is receiving interrupts for incoming packets so I will have to check the path.

Atmel provided a mini TCP/ IP Stack capable to respond to ARP and Ping requests in order to test their MAC driver implementation. This mini TCP/ IP Stack and Ethernet drivers were implemented by Atmel for ATSAM4E and KSZ8051.

I updated the code to properly function with custom hardware build around ATSAM7EQ21 uC and KSZ8041TL Ethernet driver -> board responded to ARP and Ping requests (continuously tested for few hours without failures).

Broadcast messages are allowed by EMAC.

FreeRTOSIPInit() called before starting the scheduler; prvIPTask priority = 3 IPHook function -> network up -> create server task with priority = 1


Simple TCP Echo server - does not respond to ping

Posted by heinbali01 on January 26, 2017

Hi Andrei, I'm afraid I can't help you much more on this. Do you see that it attempts to send packets back? If not, you'll really have to follow the entire path from reception to answering. I'm not familiar with the mini IP-stack developed by Atmel. FreeRTOS has FreeRTOS+TCP, which has a driver and demo project for SAM4E. Unfortunately I don't have a ATSAM7EQ21 for testing.


Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 26, 2017

Hello Hein, I think I was not so clear in explanations. Currently I am using the FreeRTOS+TCP with driver and demo project based on SAM4E but with some small updates necessary for ATSAME70Q21.

The mini TCP/ IP Stack provided by Atmel I initially use it just to test the EMAC driver, network configuration and possible hardware issues. After being confident that all things were well functioning I replaced the mini TCP/ IP Stack with FreeRTOS+TCP. Now comes my problem because the board does not respond to ARP and Ping requests.

It seems that TCP/ IP packets are not sent to IP Task due to pxNextNetworkBufferDescriptor which is NULL (prvEMACRxPoll function). Please have a look below.

	if( pxNextNetworkBufferDescriptor != NULL )
	{
		/* Point pucUseBuffer to the buffer pointed to by the descriptor. */
		pucUseBuffer = ( unsigned char* ) ( pxNextNetworkBufferDescriptor->pucEthernetBuffer - ipconfigPACKET_FILLER_SIZE );
	}

** else { /* As long as pxNextNetworkBufferDescriptor is NULL, the incoming messages will be flushed and ignored. */ pucUseBuffer = NULL; }**

I am trying to figure out why this is happening.


Simple TCP Echo server - does not respond to ping

Posted by rtel on January 26, 2017

Which buffer allocation file are you using? BufferAllocation1.c or BufferAllocation2.c?


Simple TCP Echo server - does not respond to ping

Posted by heinbali01 on January 26, 2017

the board does not respond to ARP and Ping requests

Before being able to PING, an ARP request must be sent and answered. So let's focus at the ARP requests.

Do you see ARP requests arrive at your device? If not, did you allow for broadcast addresses?

If ARP requests do arrive, do you see that xNetworkInterfaceOutput() gets called? Do you see an answer to the ARP request on the LAN, when looking with Wireshark? If you do not see an answer, has the DMA been initialised well? Did you start the peripheral clock for DMA? Did you enable RX and TX? Were all descriptors well initialised?

If pxNextNetworkBufferDescriptor equals to NULL, that would mean that some Network Buffers do not get released. You're running out of Network Buffers.

Would you mind showing the adapted NetworkInterface.c ? You might also attach a PCAP if you want, when trying out an ARP / PING.

Regards.


Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 26, 2017

I am using BufferAllocation_2.c

For an ARP request I don't see any network transfer with Wireshark but in debug mode if I store data received into a buffer (gsuceth_buffer) I can see the received packet, please see .png image and Wireshark capture.

For Ping request please see Wireshark capture named "Ping request.pcapng".

xNetworkInterfaceOutput () gets called For all the other questions the answers are affirmative.


Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 26, 2017

... and in attachment it is the updated NetworkInterface.c source code

Attachments

NetworkInterface.c (24197 bytes)

Simple TCP Echo server - does not respond to ping

Posted by heinbali01 on January 28, 2017

Hi Ion Andrei,

Your PCAP called "ARP request.pcapng" looks strange:

It shows 32 so-called gratuitous ARP requests, which are sent within less than a ms. The IP-stack will send these 'gratuitous ARP requests' regularly but not that often. The requests help other devices to keep ARP tables up-to-date, and also to help the detection of double IP-addresses.

Within "PING request.pcapng", I see three gratuitous ARP requests, sent at an acceptable frequency of two per minute.

The ping command (e.g. ping 192.168.0.2) will always start with an ARP command. In you PCAP, the ARP commando isn't answered by the device. As the device is sending gratuitous ARP requests, I would conclude that its RX path isn't working properly.


Simple TCP Echo server - does not respond to ping

Posted by andrei799 on January 29, 2017

Hello Hein,

Related to ARP requests - after some time (dozens of seconds) the "gratuitos ARP requests" are sent at much lower frequency as you pointed out.

I'm fully agree that issue is on Rx path. Please have a look at first image with an ethernet frame received stored in gsuceth_buffer. All data bytes seems to be correctly received (e.g. ethernet header, ...) but aren't sent further to IP Task because all time pxNextNetworkBufferDescriptor == NULL and ~~~ As long as pxNextNetworkBufferDescriptor is NULL, the incoming messages will be flushed and ignored. pucUseBuffer = NULL; ~~~

~~~ > > It seems that TCP/ IP packets are not sent to IP Task due to pxNextNetworkBufferDescriptor which is NULL (prvEMACRxPoll function). Please have a look below. > > > > if( pxNextNetworkBufferDescriptor != NULL ) > > { > > /* Point pucUseBuffer to the buffer pointed to by the descriptor. / > > pucUseBuffer = ( unsigned char ) ( pxNextNetworkBufferDescriptor->pucEthernetBuffer - ipconfigPACKETFILLERSIZE ); > > } > > > > else > > { > > / As long as pxNextNetworkBufferDescriptor is NULL, the incoming > > messages will be flushed and ignored. / > > pucUseBuffer = NULL; > > } > ~~~

Please give me some hints about why pxNextNetworkBufferDescriptor equals NULL. What could be the reason for this? Thanks you.

Regards, Andrei


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists