tags:

views:

80

answers:

2

Im playing with 'recvfrom' and 'sendto' calls using UDP. I have a client that just broadcast UDP packets on port 6000. I have a server that binds a socket on port 6000, and do a single recvfrom.

The problem is that sin_port member of struct sockaddr returned from recvfrom is always incorrect. Why?

I would post some source code but someone already posted that question (with no answers) and I'm using almost the same code as he. Besides, you can get further information about this problem reading his post: FORUM POST.

Thanks in advance

EDIT: I really think 'cause number 2' from 'nos' answer might be the problem. How can I check it?

A: 

Are you converting from network byte order?

Jim
Yes, Im actually checking it on a debugger and the sin_port field has nothing to do with 6000, no matter if it was little-endian or big-endian enconded
Lost Developer
+4  A: 

Here's 2 likely causes:

  1. You're not converting the sin_port to host order before you inspect/display it. sin_port comes in network endian. That is you might be displaying the port as big endian on a little endian machine.

  2. Your client uses a random source port. So while your destination port is 6000, the source port of the client is randomly chosen. recvfrom gives you the source IP address and the source port no. Not the destination port.

If it's neither of these, please provide some relevant test code, and the actual values you are seeing. It's possible you e.g. have some buffer overflows, or something other fishy going on.

EDIT, looking at the code in your link, you hardcode the buffer size(udpPkg.udpRecvBuf) as 1024. Is the buffer really atleast 1024 big ? If not, you're probably overflowing udpPkg.udpRecvBuf.

nos
1) I'm checking my results on a debugger and the received port has nothing to do with 6000. The first word of recvfrom address is:'4D120002' and I was expecting '70170002', since 6000 = 0x1770 (0002 stands for INADDR, I guess) Besides, this number I posted '4D12' changes everytime I run the client.2) Yes, I think the problem might be on the client. Is there anyway I can check it? Is there anyway I can 'fix' it. Thanks in advance.
Lost Developer
How big is udpPkg.udpRecvBuf ? Why are you expecting 6000 ?- the recvfrom address gives you the *source* address, not the destination address
nos
Im using buffers of 256 bytes and I'm only sending packets of 4 bytes. I was using a C client and tried to do it with C# and I've got the same problem. CLR runtime would detect a buffer overflow, I hope.
Lost Developer
If the number is changing each time the client sends, then the client really is using a random source port for each call to send(). The client needs to bind() itself to a specific ip/port if your receiving code requires it to be consistent.
Remy Lebeau - TeamB
But your call to recvfrom, you say the buffer is 1024 bytes big, don't lie to the system, set it to the actual size. You are showing C ,code - what does the CLR runtime have to do with ... anything ? Also, are you checking if the call to `bind`` succeeds ? Or.. post the real code.
nos
Ow, I'm ##NOT## using bind on the client. Do I need to bind it's socket even when performing a sendto call?
Lost Developer
If you're not using `bind` on the sending side, the system chooses a random port as the source address.And if you want a shortcut to check this, run a network sniffer like wireshark and see if the port number in the actual packets are the same as the one you see as the port number.
nos
OK.I will try to bind it, and if it works I will post here.THANK YOU very much
Lost Developer
Using bind on client solved the problem!Thank you again.
Lost Developer
@Lost Developer: You don't actually *need* to `bind()` on the client - that's *why* `recvfrom()` tells you the port that the client used - so you can respond back to it, no matter what it is!
caf