When I try to bind a socket using linux bind call. it return error 63 (Out of streams resources). I tried to explore (using google) why this error is coming and how to reproduce it but I had no luck. This problem is happening at one of the setup where I do not have direct access. I want to understand why this error is coming and want to recreate the problem. I am using Opensuse linux.
Any help would be really appreciable.
Error 0x63 is EADDRNOTAVAIL, which means you're trying to bind to an address that's already in use. Make sure you are not already running an instance of your program (which would have bound the port), and that there's not something else using the port.
The command
netstat -nat
will tell you if the port is in use. If you have root access you can add an option (-p on linux) that will also tell you which process has the port open.
There's also the lsof and/or fuser commands (depending on your flavor of Linux/Unix) to list open file handles and the owning processes. These also require root or sudo access.
Related
In my application, I bind a socket to the port 38614.
While in test, I find sometime the port is used by another application.
So I failed to bind on it and get the error, "Address already in use".
I did some research, and find I could set the parameter /proc/sys/net/ipv4/ip_loca_port_range to reserve the port for my application.
So I add a new line "net.ipv4.ip_local_port_range = 50000 60000" to the file /etc/sysctl.conf.
Then I reboot the system.
But I still find a port 34660 out of the range which I set is used by some application.
[root#xxxx ~]# netstat -apn | grep fe80::cef1:3
tcp6 0 0 fe80::cef1:12345 fe80::cef1:34660 ESTABLISHED 2401/xxxx
So what should I do to reserve some ports for my application?
Could anyone give me some advice?
Another method is using a small port, such as 1001 which is not used by any other application, but I do not think it is a good idea for the ports smaller than 1024 are reserved for well-known ports.
===============================================================
I have found the answer of the question "how do I reserve ports for my application?"
While I don't think it is a good idea, for it is difficult to make sure that our application runs earlier than any other application. Actually my application has to start after another application which does some prepare for my application.
The linux system may assign any port in the port pool to any application when it need a port.
===============================================================
The parameter "ip_local_reserved_ports" is similar to "ip_local_port_range", they are in the same folder, and it is much more difficult to be tested. In my test the parameter "ip_local_port_range" doesn't work as our expect, so I don't believe the "ip_local_reserved_ports" is ok.
B.R.
Forward
The idea to reserve the port is to block the usage of this port for an outgoing connection. I mean if you have a potential service that will open for LISTEN the port 8080, if you don't reserve it, and the range of ports include this port, could conflict with a outgoing connection that randomly uses 8080 as "source port".
I'm quoting answers of how do I reserve ports for my application?
You could try with:
sysctl -w net.ipv4.ip_local_reserved_ports = 49000, 49001
drop it in /etc/sysctl.conf, and then run sysctl -p.
To ensure the kernel won't give out 49000 and 49001 to clients as you wish to use them for your servers on linux.
Note that this is untested.
However, this is the accepted answer to the question:
Technically, there's no such thing as a "reserved port".
In TCP/UDP, the only way to "reserve" a port is to actually bind() a socket to it. A bound port will not be used by other applications; an unused port is, well, unused so other applications are free to use it.
If you are writing server software, then you can bind your sockets to specific ports as early as you want in the application code. Make the port numbers configurable, or at least clearly state them in the documentation, so that a systems administrator can quickly identify clashes and move conflicting applications to separate servers.
I have problem to open a listening port from localhost in a heavy loaded production system.
Sometimes some request to my port 44000 failed. During that time , I checked the telnet to the port with no response, I'm wonder to know the underneath operations takes there. Is the application that is listening to the port is failing to response to the request or it is some problem in kernel side or number of open files.
I would be thankful if someone could explain the underneath operation to opening a socket.
Let me clarify more. I have a java process which accept state full connection from 12 different server.requests are statefull SOAP message . this service is running for one year without this problem. Recently we are facing a problem that sometimes connection from source is not possible to my server in port 44000. As I checked During that time telnet to the service is not possible even from local server. But all other ports are responding good. they all are running with same user and number of allowed open files are much more bigger than this all (lsof | wc -l )
As I understood there is a mechanism in application that limits the number of connection from source to 450 concurrent session, And the problem will likely takes when I'm facing with maximum number of connection (but not all the time)
My application vendor doesn't accept that this problem is from his side and points to os / network / hardware configuration. To be honest I restarted the network service and the problem solved immediately for this special port. Any idea please???
Here's a quick overview of the steps needed to set up a server-side TCP socket in Linux:
socket() creates a new socket and allocates system resources to it (*)
bind() associates a socket with an address
listen() causes a bound socket to enter a listening state
accept() accepts a received incoming attempt, and creates a new socket for this connection. (*)
(It's explained quite clearly and in more detail on wikipedia).
(*): These operations allocate an entry in the file descriptor table and will fail if it's full. However, most applications fork and there shouldn't be issues unless the number of concurrent connections you are handling is in the thousands (see, the C10K problem).
If a call fails for this or any other reason, errno will be set to report the error condition (e.g., to EMFILE if the descriptor table is full). Most applications will report the error somewhere.
Back to your application, there are multiple reasons that could explain why it isn't responding. Without providing more information about what kind of service you are trying to set up, we can only guess. Try testing if you can telnet consistently, and see if the server is overburdened.
Cheers!
Your description leaves room for interpretation, but as we talked above, maybe your problem is that your terminated application is trying to re-use the same socket port, but it is still in TIME_WAIT state.
You can set your socket options to reuse the same address (and port) by this way:
int srv_sock;
int i = 1;
srv_sock = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(srv_sock, SOL_SOCKET, SO_REUSEADDR, &i, sizeof(i));
Basically, you are telling the OS that the same socket address & port combination can be re-used, without waiting the MSL (Maximum Segment Life) timeout. This timeout can be several minutes.
This does not permit to re-use the socket when it is still in use, it only applies to the TIME_WAIT state. Apparently there is some minor possibility of data coming from previous transactions, though. But, you can (and should anyway) program your application protocol to take care of unintelligible data.
More information for example here: http://www.unixguide.net/network/socketfaq/4.5.shtml
Start TCP server with sudo will solve or, in case, edit firewalls rules (if you are connecting in LAN).
Try to scan ports with nmap (like with TCP Sync Handshake), or similar, to see if the port is opened to any protocol (maybe network security trunkates pings ecc.. to don't show hosts up). If the port isn't responsive, check privileges used by the program, check firewalls rules maybe the port is on but you can't get to it.
Mh I mean.. you are talking about enterprise network so I'm supposing you are on a LAN environment so you are just trying to localhost but you need it to work on LAN.
Anyway if you just need to open localhost port check privileges and routing, try to "tracert" and see what happens and so on...
Oh and check if port is used by a higher privilege service or deamon.
Anyway I see now that this is a 2014 post, np gg nice coding byebye
I am interested in finding out when things SSH into my boxen to create a reverse tunnel. Currently I'm using a big hack - just lsof with a few lines of script. So my goal is to see when a socket calls bind() and, ideally, get the port it binds to (it's listening locally since it's a reverse tunnel) and the remote host that I would be connecting to. My lsof hack is basically fine, except I don't get instant notifications and it's rather... hacky :)
This is easy for files; once a file does just about anything, inotify can tell me in Linux. Of course, other OSs have a similar capability.
I'm considering simply tailing the SSHD logs and parsing the output, but my little "tunnel monitor" daemon needs to be able to figure out the state of the tunnels at any point in time, even if it hasn't been running the whole time SSHD has.
I have a pretty evil hack I've been considering as well. It's a script that invokes GDB on /usr/sbin/sshd, then sets a breakpoint on bind. Then it runs it with the options -d -p <listening port> -- Running a separate SSHD for these tunnels is fine. Then it waits for that breakpoint to get hit, and uses GDB's input to get the remote hosts's IP address and the local IP on which SSH is now listening. Again, that's text parsing and opens some other issues.
Is there a "good" way to do this?
I would use SystemTap for a problem like this. You can use it to probe the kernel to see when a bind is done by any process on the system. http://sourceware.org/systemtap/
I'm trying to write an application that runs as a daemon and monitors
running X sessions. Right now I'm struggling to find documentation
regarding the X security model. Specifically, I'm attempting to
connect to running X displays from my daemon process. Calling
XOpenDisplay(dispName) doesn't work, I guess because my process
doesn't have permission to connect to this display. After a bit of
research, it looks like I need to do something with xauth.
In my test environment, the X server is started like this:
/usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-QBEVDj
That file contains a single entry, that looks like this:
#ffff##: MIT-MAGIC-COOKIE-1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
by adding an entry to ~/.Xauthority with the same hex key, I can
connect to the X server. However, this is difficult because I need to
programmatically find the auth file the X server is using (the
location of which I guess will change from distro to distro, and
probably from one boot to the next), then query it, then write a new
auth file. If the process is running as a daemon, it might not have a
home directory, so how do I know where to write the new entries to?
Ideally, what I'm looking for is a way to bypass the need to have the
xauth cookie in ~/.Xauthority, or even to know what the cookie is at
all. I realise that this is unlikely - what good is a security model
if it's easily bypassed? but I'm hoping someone on this list may have
a few good ideas. Is there a way to specify that my process is
privileged and thus should automatically be given access to any
display on the local machine?
You don't have to use a home directory if you specify an XAUTHORITY environment variable, which specifies the location of the .Xauthority file. Read the xauth man page.
But, in general, it's hard to locate the auth file, for the reasons you mentioned; also, this "fishing for auth tokens" approach would only work for local displays.
With regard to letting root (or some other user) connect to an X server willy-nilly, you'd probably have to patch the source code to do this, and you'd have to use something like getpeereid to obtain the connecting user's uid/gid (this only works on Unix-domain sockets, which I presume would be the type used for local connections, anyway).
Xauth is not the only security mechanism for X
There is also another one (less secure) that just performs IP based authentication
(See xhost).
So if you switch your X server to this less secure mode it will trust any connections coming
from the defined set of IPs.
This way you do not need to deal with Xauthority at all.
My only way of communication with my embedded device is a serial port. By default, embedded Linux uses this port as a terminal. How do I disable this terminal and use the serial link to transfer binary data? I heard of commands like rx and tx but i cannot find them.
I think I can just read() from and write() stuff to /dev/tty but I want to make sure no error messages or whatever mess with my data stream.
You can use an application like xmodem to transfer file over any terminal. Is the serial port you speak off a terminal, or is it also the kernel console.
If you're kernel is not noisy, then you can use your current connection to make xmodem like transfer. On the host side, you can use kermit, which is nice AND scriptable.
If you want to make your serial port raw, and you have file descriptor ttyfd opened,
here is one way to do it :
struct termios tty, orig_tty;
...
if(tcgetattr(ttyfd, &tty) < 0)
{
// error checking
}
// backup tty, make it raw and apply changes
orig_tty = tty;
cfmakeraw(&tty);
if(tcsetattr(ttyfd, TCSAFLUSH, &tty) < 0)
{
// error checking
}
...
//end of program or error path :
tcsetattr(ttyfd, TCSAFLUSH, &orig_tty)
Don't forget to restore the setting at the end of your program if you still want a good behaved terminal.
Can't you just set the terminal to raw?
Have a look at this tutorial.
To disable the Linux console you have to change the Linux command line create by the bootloader from :
console=/dev/ttyS?
to :
console=null
You can run on the terminal a command that will transfer the data through an application-level protocol. The rx and tx commands you refer to implement the XMODEM file transfer protocol. It could be a solution, if the binary data you want to transfer consists of files, the throughput demands are low, and you don't mind the administrative overhead of running the commands. Alternatively, you may want to multiplex the serial port for handling both data transfer and the terminal. Disable the serial terminal driver command (getty), and run the PPP protocoll over the serial line to establish an IP connection to your device. You can then login to the device through ssh or telnet and transfer your data through an IP socket.
As the other notes have implied, there are several things to check, collected here:
Make sure the linux kernel isn't using the serial port. Make sure there is either no console= option on the bootload command in your grub file. It usually isn't there by default.
Make sure there is no getty running on the serial port. Look in /etc/inittab for an entry for /dev/ttyS0 (serial port A) and comment it out if it is there.
Make sure the /dev/ttyS0 is readable and writable by your process. You might create a specific user under which the control program is run, and which owns the /dev/ttyS0, then chmod 700 /dev/ttyS0. This will help make sure some other user/program doesn't also try using the serial port.
Use open() on ttyS0 to get an fd, then use the tcsetattr family of routines to set the line speed and discipline.
Terminal programs probably won't be useful to you unless you can run the same program on the embedded device to manage the other end of the connection.
Yes, all of your serial ports are in /dev/ttyxx. Note that /dev/tty is a shortcut that stands for your current terminal, not a specific serial port. Often, these are owned by root, and require you to either have privileges or be in the adm group to access the device directly from your application.
You may want to chown the device so you can access it. I'm not sure what the consequence of changing device ownership are; IIRC, it's easy to do and works nicely. The alternative is to use setuid to elevate your program to a privileged state.
There's a program named getty that lets users login from a serial port. Your inittab will start getty on serial ports so people can login.
You want to disable getty. In some cases, there's a port manager that helps do this.
In some cases, you can change your inittab to use mgetty, which is a smarter and easier to control version of getty.