I setup a Server on my machine that listens on port 8888 for incoming connections. Now I wanna make absolutely sure that this port is properly working and waiting for incoming connections. Is there maybe a tool I could use for Win XP that tells me if on my local machine there is an TCP port waiting for a connection?
The easiest thing to do, IMO, and what I typically do, is run:
telnet localhost 8888
If I get a connection (blank screen, just a prompt), it's running, otherwise, the telnet application terminates with something like:
Connecting To localhost...Could not open connection to the host, on port 8888: C
onnect failed
To get out of telnet, press Ctrl], and then type in:
quit
Enter
use the command "netstat.exe -an" from the command line to list out all listening ports and connections.
Some sample output from my machine:
C:\>netstat.exe -an
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING
TCP 127.0.0.1:1026 127.0.0.1:1027 ESTABLISHED
TCP 127.0.0.1:1027 127.0.0.1:1026 ESTABLISHED
TCP 127.0.0.1:1033 127.0.0.1:1034 ESTABLISHED
TCP 127.0.0.1:1034 127.0.0.1:1033 ESTABLISHED
TCP 127.0.0.1:2577 127.0.0.1:2578 ESTABLISHED
TCP 127.0.0.1:2578 127.0.0.1:2577 ESTABLISHED
TCP 127.0.0.1:2579 127.0.0.1:2580 ESTABLISHED
TCP 127.0.0.1:2580 127.0.0.1:2579 ESTABLISHED
TCP 192.168.2.6:3522 192.168.2.2:80 ESTABLISHED
[...cut for privacy...]
We can see from the above that TCP port 445 for example is open and listening for incoming connections.
You can ping your service like Telnet. Or after Telnet use get command to find the response of the service.
You can use
netstat -an |find /i "listening"
from the command line to see what ports are open and listening. You'll get some output that looks like
TCP 0.0.0.0:8888 0.0.0.0:0 LISTENING
if your application is listening on port 8888. Run the command before your application to make sure the port is not already in use (or just run your application and look at the stack trace ;)).
The telnet app is not a bad idea. Also if your program shoves a few characters out the port when it starts (I forget, I think it's 3 bytes though) you can actually display messages on/interact with the telnet session.
The bytes you send are telnet's negotiation session where it asks the terminal what type/size/color/whatever it can do. The telnet program expects a few bytes of these queries and won't connect without them, but if you just blast out the correct few bytes and ignore the response, you'll have a more-or-less fully functional telnet server.