[En-Nut-Discussion] Bug in UDP socket handling

[Dusan Ferbas]

Hi,

I pointed out non existance of UDP queue for incoming packets a year ago. I 
have different opinion from Ralph. I think that this feature is needed for 
Nut/OS. Our next applicaton will handle snmp traffic from several hosts 
that will be checking through our device that target technology (large UPS 
system) is working. Of course solution can be done more efficiently with 
snmp traps but we have no strength to change large IBM SW solutions.

So we need a UDP queue. For us it is not question of why but only when. I 
noticed that Oliver S. pointed out another problem with SIGNALED state of 
UDP socket (for your convenience attached below).

I suggest to divide a work on this improvement. If there is somebody 
working on it and wants to participate I will appreciate it. I do not want 
to bother anybody but I simply need it. If there are no other suggestions I 
can try to be responsible for queue handling, Oliver can improve state 
signalling, Ralph can test if it fits into his PPP application.

Time horizon - I need it in the middle of December this year.

Some more ideas ?

Dusan Ferbas


> > Hello All, hello Harald.
> >
> > It seems, that I found a bug or a general problem in UDP socket
> > handling.
> >
> > I figured out to situations where the bug appears.
> >
> > 1.
> > As soon as you create a UDP socket with 'NutUdpCreateSocket' the
> > socket is ready to receive UDP packets. If a packet is received before
>
> > some thread calls 'NutUdpReceiveFrom' the netbuf is stored in the
> > socket and the receiving event is posted. Because nobody waits for the
>
> > event at this time, the event queue is set to SIGNALED. In the first
> > call of 'NutUdpReceiveFrom' the already received UDP packet is noticed
>
> > and will be returned to the caller. The netbuf pointer in the socket
> > is set to 0, but the event queue is still SIGNALED. The next call to
> > 'NutUdpReceiveFrom' will immediately fail, because the event is
> > SIGNALED, but no netbuf is stored in the socket. The return value is
> > then 0, which indicates a timeout event...
> >
> > 2.
> > Consider that one thread has called 'NutUdpReceiveFrom' on an empty
> > socket (that means no packets was received yet) and is sleeping now.
> > Then two or more packets are received one immediately after the other.
>
> > That happens for example as an answer from several hosts to a UDP
> > broadcast (I used NutSNTPGetTime). The first received packet is
> > normally routed through the IP stack, UDPIn finds the correct socket,
> > stores the netbuf in the socket and posts the event to the queue.
> > Because only one thread was in the queue, the queue points now to
> > 0x0000, indicating an empty queue. The formerly sleeping thread is
> > inserted in the 'runQueue' and marked as ready to run.
> >
> > But then the nic receive thread 'rxi5' (which is still running) sees
> > the next received UDP packets and routes it again to the stack. UDPIn
> > notices that there's already a stored UDP packet and discards it. The
> > new packet will be stored in the socket and the event is posted again.
>
> > Because the event queue was empty before, it now has the SIGNALED
> > value. If then the sleeping thread (caller of 'NutUdpReceiveFrom')
> > becomes active, it get the last received UDP packet and removes the
> > netbuf from the socket. Because the event queue is still SIGNALED, the
>
> > next call to 'NutUdpReceiveFrom' will fail like in situation 1.
> >
> >
> > To fix this issue I suggest to introduce also for UDP sockets a kind
> > of received packets queue. The NETBUF struct already has a pointer to
> > another NETBUF for generating lists, so its not very complicated to
> > add this feature.
> >
> > If it's done you will not lose UDP packets anymore. Before UDPIn posts
>
> > the received event, it has to check the queue. If empty, it must not
> > post the event. Otherwise we will get the SIGNALED state and
> > 'NutUdpReceiveFrom' can fail again.
> >
> > Any comments?
> >
> > Cheers,
> > Oliver.
> >