Labwindows recvfrom ==SOCKET_ERROR

[JasonZha]

Hello, 

I try to use the NI 8561 to capture some ethernet frames. 

Then I write a Ethernet ReadFrame function in the CVI which will be called by the Teststand.

Secondly, I configure the Tester's IP, Mac. After that I use a wireshark to capture the frame, it shows successfully.

But my program will always failed on the recvfrom step, see below pic.

I also add my source code as the attachment files. I have worked for some days, but no any progress.

Is somebody can give me some suggestions?

Thanks in advance.

[JasonZha]

Finally, I got the root cause. It is weird that Windows firewall limited the recvfrom fucntion to get the messages. After I closed the windows firewall, it implemented successfully.

[rolfk]

That's fully understandable. Windows network firewall will normally give you a dialog the first time an executable tries to open any network socket and prompt you to allow this. If you cancel this dialog, which can easily happen, Windows firewall will consider this as a denial from you to grant that access and register an according blocking rule for the executable in question. You can change these settings per application in the Windows firewall settings and grant such an application access anyways after the fact. You definitely should never ever disable the firewall on a system that is in any way connected to the internet!

There is another potential problem in your code:

if ( (nRxBytes = recvfrom(rxSocket, rxBuffer, sizeof(rxBuffer),  0, (SOCKADDR*)&senderAddress, &senderAddressSize)) == SOCKET_ERROR )

After this call returns successfully, senderAddressSize will have been updated with the actual size of the SOCKADDR* structure returned. If your recvfrom() for some reason updated this value in case of some incoming message to your registered port but with a shorter address than your intended sender, and you then go around and loop again to receive the next message, it may not be able to fill in the actual address as it believes the buffer to be to small.

You should add in your code at the end of the for loop a line to reassign sizeof(senderAddress) to this variable just to be sure. And you should probably add also something that will cause the loop to break if the timeout was exceeded. Currently your loop will only break when either a socket error occurs during recvfrom() or when the received message is from the expected sender.

[JasonZha]

Hi Rolf,

Thanks for your kind help. It is so detailed and useful. I will consider it and try to optimize the source code.

But I am also confused that I run the application so many times, but the windows dialog do not appear every time, seems they only appeared by occasionally that is why I take so many days to get the root cause. At the same time, even I clicked the allowing, the recvfrom still failed. That is what I am confused.

Thanks

[rolfk]

Windows firewall only shows you that dialog once for each program as long as it does not have a rule for it. Once you dismiss this dialog, positive or negative (and canceling it quickly as "another" dialog during program startup counts as negative confirmation too) it stores that information and never bothers you again for this application.

You have to select in that dialog for which network choice you want to allow it but that selection is very broad (only gives you Public and Work networks as a choice. If that does not give you enough control you have to explicitly go into the Windows Firewall settings and give your executable the according rights, which are controlled separately for UDP and TCP network access and can go even into more detail such as a port number range.

[RobertoBozzolo]

Just as a side note, I remember to have had problems in the past where the firewall was complaining about the application, asking me to grant permissions every single time I recompiled it (as you may know, on development it happens quite often 😉 ). I eventually solved it by manually adding a rule in the firewall for the application, 'cause replying to the message didn't fixed the situation.

It happened a few years ago and for the life of me I can't remember whether at that time I was using the built-in WIndows firewall or another vendor's one

[rolfk]

Windows Defender itself is fairly minimalistic in what it allows to configure as well in how it attempts to interfere with the user. The general rule is that Windows stores per executable location (full path including executable name) the rules for a process. I never saw that a recompilation would have reset those settings but it could be possible.

There is something to be said to require reacknowledgment when the application version or timestamp has changed, but the downside to this is "yet another dialog" that most users just click away.