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.
Related
I'm searching for help and an opinion-advice for a network project, in which I'm working lately. This requires a Linux machine to be a passive network appliance.
Network packets come in from one network interface and come out from another interface ( net--eth0-->Linux PC--eth1-->net) without making any modifications on data.
The application, which is going to run on the Linux system, will change only the order of the packets. It is going to be a "silly" network emulator application.
The first implementation was made with RAW sockets, where read() is called every time a packet arrives to user space and write() is called when an Ethernet packet should be sent down to the NIC.
I would like to know if there is a more practical and direct way than RAW sockets, bypassing Linux's network stack.
If what you want is to bypass the kernel, DPDK in Linux and NetMap in FreeBSD are options to do just that.
Indeed this can be done in dpdk in Linux. There are l3fw and l2fwd sample applications in the examples folder of the dpdk tree, which may inspire you. Also consider using vpp, a fd.io project hosted by Linux Foundation, which can use dpdk.
Rami Rosen
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.
My goal is to monitor sockets and relate them to the applications that created them.
I am aware of netstat, ss, lsof and so on and that they can list all sockets with their application.
And I also know that I can parse /proc/net/tcp to get the sockets and relate them to the applications with /proc/(PID), which is exactly what these tools do or they use netlink sockets.
My researches brought me to an article which explains how to get all sockets from the kernel with netlink via the inet_diag protocol. The user space program sets up a netlink socket of the inet_diag type and sends a request to the kernel. The response consists of several messages which contain the sockets and additional related information.
This is really neat, but unfortunately the kernel sends this information only once per request. So I have to "poll" continuously.
Further researches brought me to another article which monitors IP changes of interfaces with netlink route sockets continuously. The socket is bound to a multicast group and then messages are read from it in an endless loop.
So I investigated if there is the same possibility with the inet_diag sockets. Unfortunately I am not really able to understand kernel code. But as far as I can tell there are no multicast groups for this socket family.
At this point I am stuck and I need to know if this approach is somehow feasible or somebody knows any other hints.
You can try dtrace if every tools you mentioned can't meet your requirement.
You can use kprobe kernel module to hook all connect system call，whichi monitor sockets and relate them to the applications that created them
just like Elkeid，Elkeid Driver hooks kernel functions via Kprobe, providing rich and accurate data collection capabilities, including kernel-level process execve probing, privilege escalation monitoring, network audition, and much more. The Driver treats Container-based monitoring as a first-class citizen as Host-based data collection by supporting Linux Namespace. Compare to User Space agents on the market, Elkeid provides more comprehensive information with massive performance improvement.
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.
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.