I used netstat to find which ports are established and I tried to read from an established connection using ip and port. I am getting the following error.
Connection actively refused by the machine
No - you can only create a connection to a listening port. "Established" means there is already a connection between two sockets. You can't add a third socket to an existing connection.
If you want to eavesdrop on the connection, there are ways to do that - on Linux, you can create a SOCK_RAW or AF_PACKET socket to receive all packets. On Windows, you need to install the WinPcap or Npcap driver and use libpcap.
If you are just curious and don't need to intercept the connection from a program, you can also use the open source tool Wireshark to see what data your computer is sending and receiving.
Related
BitTorrent peers connect with each other via TCP (mainly). When a peer A tries to connect to peer B, does peer B also needs to try to connect with A simultaneously so the TCP 3-way handshake happens and they form a connection? If not, why?
Also, I have been studying three bittorrent client implementations. While they start TCP connections with the obtained peers, I noticed none of them opens a TCP socket to listen on the port they are announcing to the tracker. Does it mean no one can initiate connection to them? Shouldn't they create such TCP socket?
When a peer A tries to connect to peer B, does peer B also needs to try to connect with A simultaneously so the TCP 3-way handshake happens and they form a connection? If not, why?
Connection setup is a general TCP feature, not specific to bittorrent. One side initiates the connection by calling connect on an unconnected socket and the other side has a listening socket configured on which it calls accept in a loop to create create connection-specific sockets for each accepted incoming connection.
There is a simultaneous open flow for connection setup but that's rarely relevant and the connect/accept flow is used by bittorrent clients.
I noticed none of them opens a TCP socket to listen on the port they are announcing to the tracker.
They generally do and should unless process privileges are insufficient to bind a particular port or another process is already listening on it, in which case they should log a warning at least.
If you used a portscan then you may be seeing firewall or NATs getting in the way rather than the client not having a listening socket open. Instead you could use something like netstat (may need some additional arguments, depending on OS) to show listening sockets.
If they truly do not have a listening socket open then yes, that would be a problem since they could not accept incoming connections and only talk to a more limited set of clients (those that do).
Bittorrent being a peer-to-peer protocol means that clients should be equals (peers) which means they should be equally capable of initiating and accepting connections.
Is there any way to determine which Local Port was used by the Client (C#) to Establish a connection to a SignalR Hub? I have looked at properties of both the HubCallerContext and HubConnection, but it does not seem to be available.
The short answer the question: yes, using netstat or similar you can look at all the connections your client initiated to the SignalR. There you can identify the TCP source port number.
If for some reason you want to get this from inside the application you can either try to find your way via Get underlying tcp connection from HttpWebRequest/Response
or by following this answer.
I establish a TCP connection between my server and client which runs on the same host. We gather and read from the server or say source in our case continuously.
We read data on say 3 different ports.
Once the source stops publishing data or gets restarted , the server/source is not able to publish data again on the same port saying port is already bind. The reason given is that client still has established connection on those ports.
I wanted to know what could be the probable reasons of this ? Can there be issue since client is already listening on these ports and trying to reconnect again and again because we try this reconnection mechanism. I am more looking for reason on source side as the same code in client sides when source and client are on different host and not the same host works perfectly fine for us.
Edit:-
I found this while going through various article .
On the question of using SO_LINGER to send a RST on close to avoid the TIME_WAIT state: I've been having some problems with router access servers (names withheld to protect the guilty) that have problems dealing with back-to-back connections on a modem dedicated to a specific channel. What they do is let go of the connection, accept another call, attempt to connect to a well-known socket on a host, and the host refuses the connection because there is a connection in TIME_WAIT state involving the well-known socket. (Stevens' book TCP Illustrated, Vol 1 discusses this problem in more detail.) In order to avoid the connection-refused problem, I've had to install an option to do reset-on-close in the server when the server initiates the disconnection.
Link to source:- http://developerweb.net/viewtopic.php?id=2941
I guess i am facing the same problem: 'attempt to connect to a well-known socket on a host, and the host refuses the connection'. Probable fix mention is 'option to do reset-on-close in the server when the server initiates the disconnection'. Now how do I do that ?
Set the SO_REUSEADDR option on the server socket before you bind it and call listen().
EDIT The suggestion to fiddle around with SO_LINGER option is worthless and dangerous to your data in flight. Just use SO_RESUSEADDR.
You need to close the socket bound to that port before you restart/shutdown the server!
http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
Also, there's a timeout time, which I think is 4 minutes, so if you created a TCP socket and close it, you may still have to wait 4 minutes until it closes.
You can use netstat to see all the bound ports on your system. If you shut down your server, or close your server after forking on connect, you may have zombie processes which are bound to certain ports that do not close and remain active, and thus, you can't rebind to the same port. Show some code.
Socket Server with SSLStream some times refuses new connections from clients.
I used the telent hostname port, and it says Connecting To host...
Could not open connection to the host, on port 6002: Connect failed
I used netstat -a , and I see TCP status as
TCP 0.0.0.0:6002 host:0 LISTENING
I also see the service as listening in tcpview too.
The error I see on client side is connection refused with error code 10061.
The same socket server was accepting new connections and just runs fine without any issues.But after some time the above issue happens.its random.
When I restart the sockets it just works fine and accepts conenctions, which I don;t want to do it frequently.becasue this disconnects clients, who are already connected.
Could somebody help me to trouble shoot this?
Thanks.
Where are you running netstat? On the server?
Try connecting to the socket from localhost (from the server itself) using the destination IP address 127.0.0.1
Do the same test with the network IP of the server.
My guess is that the firewall is preventing external access or a router in between is preventing the connection.
It works for a while and then stops. Few options I can think of:
Some firewall on the way does some kind of throttling
You open and close too many connections too quickly. In this case you exhaust the ephemeral ports on the client (usually) and/or on the server. If you do netstat -a you will see a lot of sockets in TIME_WAIT state, try this both on client and server. Solution here is to reuse connections (best). Or increase the number of ephemeral ports (registry setting). But this will take you only so far.
You have a bug in your server and it stops accepting new connections after a while.
I have an FPGA device with which my code needs to talk. The protocol is as follows:
I send a single non-zero byte (UDP) to turn on a feature. The FPGA board then begins spewing data on the port from which I sent.
Do you see my dilemma? I know which port I sent the message to, but I do not know from which port I sent (is this port not typically chosen automatically by the OS?).
My best guess for what I'm supposed to do is create a socket with the destination IP and port number and then reuse the socket for receiving. If I do so, will it already be set up to listen on the port from which I sent the original message?
Also, for your information, variations of this code will be written in Python and C#. I can look up specific API's as both follow the BSD socket model.
This is exactly what connect(2) and getsockname(2) are for. As a bonus for connecting the UDP socket you will not have to specify the destination address/port on each send, you will be able to discover unavailable destination port (the ICMP reply from the target will manifest as error on the next send instead of being dropped), and your OS will not have to implicitly connect and disconnect the UDP socket on each send saving some cycles.
You can bind a socket to a specific port, check man bind
you can bind the socket to get the desired port.
The only problem with doing that is that you won't be able to run more then one instance of your program at a time on a computer.
You're using UDP to send/receive data. Simply create a new UDP socket and bind to your desired interface / port. Then instruct your FPGA program to send UDP packets back to the port you bound to. UDP does not require you to listen/set up connections. (only required with TCP)