UDP packets not received at client when LAN switch is used

Question

UDP packets are sent to a Linux client. If those packets are not sent for a particular time interval(1 min) and sent again to the same UDP port, then the recv function returns -1 and error is EAGAIN. This problem occurs only when the client is connected to the network through the LAN switch. Why this problem occurs, when using a switch?

And this problem was fixed temporarily, when the UDP client uses the send function to send dummy data to the server whenever recv function returns EAGAIN error. Please someone clarify on this behaviour.

Answer 1

The above problem has been resolved. Its the UDP timeout (30 sec) setting in the router which affects the packet flow after 30 seconds if there is no flow of packets to the client.

Answer 2

recv function returns -1 and error is EAGAIN

This means that the socket is non-blocking. If that is the case, then you might likely be missing the packet (may be calling recv() before the datagram made it to the receiver). Purely for debugging, you should make it blocking and try.

If those packets are not sent for a particular time interval(1 min) and sent again to the same UDP port

This should have anything to do with UDP datagram reception. If the sender sends a data, then the receiver's UDP buffer should store hte packet until the application calls recvfrom().

I would suggest two things.

First, you can use ss (or its earlier (deprecated on Linux) version netstat, if ss is not available). You would see something like this. If you have received the packet (datagram), then the second column (Recv-Q) pertaining to your flow should show the number of received packets; you can identify the flow using the port number on which your receiver is bound.

# ss -upan
 State    Recv-Q Send-Q   Local Address:Port   Peer Address:Port 
 UNCONN   0      0        *:48408              *:*   users:(("dhclient",22086,20))
 UNCONN   0      0        *:7000               *:*   users:(("udp_server",23994,3))
 UNCONN   0      0        *:68                 *:*   users:(("dhclient",22086,6))
 UNCONN   0      0        *:631                *:*   users:(("cupsd",1549,13))
 UNCONN   0      0        :::47798             :::*  users:(("dhclient",22086,21))
 # 
 # netstat -upan
 Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address    Foreign Address  State  PID/Program name   
 udp        0      0 0.0.0.0:48408    0.0.0.0:*               22086/dhclient      
 udp        0      0 0.0.0.0:7000     0.0.0.0:*               23994/./udp_server  
 udp        0      0 0.0.0.0:68       0.0.0.0:*               22086/dhclient      
 udp        0      0 0.0.0.0:631      0.0.0.0:*               1549/cupsd          
 udp        0      0 :::47798         :::*                    22086/dhclient      
 # 

Second, if you see nothing in the receive queue (Recv-Q), then you should use a packet capturing tool like tcpdump and see if packets are making it through?