I've to write an application on Linux that has the requirement to talk with a device with custom Ethernet type. There are many solutions even in SO how to write such an application. A drawback is that for this root access is needed (AFAIK). Releasing the root rights afterwards could be an option, but it raises the problem that the program is developed in an IDE, which I don't like to run as root. In my special case the main application is written in Python which would mean to give root access to the whole Python interpreter. I'm looking into possible alternatives. E.g.
Writing a tiny UDP/TCP server that redirects every raw packet over TCP/UDP. This could be written in Python as well. Only this tiny application needs root rights.
Using socat for redirection, unfortunately I'm unable to find an option to only care about one Ethernet type on not get overflowed by IP packets.
Any other ideas?
I think you only need to be root, or have CAP_NET_RAW, to open the socket. Once the socket is open, you can be any user you like.
So have either:
A setuid helper program which opens a raw socket, binds it (if necessary), then drops its root privileges and exec's your main program, keeping the socket open and passing the file descriptor number somehow (command line? Environment variable?)
A setuid helper which will pass an open file descriptor using another mechanism (e.g. unix socket)
A root-owned daemon which passes such an open socket descriptor to other programs upon request
Related
I have an application that I inherited that listens on port 7001 for UDP broadcasts from our in-house test equipment, and I recently updated another application that needs to do the same thing. Both applications must be able to coexist on the same computer.
Currently, when my recently updated application attempts to bind to the port to listen for UDP broadcasts and fails, it simply reports that the port is not available and suggests that the inherited application is probably running. How can I get my application to detect what application is actually listening on that port? I've done a Google search and have even searched this site, but so far I have been unable to find anything except to use Task Manager, TCPView, or netstat at the command line.
I would prefer a technique that either uses the Windows API or a Windows system COM component, since both applications are written in Visual Basic 6.0. (I know, I know, but I must maintain these applications since they are mission critical.) However, a .NET solution would would also be useful in case I need it in my new development efforts.
Use:
netstat -n -o
That will show the process ID and from there you can either look in the Task Manager's process viewer, go to menu View → Columns... and check the Process ID (PID). Then you can see the name of the process listening on that port.
Of course, you're wanting a programmatic way of accomplishing this and the GetTCPTable2 API is best as was already suggested. In fact, if you look at the IAT (Import Address Table) for netstat.exe, it actually uses that API to get that information.
There is a way to communicate directly with a command window and get its output using pipes and it would work fine, but the ideal way is to simply use the same API netstat uses.
I'm developing Firefox addon that communicate with external program by sockets. This program create local socket server on specified port when this addon need it. I would like to ckeck from this addon whether this application has opened this port already.
On Win7 when server isn't created yet I receive in socket created by addon NS_ERROR_CONNECTION_REFUSED in nsIRequestObserver::onStopRequest but if I can feel certain port isn't open when I receive this error?
You try to connect and see if the connection succeeds.
If it doesn't, then the port is not reachable (open).
That's the most obvious and easiest answer.
Other low-level solutions would require polling the OS itself somehow. That would be cross platform specific (so you'd need to write an implementation per platform) and also there is no API readily available so you'd have to mess around with C/C++ or at least js-ctypes, or hack together some ugly "execute this program and check output" stuff. All of which doesn't worth the fuzz.
If you want to find out which "inbound ports" are in use in windows you can use cmd,
if you don't know how to open cmd - open the run dialog by pressing windows-key+r. type cmd and hit enter
type netstat -a and hit enter and it will list all "listening" ports.
more info - http://www.techrepublic.com/blog/it-security/list-open-ports-and-listening-services/
My goal is to remotely write code. So far, I have been using ssh + screen + an editor (e.g. vim).
I understand using a local emacs (or vim), one can edit remote files. But once the local emacs is closed and I want to reopen it (or open it using another computer), I would need to reopen all the buffers again.
Is there a way to set up a emacs server on the remote machine and I could simply access it using a local emacs client? Which essentially simulate the screen behavior.
I think you might find your answer here;
http://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html
According to http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html#emacsclient-Options ;
An Emacs server usually uses an operating system feature called a “local socket” to listen for connections. Some operating systems, such as Microsoft Windows, do not support local sockets; in that case, Emacs uses TCP instead. When you start the Emacs server, Emacs creates a server file containing some TCP information that emacsclient needs for making the connection. By default, the server file is in ~/.emacs.d/server/. On Microsoft Windows, if emacsclient does not find the server file there, it looks in the .emacs.d/server/ subdirectory of the directory pointed to by the APPDATA environment variable. You can tell emacsclient to use a specific server file with the ‘-f’ or ‘--server-file’ option, or by setting the EMACS_SERVER_FILE environment variable.
Even if local sockets are available, you can tell Emacs to use TCP by setting the variable server-use-tcp to t. One advantage of TCP is that the server can accept connections from remote machines. For this to work, you must (i) set the variable server-host to the hostname or IP address of the machine on which the Emacs server runs, and (ii) provide emacsclient with the server file. (One convenient way to do the latter is to put the server file on a networked file system such as NFS.)
When the Emacs server is using TCP, the variable server-port determines the port number to listen on; the default value, nil, means to choose a random port when the server starts.
Of course, make sure to adjust your firewall settings on the server side, so that clients may connect to the machine running the emacs-server.
I've attempted the method mentioned in the other post many times and have never had any success with it.
One nice thing that emacs is able to do is desktop-save-mode which will store all of your open buffers when you kill emacs and restore them when you open emacs again. By default it won't restore tramp buffers, but you can tweak the settings to allow this to happen. More information can be found in this Stack Overflow question.
You can login locally and then ssh to a remote machine. On the remote machine, you can have 'screen session, that you can join'. In this session, you have emacs running, with all buffers as you had left. You can also use the desktop-save in combination to this, in the case that remote machine need to be restarted, and you can lose your session. This is the most practical solution, I use. You can change the 'client computer' any time. You don't need to use local emacs client. You can also make multiple session for different projects and join screen session for a particular project on different terminal.
For example http://www.utorrent.com/testport?port=12345
How does this work? Can the server side script attempt to open a socket?
There are many ways of accomplishing this through server-side scripting. As #Oded mentioned, most server-side handlers are capable of initiating socket connections on arbitrary ports, and most of those even have dedicated port-scanning packages/libraries (PHP has one in the PEAR repository, Python's 'socket' module makes this type of tasks a breeze, etc...)
Keep in mind that on shared host platforms, socket connections are typically disabled for security purposes.
Another way that is also very easy to accomplish is to use a command-line port-scanner such as nmap from your server-side script. i.e in PHP, you would do echo ``nmap -p $port $ip\
The server side script will try to open a connection on the specified port to the originating IP.
If there is no response (the attempt will timeout), this would be an indication that the port is not open.
The server can try, as #Oded said. But that doesn't ensure the receiver will respond.
Typically, something like this happens:
The URL request contains instructions about which port to access. The headers that your browser sends include information about where the request is originating from.
Before responding to the request, the server tries to open a port and checks if this is successful. It waits a while before timing out.
The webpage is rendered dynamically based on the results of this test.
The response is returned to you containing the results.
Sometimes steps (2) and (3) will be replaced with an AJAX callback, which allows the response to return sooner.
What is the best way to access a running mono application via the command line (Linux/Unix)?
Example: a mono server application is running and I want to send commands to it using the command line in the lightest/fastest way possible, causing the server to send back a response (e.g. to stdout).
I would say make a small, simple controller program that takes in your required command line arguments and uses remoting to send the messages to the running daemon.
This would be similar to the tray icon controller program talking to the background service that is prevalent in most Windows service patterns.
Mono's gsharp tool is a graphical REPL that lets you Attach to Process.
#Rich B: This is definately a suitable solution, which I already had implemented - however on the server I have to use, the remoting approach takes around 350ms for a single request.
I've measured the time on the server side of the request handling - the request is handled in less than 10ms, so it has to be the starting of the client program and the tcp connection, that takes up the time.
Hence the hope that I can find another way to post the requests to the server application.
You can use the system.net.sockets abstractions to create a service on a TCP port, and then telnet to that port.
Check the library status page; Mono's coverage here is a bit patchy.