tags:

views:

59

answers:

2

Hi

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.

A: 

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.

caf
He's saying the `SO_RCVTIMEO` is set.
Nikolai N Fetissov
@Nikolai: Sure, but he's also saying that the reply is coming back well within the `SO_RCVTIMEO` time.
caf
Hmm, I don't see that in the question.
Nikolai N Fetissov
@Nikolai: *"and ECHO REPLY which is coming within few milliseconds but still recvfrom is not able to read it"*
caf
Exactly - there's a packet on the wire but the app is not seeing it.
Nikolai N Fetissov
@Nikolai: The OP has not said whether it's returning `EAGAIN` immediately (which would imply that it is a nonblocking socket) or after 10 seconds (which would imply that it is not seeing the packet).
caf
I read it as the former, though yes, not enough info, no point in arguing.
Nikolai N Fetissov
Hi guys ... after hours going through the flow .. I found that packet is getting dropped by IP STACK as a result my SOCKET is not able to get any of the packets destined to it.
codingfreak
Just curious - was the socket non-blocking?
Nikolai N Fetissov
+1  A: 

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.

codingfreak