In my application, I have a server listening on a port on localhost for client connection. Then I have clients running and establishes connection with the server. I used tcpListner in c# for the server and the clients were written in perl using Inet function.
The connection between clients and server were established without a problem and a message from client is received by the server. However, after about 3 to 4 seconds, the connection is lost. I use netstat -a to see if the status of the connection is still "established". The result is "Close_wait" after I use netstat command on DOS.
How can I debug this problem? Which side is causing the lost of connection?
Thanks
Edit:
$tx_socket = IO::Socket::INET->new( PeerAddr => '127.0.0.1', PeerPort => 9000,
LocalPort => 8000, Proto => 'tcp',
Type =>SOCK_STREAM, Reuse=>1 ) or die("$!\n");
die("init_tx_socket failed!\n") unless $tx_socket; print "Socket good!\n";
$tx_socket->autoflush(1); $tx_socket->print("Hello");
sleep(5);
$tx_socket->print("World");
Capturing network packets with Microsoft Network Monitor or Wireshark, or use System.Net tracing.
Socket issues cannot be easily analyzed and handled without such analysis.
Related
I am trying to create tcp connection.
I am sending tcp SYN and getting SYN-ACK.
Afterwards, I am sending ACK message.
However, before my last ACK is sending I am getting RST reset packet. I can see that using wireshark sniffer.
I am writing my code in C# , an using pcap .NET library, over Win7.
How can I fix the problem and what makes it happen?
Your problem is, that your OS receives a SYN/ACK that it cannot associate on a source port and thus the OS TCP/IP stack sends a RST.
What do you exactly want to do? You could suppress the RST with a local firewall.
I tried to play around with malware stranger sent me. I open it in vmware and run microsoft network monitor
screenshot
So I tried to make tcp connection using C# like this:
TcpClient tcpclnt = new TcpClient();
Console.WriteLine("Connecting.....");
tcpclnt.Connect("darcometweb.no-ip.org", 225);
tcpclnt.Close();
but it throws exception: Message "No connection could be made because the target machine actively refused it 95.244.217.192:225"
To make sure I also tried it in Python but it also throws the same exception
import socket
s = socket.socket()
host = 'darcometweb.no-ip.org'
port = 225
s.connect((host,port))
s.close
print 'done'
Anyone knows what is wrong ?
# Syed Ali Taqi: I have looked into that question, however in my case the malware can make connection but my c# app can't
Usually happens when the port is closed/ no port forwarding on the router/ firewall or anti virus blocking the connection.
First open command line and type
netstat -a
to see all the open connections and ports, if your port listed then go to
Open port checker and type in your port to see if there is an access from outside your network.
If no i would go with port forwarding then, windows firewall, anti virus.
I set up Thrift to build two entities and a corresponding service. I genereated the code for C#, created a small console application for the server and another one for a test client. I ran both on my local machine and it worked like a charm. But when deploying the server on my Azure VM running Windows Server 2012, with an endpoint created on port 9090 for TCP, my client can't connect. There's a timeout.
Similar questions on SO: This one is about a php library specific problem and this one is about two linux machines. The latter one is close to my question, but I can imagine my problem is Windows or Azure VM specific.
I'm using Thrift 0.9.0.0 from NuGet. I tried SimpleServer and ThreadPoolServer. This is what I'm doing on the server:
Thrift.Server.TServer server = new Thrift.Server.TThreadPoolServer(new TodoThriftService.Processor(new TodoThriftServiceHandler()), new TServerSocket(9090));
This is what I'm doing on the client:
TodoThriftService.Client client = new TodoThriftService.Client(new TBinaryProtocol(new TSocket("my.host.com", 9090)));
I also tried the server IP address instead of its host name, but it didn't work either.
netstat -an output is:
TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING
Output from telnet from client (telnet my.host.com 9090):
Verbindungsaufbau zu my.host.com...Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 9090: Verbindungsfehler
Which is German for "connection error".
When I visit http://canyouseeme.org/ on the server and check port 9090 the output is:
Error: I could not see your service on 123.34.567.890 on port (9090). Reason: Connection timed out
When I sniff packets with Wireshark on the server the output is:
1 0.000000000 12.3.456.78 12.34.567.89 TCP 66 53566 > websm [SYN] Seq=0 Win=8192 Len=0 MSS=1452 WS=256 SACK_PERM=1
And two retransmissions.
Note: The destination IP shown in Wireshark differs from the IP that canyouseeme.org determined.
Also note: Both connection attempts from my test client as well as from canyouseeme.org are shown in Wireshark.
Is my server console application doing anything wrong? It works fine on my local machine.
Because netstat reports that your server is listening on 9090, and because tcpdump reports that SYN packets are arriving to 9090, something else must be blocking the client.
My suspicion in this case would be some sort of local firewall (because the packets did arrive, but the OS should have answered with a SYN packet and you didn't see that). Check Windows Firewall to make sure port 9090 is open.
I have 2 instances of the same application, on different machines, that should talk with each other, where no one is a typical server or client.
Both instances of the application has a TcpListener, local port = 8000.
One application instance (call it "A") creates a TcpClient. Now, this client can't have local port = 8000, or the constructor throws the socket exception "Only one usage of each socket address (protocol/network address/port) is normally permitted".
So, I create this first client with a random local port, and run Connect() to connect with the other application instance "B".
"B" accepts the connection using TcpListener.AcceptTcpClient(), which returns a TcpClient that can be used to communicate with "A". Though, this TcpClient has the same IP and Port as the TcpListener!? How is this possible, when I could not use the same port when I created the TcpClient manually on "A"? I actually really would like them to use the same port as the listener, on both machines...
So, how can I create the TcpClient on "A" with same port as the TcpListener?
I think you might not fully understand the address port client server architecture.
TcpListener is listening to any connection on address and port. After connection established you can use the "Socket" to receive and send messages from the client and server both.
example:
0.0.0.1 is machine A.
0.0.0.2 is machine B.
you can put a TcpListener that is listening on port 8000 on machine A. When the TcpClient on machine B will make try to connect machine A on port 8000 the TcpClient on machine B will get a generated (by the OS) port.
and then you will have a connection
0.0.0.1:8000 -> 0.0.0.2:3587(Generated port) - so you dont need to worry for the client listening port.
A TCP Connection has always a server and a client side. The server is listening (waiting) for a connection and the client connects to the server.
When the server gets the connection request, AcceptTcpClient gives you the socket of the server side to communicate with the client. A TCP Connection is always defined with the IP Addresses and Ports of the two sides: serverip:serverport and clientip:clientport.
If you want a really symmetrically System, both instances would have a server and a client that connects to the other server. All data that would then always be sent from client to server over the connection that was established by the client.
For Example:
ClientA connects to ServerB -> ConnectionAB
ClientB connects to ServerA -> ConnectionBA
ApplicationA sends data to ApplicationB over ConnectionAB
ApplicationB sends data to ApplicationA over ConnectionBA
If your goal is to use 2 TCP endpoints to talk to each other, without one of them being an
explicit server always, you probably should run a listener (on port 8000, in your case)
on both machines. Next, let each machine try randomly for the connection -- let each
machine pick a random time (between 0 and T) and then wake up. Whichever machine
wakes up first, will call connect() and establish the connection.
As #nivpenso pointed, the end point doing the connect need not explicitly bind to
a port. The connect() step explicitly assigns a temporary random port to that
end point.
So, if hostA initiates the connection, here are all the endpoints you would see
(you can use netstat to see these connections)
HostA:
-- listener: 8000
-- connection to hostB:port8000, localport:xyz
HostB:
-- listener: 8000
-- connection to hostA:port:xyz, localport:8000
On the other hand, if hostB initiates the connection, here are all the endpoints you
would see:
HostA:
-- listener: 8000
-- connection to hostB:port:xyz', localport:8000
HostB:
-- listener: 8000
-- connection to hostA:port8000, localport:xyz'
In the Internet, BGP uses a similar method to connection 2 TCP peers.
I have created a simple "proof of concept" app that sends a text message over sockets using C# between two Windows computers (XP sending, W2K receiving).
When I run "netstat -a" on the receiving computer, I see a couple of strange things:
netstat tells me:
...
TCP <thismachinename>:netbios-ssn <DevMachineName>:1330 ESTABLISHED
...
--and:
TCP <thismachinename>:1041 a65.197.244.82.deploy.akamaitechologies.com:http CLOSE_WAIT
So:
1) Why is there a connection with my Dev machine (It SHOULD be listening on port 62222, but it's not, yet this mysterious ESTABLISHED connection does exist...)
2) Who/what/why is this akamai technologies connection?
Note: I restarted the remote/listening machine this morning; I checked netstat -a to be sure it was not listening on port 62222 yet (it wasn't); I then started the dual-purpose app that should listen on that port; I ran netstat -a again, and it was STILL not listening on port 62222. Yet these other two odd things...
The established connection to <thismachinename>:netbios-ssn is because you have connected to a Windows Share, printer or something on thismachinename from DevMachineName.
The second connection is that your computer has for some reason connected and downloaded something from akamai. The connection is closed, but in CLOSE_WAIT mode which it is for 120 seconds (if I remember the timeout correctly).
For the listening on port 62222 that is not appearing - do you get any errors in your app when you are opening the listening socket?