Problem sending/receiving radius accounting UDP packet using winsock

I'm trying to send a radius auth start/stop message using winsock in a C++ program.
I have all the values inc. shared secret, and I believe I am forming a valid radius packet inc. MD5 hash but I can't be 100% sure.
I don't control the radius server I'm trying to hit...

NTRadPing 1.5 works fine, but on the same machine, my app doesn't (i.e. the packet never gets there or is ignored). My packet length is the same length as the one that ntradping is sending, with what I believe are all the same parameters.

Assuming my radius packet is correctly set up, how do I make my winsock code work properly to read a response?
The "recv()" call hangs - perhaps because the radius server is ignoring or not receiving the message.

I'm having trouble reading the response. Here is what I'm trying to do with winsock (leaving out error handling and such):

WSADATA     wsadata;
SOCKET      sendSocket      = NULL;
sockaddr_in      recvAddr;
DWORD      dwPort      = 1813;
char *      szHostIP      = ""; // real IP hidden

WSAStartup(MAKEWORD(1, 1), &wsadata);
sendSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
recvAddr.sin_family = AF_INET;
recvAddr.sin_port = htons((u_short)dwPort);
recvAddr.sin_addr.s_addr = inet_addr(szHostIP);
connect(sendSocket, (SOCKADDR *)&recvAddr, sizeof(recvAddr));
send(sendSocket, (const char *)rgbBuf, cbLen, 0);

recv(sendSocket, achBufRecv, min(20, sizeof(achBufRecv)), 0);

Who is Participating?
>>The "recv()" call hangs - perhaps because the radius server is ignoring or not receiving the message.

Correct. The recv() will wait until DATA arrives.

>>I'm having trouble reading the response

Yes, even if UPD works corretly this can still occur. The correct procedure is to use the select() call with a time-out value, or use it in a polling fashion, and ONLY call recv() when select() says that there is something to be read.

Lastly I don't connect using UPD but I use sendto(). This link gives an example of BOTH systems, TCP and UDP. See trhe senderprog.c bit.

Note that you then need to use recvFrom() to pick up the reply.

povjetsetAuthor Commented:
that helps with theblocking issue, thanks, however:

1. (stupid question): the response from the radius server is going to come back to my sendSocket, right? (i.e. I don't need to create a second receive socket, which wouldn't make sense!)

2. I still have the issue of not knowing if the packet is even reaching the radius server... the send still returns sucess even if I use a bogus ip address and port...
1. Correct. You just use recvFrom() using the same socket.

2. That I don't quite understand. Are you using the sendTo() interface?
povjetsetAuthor Commented:
send or sendTo, neither is working.
I ran wireshark and compared my packet to one sent successfully by ntradping and I noticed this important difference:

my winsock code's packet: wireshark says it's just a UDP protocol packet with [Protocols in frame: eth:ip:udp:data]
ntradping packet: wireshark says it's a radius protocol packet with [Protocols in frame: eth:ip:udp:radius]
(this is in the main frame of the packet)

So what/where can I set something that will change it from a data to a radius packet?
povjetsetAuthor Commented:
final mystery solved: the length inside the data portion of my radius packet was little endian instead of big endian. once I fixed that, then wireshark recognized it as a radius packet!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.