I want to send message from VM kernel to host kernel without net like socket. I refer to hypercall but still can not know how to use. Is there any tutorials or any other solution?
A possibility might be to use AF_NETLINK sockets documented in netlink(7). You might need to code then load your own Linux kernel module.
Related
I need to create a Cocoa app that will create a virtual serial port available to other apps, meaning registered in the IO Kit Registry.
Gist of the app:
Create a virtual serial port (listed in /dev and registered with the IOKit Registry)
Initiate a tcp connection out to another computer
Proxy everything received on the virtual serial port out to the
network and vice versa.
This app will be used by third party apps that talk to serial ports on the computer, allowing for the particular serial device to be located across the network. The Cocoa and network part is no problem, I've written several apps that talk over the network. My hangup is the serial port.
I've done the test with socat/netcat/minicom to verify that it all works to proxy pty/tty traffic over the network but the tty I use doesn't show up as usable by random applications because it's not registered in the IO Kit Registry.
While I can use a pty/tty master/slave for the communication, I need this slave tty to show up to Mac applications. What would be very handy is a way to register a tty in the IO Kit Registry.
Do I really need to create a custom IOKit kext driver that gets registered at Cocoa app runtime? If so, I have a big learning curve ahead of me. Where should I start reading? Or, can I use IOKit to create a virtual serial port and register it as a usable serial port for applications without having to load any kernel extensions?
Thank you for any help you can provide,
Stateful
First of all, have you checked if you can borrow a solution from this app? It's not obvious from the website if they've managed to get their virtual serial ports fully integrated into the system.
If there is a way to do it from user space, I'm not aware of it. The user-space IOKit API generally doesn't let you create class instances, let alone new device driver classes. Maybe you can somehow otherwise persuade the Cocoa libraries to find it despite not being registered in the kernel.
I don't know if you could get away with creating a "dummy" serial port in the kernel and then move your tty into its place in /dev from your userspace daemon. Maybe that's an option.
In case you do have to do it all in the kernel:
The virtual driver itself shouldn't be too much work, at least, though it will require some time to get up to speed with kernel dev. Unfortunately, the documentation is pretty thin for serial port drivers - the key is subclassing the IOSerialDriverSync abstract class. Just about the only description I've seen is in Ole Henry Halvorsen's OSX and iOS Kernel Programming book. It also has a fragment of an example for the reading & writing operations. (disclosure: I was one of the tech reviewers for this book; I don't receive any incentives for recommending it - in this case it's literally the only documentation I know of) You can find the source for a complete serial port driver in Apple's USBCDC driver, AppleUSBCDCDMM is the class that actually represents the serial port node.
It's relatively straightforward to open a so-called "kernel control" socket in the kernel, the individual APIs are documented here; from user space you use the normal BSD socket send/recv APIs. (this is also described in the aforementioned book) Your daemon can then connect to that, and all you'd need to do is push the data between the socket and the virtual serial port device. You'll need to handle disconnect events and such correctly of course.
Still, I think this is achievable as a first kernel project for an experienced C programmer (with some C++).
I hope that helps!
I'm writing an IPsec implementation for a microcontroller and I want to test it using a standard Linux box running Debian Lenny. Both devices should secure the communication between them using IPsec ESP in tunnel mode. The keys are setup manually using setkey. There's no (or at least should be no) user space program involved in processing an IPsec packet. Now I want to see how my created packets are processed by the Linux kernel. To see the raw packets I capture them using tcpdump and analyze them using wireshark.
What's the best way to obtain debug information about IPsec processing?
How can I figure out whether the packet is accepted by the kernel?
How can I view the reason for a packet to be dropped?
You can instrument the XFRM (or perhaps ipv4/esp.c) kernel code to print out debug messages at the right spots.
For example, in net/ipv4/esp.c there exists a function esp_input() which has some error cases, but you'll see most the interesting stuff is in the xfrm/*.c code.
That said, I didn't have a problem interoperating a custom IPSec with Linux. Following the 43xx specs and verifying the packets came out correctly via wireshark seemed to do well. If you're having issues and don't want to instrument the kernel then you can setup iptables rules and count the number of (various type of) packets at each point.
Finally, be sure you've actually added a security policy (SP) as well as a security association (SA) and setup firewall rules properly.
I have a small TCP server that listens on a port. While debugging it's common for me to CTRL-C the server in order to kill the process.
On Windows I'm able to restart the service quickly and the socket can be rebound. On Linux I have to wait a few minutes before bind() returns with success
When bind() is failing it returns errno=98, address in use.
I'd like to better understand the differences in implementations. Windows sure is more friendly to the developer, but I kind of doubt Linux is doing the 'wrong thing'.
My best guess is Linux is waiting until all possible clients have detected the old socket is broken before allowing new sockets to be created. The only way it could do this is to wait for them to timeout
is there a way to change this behavior during development in Linux? I'm hoping to duplicate the way Windows does this
You want to use the SO_REUSEADDR option on the socket on Linux. The relevant manpage is socket(7). Here's an example of its usage. This question explains what happens.
Here's a duplicate of this answer.
On Linux, SO_REUSEADDR allows you to bind to an address unless an active connection is present. On Windows this is the default behaviour. On Windows, SO_REUSEADDR allows you to additionally bind multiple sockets to the same addresses. See here and here for more.
On a win32 multiple nic computer, how to force DNS resolving through gethostbyname() on a specific nic if all nics have different DNS configured and have the same metric ?
Otherwise, how to know which DNS will be used to resolve names each time a gethostbyname() call will be performed by the application ?
You can't do this, at least I'm fairly certain you can't specify an interface to send out the queries from using gethostbyname() or any of the standard socket utilities. (There might be a very esoteric win32 option for this, but I'm betting against it)
If you absolutely need this functionality, you'll need to pick a third party DNS library that provides you with such an ability ... or even write one from scatch.
The library will need to provide you with a means of binding the UDP socket that will be issuing the DNS queries to a specified address.
There also might be a way of configuring Windows to issue DNS queries from an interface using system settings, but I strongly doubt there is a means of doing this from within a program.
That might be better answered at https://serverfault.com/ It's a site geared more toward administering a machine. SO is best for programming.
Consider to use raw sockets and implement your own DNS query mechanism.
The cross platform dev environment I use has a built in function that is supposed to indicate whether or not a tcp port is available. However, the function malfunctions under Vista and always returns "available".
Is there an easy way, such as a dll function, I can use to correctly determine this information without needing .Net?
You can attempt to bind to and listen on the port using the usual Winsock functions. If something else is already listening on the same port, you will get an error (WSAEADDRINUSE from bind()).
To avoid bringing in added dependencies or windows-specific code you could simply try to use the port and catch any problems (such as interception by firewall software).
Simply use Win32 Nw apis to enumerate TCP ports.