lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Problems with sending UDP packets in FreeRTOS


From: Mike Fleetwood
Subject: Re: [lwip-users] Problems with sending UDP packets in FreeRTOS
Date: Thu, 28 Jul 2016 09:58:09 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi Noam,

Many thanks for the additional hints!  This project (as you guessed) is also VOIP.  It will use RTP, but the code fragment I sent is a stripped-down version of the packet sender, that I used when I started to find problems.  There are separate threads to handle discovery (using NetBIOS, as only my devices need to discover each other), set-up user interface HTTP server, also SIP and RTCP which I haven't written yet.  Currently, all threads except the RTP/audio and lower level LWIP are disabled for testing.

I looked at the first link you sent, and the Netconn example is pretty close to where I started - I will copy it into my code and see what it does!  I haven't had a chance to look at the others yet.

Thanks again,
Mike.

On 28/07/2016 09:07, Noam Weissman wrote:

Hi Mike,

 

Above all your testing…

 

Many years ago I worked on a VOIP project and implemented portions of RTP protocol.

 

From that experience, I think you should not reinvent things. Sending streaming data over UDP

without some protocol will eventually cause you to lose or miss data.

 

UDP packet ordering is not guaranteed so you must have some protocol to carry the data.

 

What do I mean?… TCP will guaranty that the order of sent data is the same order it is received.

Under UDP data packets are not guaranteed to be received in the same order they were sent !.

 

To overcome this problem and still benefit the faster transfer under UDP, RTP defines a time stamp

for every packet. This way you push data packets to a link list on TX side, every packet sent out has

a time stamp. A real accurate time stamp

 

On the receiving end you also hold a link list. Received data packets are checked and if the time stamp

is older than the last handled packet is discarded…

 

This is in short. There is much more, but I am sure you can read about RTP and more modern video/audio

streaming protocols in details.

 

Another overlooked issue that I learned the hard way:

if you send TCP data, if connection is dropped or there is an error, eventually data is removed from the

TCP stack and memory is released.

 

People FORGET that when you send UDP data and remote IP is not reachable or wrong data is piled

at the TCP stack and never freed. Eventually causing the TCP stack to crash or have memory errors.

 

The reason is that if you send data to a wrong IP or domain and TCP stack does not have the destination

MAC address so it will issue ARP messages. What if the ARP message fails ?... The TCP stack does not know

where to send the UDP packets. As a result if you continue to send UDP packets they are added to the

waiting packets to be sent. They are never sent, memory is not freed and eventually you are without

memory !!

I hope the above helped in some way.

 

BR,

Noam.

 

 

From: lwip-users [mailto:address@hidden] On Behalf Of Mike Fleetwood
Sent: Thursday, July 28, 2016 10:42 AM
To: address@hidden
Subject: Re: [lwip-users] Problems with sending UDP packets in FreeRTOS

 

Hi Noam,

 

Thanks for the response.

 

I will look at the links you sent, later today - see what I can discover.

 

I originally had the buffer creation/deletion inside the loop -  so it was a fresh buffer for every send.  The final version needs to do this anyway, as the audio packets to send will vary slightly in size.  I only changed it when I was trying to discover the cause of the ERR_USE return.

 

What I don't understand is why/how repeated sends with the same source/destination address and port should (after a time) cause an error.  My understanding is, this should only happen if we attempt to create a new connection with the same character as an existing one - as far as I can see, my software should keep using the original one (changing the destination address only if needed).

 

Many thanks,

Mike.

 

On 27/07/2016 21:46, Noam Weissman wrote:

Hi,

 

I never worked with netconn so I am not sure. I worked mainly with RAW API.

 

See these:

http://www.ultimaserial.com/avr_lwip_udp.html

lwIP UDP Echo Broadcaster Example using Raw API, Socket or Netconn approaches UltimaSerial . Windaq Add-ons

 

https://lists.nongnu.org/archive/html/lwip-users/2010-04/msg00053.html

 

 

 

http://www.freertos.org/FreeRTOS_Support_Forum_Archive/April_2009/freertos_Start_lwIP_UDP_in_a_Task_3216066.html

 

 

 

Seems that in the examples for every send they allocate a new buffer and after every send the delete it.

For me it looks perfectly sensible.

 

I hope that helps a bit.

 

BR,

Noam.

FreeRTOS support forum archive - Start lwIP UDP in a Task

 


From: lwip-users <address@hidden> on behalf of Mike Fleetwood <address@hidden>
Sent: Wednesday, July 27, 2016 6:07 PM
To: address@hidden
Subject: [lwip-users] Problems with sending UDP packets in FreeRTOS

 

Hi,

I’m hoping someone can help me with a problem that has been causing me grief for a few days now!

 

I am writing an RTP audio system, that needs to send a packet of audio data every 4mS.  This is in a multi-thread RTOS environment, running on STM32F427, with initial code generated using ST’s “Cube” (wish I hadn’t!).  I have threads to handle NetBIOS and HTTP, but they are all disabled at the moment.

 

The problem I’m having is that after a variable length of time – sometimes immediately on start-up, sometimes after half an hour – the code stops working.  The central “netconn_send” returns with “ERR_USE”.  I have tried many variations with this code, all showing the same problem.  None of the other error warnings get activated, only the GPIO pins set to indicate the error.

 

Question 1: Why should send return with ERR_USE?  At present there is only one connection and it is only bound/connected once – outside the loop.  I get the same error with connection within the loop, or if I use sendto instead.

 

Question 2: Why does this supposedly non-fatal error cause all lower level LWIP functions to stop?  If I have the HTTP thread running (to show status/fault information) it also stops.

 

Question 3: Why does not SOF_REUSEADDR mask the error (SO_REUSE is enabled in lwipopts)?

 

Many thanks,

Mike.

 

void udp_test(void *arg)

{

  struct netconn *conn;

  struct netbuf *buf;

  char *data;

  err_t err;

  uint16_t index;

  size_t bufsize = 100;

 

  conn = netconn_new(NETCONN_UDP);

  if (conn == NULL) debugmessage("Could not create new netconn for UDP test<br>");

  if (conn != NULL)

  {

    ip_set_option(conn->pcb.udp, SOF_REUSEADDR);

 

    err = netconn_bind(conn, IP_ADDR_ANY, 5004);

    if (err != ERR_OK) debugmessage("Could not bind to port 5004 for RTP data<br>");

 

//    err = netconn_connect(conn, IP_ADDR_BROADCAST, 5004);

//    if (err != ERR_OK) debugmessage("Could not connect port 5004 to BROADCAST for RTP data<br>");

   

//    while(1)

    {

      buf = netbuf_new();

      if (buf == NULL) debugmessage("Could not create netbuf for UDP test<br>");

      if (buf != NULL)

      {

        data = "" bufsize);

        if (data == NULL) debugmessage("Could not allocate pointer to UDP test data in netbuf<br>");

        if (data != NULL)

        {

          while(1)

          {

            HAL_GPIO_WritePin(CONT6_GPIO_Port, CONT6_Pin, GPIO_PIN_SET);

            for (index = 0; index <bufsize; index++)

            {

              data[index] = index;

            }

//            err = netconn_send(conn, buf);

            err = netconn_sendto(conn, buf, IP_ADDR_BROADCAST, 5004);

            if (err == ERR_USE) HAL_GPIO_WritePin(CONT3_GPIO_Port, CONT3_Pin, GPIO_PIN_SET);

            if (err == ERR_MEM) HAL_GPIO_WritePin(CONT4_GPIO_Port, CONT4_Pin, GPIO_PIN_SET);

            if (err != ERR_OK) HAL_GPIO_WritePin(CONT5_GPIO_Port, CONT5_Pin, GPIO_PIN_SET);

            HAL_GPIO_WritePin(CONT6_GPIO_Port, CONT6_Pin, GPIO_PIN_RESET);

            osDelay(4);

          }

          netbuf_delete(buf);

        }

      }

//      osDelay(4);

    }

  }

}

Sent from Mail for Windows 10

 




_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users



-- 
FACE Systems Ltd
The Old Boat House
Cadgwith
Cornwall TR12 7JX
T:01326 291031
M:07831 401464


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

-- 
FACE Systems Ltd
The Old Boat House
Cadgwith
Cornwall TR12 7JX
T:01326 291031
M:07831 401464

reply via email to

[Prev in Thread] Current Thread [Next in Thread]