FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [January 2017 Threads] Simple TCP Echo server - does not respond to pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted 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 pingPosted by andrei799 on January 26, 2017 ... and in attachment it is the updated NetworkInterface.c source code
Simple TCP Echo server - does not respond to pingPosted 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 pingPosted 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|