LabVIEW
There is a delay in the PING server using system exec.vi.
I tried Ping with. NET and found that the delay had disappeared. At this point, system exec. VI had a problem with the process from Source Code to EXE
@billko wrote:
@jiaojiao002 wrote:
I am sorry to reply you now. I have two computers. Their network environment is different. In one computer, the source code and EXE have no delay, in another computer, the source code has no delay, the EXE will delay about 8S, each time there is a delay, this program will start 10 minutes later, the delay will disappear, 8s and 10min is an approximate value, I did not give him manual delay, this time is also I want to find out. Please see the pictures for the program
Hmmm... now that you mention it, I might have been seeing the same issue across two computers for a while now, but never gave it a thought. Not the ten minute part but the 8 sec delay. I guess I'll have to poke around just like you. 🙂
Wild idea but maybe it is a security issue where security software prevents network access to a never seen application before the AV system has a chance to scan the executable in more detail and monitor the network behavior. Malware typically contacts a series of rogue servers that are often taken down quickly, so malware might ping them first to see what's still around. Pinging by an application that just started could be considered suspicious.
Do you run any specific AV/security suite?
I wonder if running the exe as administrator would make a difference.
@altenbach wrote:
@billko wrote:
@jiaojiao002 wrote:
I am sorry to reply you now. I have two computers. Their network environment is different. In one computer, the source code and EXE have no delay, in another computer, the source code has no delay, the EXE will delay about 8S, each time there is a delay, this program will start 10 minutes later, the delay will disappear, 8s and 10min is an approximate value, I did not give him manual delay, this time is also I want to find out. Please see the pictures for the program
Hmmm... now that you mention it, I might have been seeing the same issue across two computers for a while now, but never gave it a thought. Not the ten minute part but the 8 sec delay. I guess I'll have to poke around just like you. 🙂
Wild idea but maybe it is a security issue where security software prevents network access to a never seen application before the AV system has a chance to scan the executable in more detail and monitor the network behavior. Malware typically contacts a series of rogue servers that are often taken down quickly, so malware might ping them first to see what's still around. Pinging by an application that just started could be considered suspicious.
Do you run any specific AV/security suite?
I wonder if running the exe as administrator would make a difference.
Very interesting, indeed. Using McAfee Enterprise. Interestingly enough, the computer with the standard IT image works fine, but one with a generic build doesn't.
Unfortunately raw sockets is a privileged resource that only elevated processes are allowed to use. That means you have to elevate your LabVIEW application specifically. Starting as administrator is not enough, you have to go through the explicit elevation dialog which will prompt you even if you are already logged in as administrator.
And no this is not a Windows speciality, all modern operating systems including Linux will require special rights assigned to an executable in order to allow them to open a raw socket. The reason is that a raw socket allows any type of network communication including spoofing of source and destination addresses, a paradise for any malignent software!
For Linux you can set the privileges of an executable file through the command line to allow it access to raw sockets. For this Linux has so called capabilities that can be applied to a file to allow specific capabilites such as CAP_NET_RAW, that are normally only granted to root processes. Obviously you need to be root to be able to grant capabilities to a file.
Under Windows there is no such fine grained capability system unfortunately. It has some privileges that can be configured in the policy editor but you only have that option in professional and enterprise versions of Windows.
However Windows comes with a build in ICMP (the low level IP protocol (ab)used to implement ping) service process and an API to interface to that which resides in Iphlpapi.dll. https://docs.microsoft.com/en-us/windows/desktop/api/icmpapi/
I am sorry to reply you so long. As for the problem of latency, I found that the key was not PING, but system exec VI calling the CMD window. Because this VI will pop up CMD window after running 8S, and pop up the window immediately back to PING instructions, and then get the return value.
Now I'm trying to call CMDs in other languages, such as C or JAVA, to determine whether the problem is the computer itself or the software
