bind() failed: Address already in use - c

I am implementing DNS server and DNS resolver and i am using socket programming in this. But i get error in function bind() as bind() failed and sendto() permission denied.
I had tried using different port numbers, also i am working as a root, but still it giving me same error.Please help me to solve those issues. Your answers are welcome. Thanks.
https://github.com/srijan/DNS-Server---Resolver/tree/c73a124a15f53eb985a4b4afc0dffedd432c8454

This error typically means some other socket in the system is open on the same port.
To see what other UDP sockets are open, run netstat -anu from the command line. You'll get a list of IP/port pairings. If you see one for port 53, that socket is conflicting with yours. If you are able to run as root and also use the -p option, it will additionally tell you the process number that owns each socket.

Run Netstat -anob with CLI in Windows.
C:\Windows\System32>socat TCP-LISTEN:443,fork,reuseaddr TCP:localhost:22
2021/02/01 16:22:41 socat[11240] E bind(5, {AF=2 0.0.0.0:443}, 16): Address already in use
C:\WINDOWS\system32>netstat -anob
Connexions actives
Proto Adresse locale Adresse distante État
TCP 0.0.0.0:22 0.0.0.0:0 LISTENING 5676
[sshd.exe]
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1244
RpcSs
[svchost.exe]
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 7396
[vmware-hostd.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
[vmware-hostd.exe] is the process that listen instead of [socat.exe].
In my case, I am using VMware Workstation 16 Pro and have disabled virtual machine sharing in Preferences, which is an deprecated option. All is now OK.
WMware Workstation Server deprecated

Related

How do I not destroy an UDP port when binding a socket?

I am using GCDAsyncUdpSocket to open an UDP socket and then I bind it to a port. The class is just a wrapper around the usual POSIX socket calls like socket, bind, etc.
SCENARIO 1:
MyMacBook: start process A
MyMacBook: open UDP port 23141 => SUCCESS
SomeComputer: send an UDP packet to MyMacBook, port 23141
MyMacBook: the standard OSX firewall asks me if i want to allow incoming network connections, and I agree.
MyMacBook: ignore packet, don't read it. (or at least, i don't see a log message that tells me that i got a packet. either my code is broken, or the CocoaAsyncSocket code is broken, or the OS didn't report the packet to my program.)
MyMacBook: kill process A
MyMacBook: start process A
MyMacBook: open UDP port 23141 => FAIL: Error Domain=NSPOSIXErrorDomain Code=48 "Address already in use" UserInfo=0x100407f30 {NSLocalizedDescription=Address already in use, NSLocalizedFailureReason=Error in bind() function
Why???
netstat -n |grep 2314
udp4 626 0 *.23146 *.*
udp4 1251 0 *.23141 *.*
^^this is how a broken UDP port looks like on the shell. If I ever want to use that port number again, I seem to have to restart my machine :-(
And no, I don't have old processes hanging around that block the port. I checked with ps aux and with lsof -i | grep UDP.
SCENARIO 2:
MyMacBook: start process A
MyMacBook: open UDP port 23143 => SUCCESS
MyMacBook: kill process A
MyMacBook: start process A
MyMacBook: open UDP port 23143 => SUCCESS
MyMacBook: kill process A
MyMacBook: start process A
MyMacBook: open UDP port 23143 => SUCCESS
MyMacBook: kill process A
...
If the port is never used, the system doesn't care if I dont close it nicely. This is how it should be.
My question:
What is wrong here? Of course, in a perfect world, a program wouldn't crash, and sockets are all closed with the POSIX close function. In an imperfect world, I just type Cmd-. in XCode to kill the app I am developing, and close isn't called.
When I am trying to bind my socket to an UDP port, what I am really trying to say to the OS is this: "Please OSX 10.8.5, bind my socket to port 23141. If some other program has it opened currently and is listening, then you may tell me that the port is in use, but if no running program cares about this port, then let me bind it to port 23141!!" Is this an OSX bug? Is it new? Is it a documented known bug, or a so-called "feature"?
This seems to be a bug in OSX.
Related posts:
https://superuser.com/questions/504750/kill-udp-port-that-has-no-process
https://apple.stackexchange.com/questions/71300/how-can-i-unbind-a-udp-port-that-has-no-entry-in-lsof
(#Barmar: thanks for finding these articles)
1) I have noted, that if a UDP port is broken (it is bound, but not bound to a particular process), then you have to restart the computer to use this port again. Logging off, and logging in again doesn't work.
2) I found out, that there is no problem if you disable the OSX Firewall. This means that the problem is a bug in the standard OSX firewall. However, a broken port doen't get unbroken if you disable the firewall, you still have to restart your computer to unbreak it. But: if the firewall is off, no port becomes broken.
There is something we can learn from part 2: the OSX firewall is not a simple packet filter. It seems to hack the socket commands on a kernel level.
Maybe someone wants to write a bug report and send it to Apple... (sounds like a joke, doesn't it?)

UDP Port access

I have a small server program in C which prints a message to the client. This program uses UDP Port for communication.
My question is: Is there a way or application by which I can test the functionality of my program from my windows machine. Example, if I type in some command, I can see the response from my program on my computer.
telnet xx.xx.xx.xx. PortNum, I believe telnet wpuld not work.
Not aware of any existing tools. I assume your server receives a message from the client and sends a response message back. If this is correct, create a basic client program which sends a message (sendto()) and then calls recvfrom() (default is blocking mode on my platform), then print the response message received. This works well for me. Don't have time to ferret around for an example (which is on linux) but you should be able to use an example udp client for windows from the web, I imagine. Let me know if you would like my client program as a template.
I think you may want to use netcat; if it's installed on your machine, it's typically executed by "nc"
netcat can connect to or listen on tcp or udp ports; -u is udp.
nc -u host port # connect to a udp port
nc -u -l 127.0.0.1 1026 # listen on port 1026, in udp mode.
etc.

ZeroMQ, how to connect to external tcp socket?

Can you please tell me how you can use to send messages ZeroMQ between two programs located on different servers using some common socket?
With all local sockets program works, but I do not understand how they spread to different places. Because climbs error:
Traceback (most recent call last):
File "/Users/*****/Projects/*****/workers/internal_links_parser.py", line 20, in <module>
socket.bind("tcp://***.***.***.***:5000")
File "socket.pyx", line 447, in zmq.core.socket.Socket.bind (zmq/core/socket.c:4312)
zmq.core.error.ZMQError: Can't assign requested address
Explain, please, and if not difficult to give an example. Thx!
From the zmq socket manual on Socket.bind;
This causes the socket to listen on a network port. Sockets on the other side of this connection will use Socket.connect(addr) to connect to this socket.
In other words, this will tell 0mq to listen to a local port for incoming connections; you should use something like socket.bind("tcp://0.0.0.0:5000") to listen to all of the machine's IP addresses on port 5000.
The other side of the connection should use Socket.connect with an URL something like socket.connect("tcp://remoteip:5000") to connect to the other side listening.
It would seem from the error message that you're trying to bind to the remote address instead of binding to the local and connecting to the remote.
Don't forget to check the firewall. It should be inactive.
Also, you can check to know if the server is accessible or not with telnet:
telnet serverIPaddress serverPortNo

C Get IP for listening server

I am writing a client/server program using C sockets. I am specifying that the server can listen on any network interface by using INADDR_ANY in sockaddr_in.sin_addr.s_addr. This is equivalent to an IP of 0.0.0.0. Is it possible for me to get the actual IP that the server is listening on? (e.g. 192.168.1.100)
When you bind a listening socket to INADDR_ANY, the socket listens on all available local IPs. There is no way to determine from the socket which IP(s) it is listening on. If you need that information, then you have to enumerate the local IPs separately (in which case you could just bind() each IP to its own socket individually if you need to retreive pre-accept binding details). However, once accept() has returned an established client connection, you can use getsockname() on the accepted socket to know which specific IP accepted the connection.
I have finally been able to find a solution that works.
Edit: link is dead so see: Internet Archive link.
Hopefully it can be helpful to others as it has been to me.

Error: Address already in use while binding socket with address but the port number is shown free by `netstat`

I tried to bind my socket(server socket) at port number 8000. It worked and did the job for me. At the end of the code I close the socket as well. The very next instant I run my code again and it shows me that the address is already in use. I have printed the meaning of error values strerror(errno); to see if my code working properly at each point. To check if the port is free I checked it using netstat but it shows that port number 8000 is free. It has happened with me a lot of times. Every time I then wait for a few more secs and then it starts working again. I am using c language. So what is he reason for this behavior by my OS.
After a few more secs I run the code and then it works.
anirudh#anirudh-Aspire-5920:~/Desktop/testing$ sudo ./a.out
Socket Creation: Success
File open: Success
Socket Bind: Address already in use
Socket Listen: Address already in use
^C
anirudh#anirudh-Aspire-5920:~/Desktop/testing$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1348/lighttpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 984/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1131/cupsd
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1211/mysqld
tcp6 0 0 :::22 :::* LISTEN 984/sshd
tcp6 0 0 ::1:631 :::* LISTEN 1131/cupsd
anirudh#anirudh-Aspire-5920:~/Desktop/testing$ sudo ./a.out
Socket Creation: Success
File open: Success
Socket Bind: Address already in use
Socket Listen: Address already in use
^C
anirudh#anirudh-Aspire-5920:~/Desktop/testing$
I've run into that same issue as well. It's because you're closing your connection to the socket, but not the socket itself. The socket can enter a TIME_WAIT state (to ensure all data has been transmitted, TCP guarantees delivery if possible) and take up to 4 minutes to release.
or, for a REALLY detailed/technical explanation, check this link
It's certainly annoying, but it's not a bug. See the comment from #Vereb on this answer below on the use of SO_REUSEADDR.
I know its been a while since the question was asked but I was able to find a solution:
int sockfd;
int option = 1;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &option, sizeof(option));
This set the socket able to be reused immediately.
I apologize if this is "wrong". I'm not very experienced with sockets
Try netstat like this: netstat -ntp, without the -l. It will show tcp connection in
TIME_WAIT state.
As already said, your socket probably enter in TIME_WAIT state. This issue is well described by Thomas A. Fine here.
To summary, socket closing process follow diagram below:
Thomas says:
Looking at the diagram above, it is clear that TIME_WAIT can be
avoided if the remote end initiates the closure. So the server can
avoid problems by letting the client close first. The application
protocol must be designed so that the client knows when to close. The
server can safely close in response to an EOF from the client, however
it will also need to set a timeout when it is expecting an EOF in case
the client has left the network ungracefully. In many cases simply
waiting a few seconds before the server closes will be adequate.
Using SO_REUSEADDR is commonly suggested on internet, but Thomas add:
Oddly, using SO_REUSEADDR can actually lead to more difficult "address
already in use" errors. SO_REUSADDR permits you to use a port that is
stuck in TIME_WAIT, but you still can not use that port to establish a
connection to the last place it connected to. What? Suppose I pick
local port 1010, and connect to foobar.com port 300, and then close
locally, leaving that port in TIME_WAIT. I can reuse local port 1010
right away to connect to anywhere except for foobar.com port 300.
Just type
unlink [SOCKET NAME]
in the terminal, then the error should no longer exist.
Even icfantv's answer to this question is already perfect, I still have more findings in my test.
As a server socket in listening status, if it only in listening status, and even it accepts request and getting data from the client side, but without any data sending action. We still could restart the server at once after it's stopped. But if any data sending action happens in the server side to the client, the same service(same port) restart will have this error: (Address already in use).
I think this is caused by the TCP/IP design principles. When the server send the data back to client, it must ensure the data sending succeed, in order to do this, the OS(Linux) need monitor the connection even the server application closed this socket.
But I still believe kernel socket designer could improve this issue.
For AF_UNIX you can use call unlink (path); after close() socket in "server" app
the error i received was:
cockpit.socket: Failed to listen on sockets: Address already in use
the fix I discovered is:
I had to disable selinux
in /usr/lib/systemd/system/cockpit service i changed the
line :
#ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws --selinux-type=etc_t
to:
#ExecStartPre=/usr/sbin/remotectl certificate --ensure --user=root --group=cockpit-ws
so as you can see i took out the argument about selinux
then i ran:
systemctl daemon-reload
systemctl start cockpit.service
then I browsed to:
I accepted the self-signed certificate and was
able to login successfully to cockpit and use it normally.
this is all on a fedora25 machine. the 9090 port had already
been added using firewall-cmd

Resources