2
votes

I am trying out a udpclient program which uses sendto and recvfrom functions. I am setting SO_RCVTIMEO value as 10 seconds for my socket.

I am binding the socket to source ipaddress and sourceport. When I check the netstat I can see that there is no other process which is binded with the same values. My bind operation is also successfull.

Then I am doing a sendto which is sending a echo request to destination. After sendto I am doing a recvfrom. But recvfrom fail's saying ERRNO 11 which means try again :(

But if I check the wireshark logs I can see ECHO REQUEST and ECHO REPLY which is coming within few milliseconds but still recvfrom is not able to read it :(. In wireshark I am seeing the UDP ECHO REQUEST AND UDP ECHO REPLY.

I dont have any FIREWALL enabled in my system.

Is there any way to debug this issue :( I am really doubting the RECV operation is there any way to find out if the packet is being sent to my sockFD or not ???

UPDATE1: My linux PC is connected to another linux pc acting as a server via switch.

2
So you see in Wireshark a UDP packet "ECHO REPLY" to a port where your socket is bound to? "ECHO REPLY" somehow looks a bit like ICMP. You are not so detailed on your setup description. Does your udpclient use the same port for sendto and recvfrom? If not, check port number (endianess). Did you check the success of bind()? Is your client port already used by another program (see: netstat)? Regarding your "SO_REUSEPORT on linux" question, usually one receiv socket gets the packet.harper
HI Harper thanks for the reply .. YES i am getting ECHO reply for the same port to which my socket is bound. YES bind returns successfull and I am seeing the instance using netstat command. My client port is not used by nay other than my application.codingfreak
Have you tried netcat (nc) to see if you can talk between the machines?Nikolai Fetissov
Does the call return immediately or after 10 seconds?Tyler McHenry

2 Answers

2
votes

I have the found out the ISSUE atlast ...

Seems UDP checksum of the packet is wrong as a result IP STACK is dropping the packet before it reach's SOCKET :( as a result recvfrom is getting timeout and coming out.

0
votes

EAGAIN from recvfrom() implies one of three things:

  • The socket has been set to non-blocking; or
  • The MSG_DONTWAIT flag was used; or
  • The receive timeout has expired.

It sounds like your socket is non-blocking to me.