Sending signal/text from Linux Machine to Labview in Window - linux

Currently I'm developing a data acquisition program for my experiment in C++ from a Linux based machine (Ubuntu), I also have many VIs in Labview who is programmed in Windows to control the instruments of the experiment (motors, Signal Generator..). The purpose is to have a 2-way communication between 2 pc, the Linux will ask which VIs to be executed, and when it's finished, send back a signal to Linux machine.
My questions are:
Can I send a signal or a command to Labview in Windows from Linux (Terminal, and it can be implemented into my C code) and vice versa? How?
TCP Labview could be a solution? Or should I try to set the inter-PC "talking" through serial communication (which is easy to setup physically)?

The best (also the easiest) way is to implement TCP-based client-server communication (TCP will ensure data is lossless. When using other mechanisms like UDP or serial you should always make sure your commands are received correctly).
At LabVIEW site, you will have TCP listener (server) which will listen to commands from the Linux machine at your specified port.
Upon command reception, LabVIEW code can do the work and reply by the same TCP connection.
This is very good article about your question: https://decibel.ni.com/content/docs/DOC-9131

Their are several choices for communicating between C++ and LabVIEW. (As well as Linux / Windows).
If you are willing to run LabVIEW on your linux machine you can make use of several of the LabVIEW communication architectures. Here is NI's white paper.
http://www.ni.com/white-paper/12079/en/
Provides choices such as Shared Variable, Network Streams, Web Services, TCP/IP.
You can also take your LabVIEW code and compile it to a DLL and call it from C++ to make use of some of the above features. If not you are likely going to have to go to the TCP/IP route or web service.
I would recommend using TCP/IP, its pretty simple to implement on both sides.
If you are more familiar with serial protocols you can also use them to communicate.

Related

How do libraries like Scapy, Npcap, WinPcap, etc., get around Window's limitations on sending raw TCP packets?

I learned the hard way that modern Windows machines do not permit sending TCP data over raw sockets after trying to perform the TCP handshake myself in Python. And yet Scapy, a Python library, is able to do it seemingly just fine. Other libraries, like Npcap and WinPcap, also seem to be able to send raw TCP data just fine on Windows. How is this possible? What are these libraries doing under the hood that enables them to bypass this limitation?
WinPcap (the windows implementation of libpcap) authors say in their website:
WinPcap consists of a driver that extends the operating system to provide low-level network access and a library that is used to easily access low-level network layers.
So the answer to your question would be: in windows, the implementation of libpcap (which is what Scapy uses according to their site) uses a driver to get access to the low-level networking stuff

UDP communication is lost on linux, are "UDP sockets" managed differentely on linux compared to windows when using C# .NET Core 2.1?

I have a C# .NET Core 2.1 application that runs fine on windows. A listener task for incoming UDP packets and another thread which sends UDP-packets. The software communicates with an embedded device using a proprietary protocol above UDP which requires "PING-PONG" (ACK) in order to "stay alive".
When running the application on windows I have no problem with the communication. When I run this on Linux Ubuntu (18.04) I sometimes have trouble communicating. Sometimes the communication is lost (packets don't arrive to the application although they are visible in Wireshark) and so on, basically it behaves bad...
The code more or less uses basic stuff from online tutorials for the "back-bone" of UDP communication (listener and so on). Do you have any idea what's going on here?
It turns out it was a combination of linux socket buffers which I increased to:
net.core.rmem_max=26214400
net.core.rmem_default=26214400
net.core.wmem_max=26214400
net.core.wmem_default=26214400
(in /etc/sysctl.conf)
and proprietary protocol specific bugs...

Linux Networking Kernel

I am reading Kernel Networking In linux. I found this http://www.ibm.com/developerworks/linux/library/l-linux-networking-stack/ article helpful. After reading this I have a doubt that If I create any software in Linux platform.. Lets say, some chat Program.. Do I have to make use of all those API`s(sk_buff and all) available to connect to the another network? Please help me with it.
sk_buff is a kernel structure that is part of the kernel's TCP/IP stack. You shouldn't need to touch this directly and will in actuality find it difficult to do so.
What you need instead is to learn the user-space API's for network communication. For quickly learning the basics of network communication on Unix, it's tough to beat Beej's Guide.
If you want to create a chat software I would recommend to you to checkout the BSD Sockets or any TCP/IP Network Guide for Linux. You don't need to understand what's going on within the Kernel in order to Program a chat software.
The sk_buff is relevant if you would like to create a new device driver but you seem to be above the protocol level.
If you want to create a chat you would create a Server Socket (Listener) and Clients which connect to the address where your Server is listening and exchange information through TCP/IP.
sk_buff is a kernel data structure for socket buffer. You do not have to touch it for your chat server. If you have taken an OS class you must have noticed there is a process structure(struct proc in Linux) but does it mean you have to use it when you write a program ? No. sk_buff is a similar case, Linux kernel uses it to buffer certain data. You don't have to be concerned with it.
For your chat server have a look at Beej's guide, it has an implementation of Chat Server if I am not wrong and its the best guide that I know to get started with Network Programming on Linux, and is filled with humour. For a deeper understanding of Network Programming look at Richard Stevens Unix Network Programming, Volume 1 and Volume 2. It is considered the bible of Network Programming.

Implementing a kernel debugging module for a Linux guest OS inside a VmWare VM

Sorry for the rather long post.
I need some input regarding a project that I am going to undertake.
I am trying to make an application that collects kernel debugging information from a guest Linux OS, located inside a VmWare Virtual Machine, and send them to a host OS efficiently.
So far, I have found a similar project, but written for Windows[1].
The author of the project wrote a DLL that is loaded into memory, and replaces the implementation of the KdSendPacket and KdReceivePacket functions, to use the VmWare GuestRpc[2] mechanism, instead of the slow serial port.
The data are then send to a debugging application on the host(Kd or WinDbg) trough a named pipe.
The author claims that there is a speed-up up to 45%, by avoiding the serial port transmission.
I am trying to achieve something similar ,but for Linux, and try to make the debugging process a little faster, than using the serial port.
My concrete questions are :
Do any similar applications exist?
I didn't manage to find any.
Would such an application be worth it ,comparing its functionality to netconsole[3], for example?
What method of intercepting printk messages would you suggest ?
Is there an equivalent of KdSendPacket/KdReceivePacket on Linux ?
[1]. http://virtualkd.sysprogs.org/dox/operation.html
[2]. http://articles.sysprogs.org/kdvmware/guestrpc.shtml
[3]. http://www.kernel.org/doc/Documentation/networking/netconsole.txt
Using the serial port is really suboptimal.. even the (virtual) network would be preferable to that, but getting back to host-guest IPC channels, VMware's VMCI comes to mind.
many approaches can use to achieve your goal, below methods can be applied if network is connected:
use syslog service and transfer log though network to your server:
syslogd, syslogng seems support sending log to a log server with some filter critiera.
directly call tcp/udp socket functions in your kernel module to sends your collected data back to server.
other approaches, you may write application on host machine that calls hypervisor's share memory access function to read the memory buffer of your kernel module. However, the xen/kvm hypervisor both support these apis and i am not sure about weather vmware have this kind of library.

Listening a particular port on linux to access data comes from mobile device

i am newbie to Linux platform, i am working on java technology.
what i have to do is : Having a program that running on mobile devices,that sends some data to my Linux machine, now i have to create a program in java that
listen to a particular port.
access data comes on that port(which is sending by mobile device)
save that data to the database.
response back to the mobile device.
i.e. i would make my Linux system as server that can listen from many clients(mobile devices), but not getting how to configure this environment... :(
i used cent OS 5.4 and
installed jdk1.6.0_24
any help would be appreciated.....
thanx in advance!
khushi
One of Java's greatest strengths is that you can pretty much ignore the host operating system as long as you stick to core Java features. In the case you're describing, you should be able to accomplish everything by simply using the standard Java networking APIs and either the JDBC to access an existing, external database or you could choose any number of embedded Java databases such as Derby. For your stated use case, that you'll be running the application on Linux is pretty much irrelevant (which should be good news... you don't need to learn a whole operating system in addition to writing your app ;-).
Here's a nice client/server tutorial, in that it is broken into steps, and adds each new concept in another step.
Here's another client/server tutorial with much more detail.
I would write it to accept one connection at a time. Once that works, I would study the new(ish) java.lang.concurrent classes, in particular the ExecutorService, as a way of managing the worker bee handling each connection. Then change your program to handle multiple connections using those classes. Breaking it up in two steps like that will be a lot easier.

Resources