• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

How do i do a trace route to a certain port?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

Mr.Guvernment

Member
Joined
Feb 26, 2003
Hey all

i dont know what port a trace route in DOS goes on, but i need to specify the port

i have traied tracert address:port but that doesnt work..


Any thoughts?
 
Tracert just gives you the hops to the specified IP address. Every port will take the same path to the destination.

What exactly are you trying to determine?
 
ahh okay

a piece of software our company uses works on port 443, customer can download, install our software - do a trace route with no time outs or anything but our software will just not connect to our server - even though we have like 2000+ people connected and people connecting wit no problems.

i can go through their system configure / disable firewalls etc but still no luck....
 
cant - hardcoded into our software :D and it works for thousand and thousands of other people. our site is SSL encrypted.
 
Is it possible they have to update their trusted Certificate Authorities, or install your site's SSL certificate?
 
Also, if it's just this customer, they may not have port 443 (HTTPS) open on their firewall, or for some screwy reason they are using an old browser without 128 bit encryption, or something stupid like that. Chances are it's a problem on their end.

They also need to make sure they have Use SSL 2.0 and Use SSL 3.0 enabled in IE if that's what they are using.
 
I find telnet to be a nice program to test tcp connections.

Just ask them to telnet to you on port 443. If they can connect, then it is something else. If they can't even connect, then their firewall must be misconfigured in some way (or yours)
 
Slackfumasta said:
You can't telnet to port 443 unless you configure a server to specifically turn off HTTPS and answer telnet on port 443. Telnet by default works on port 23.

However doing that would disable the software for the thousands of users it does work for. Not a great idea.
 
Slackfumasta said:
You can't telnet to port 443 unless you configure a server to specifically turn off HTTPS and answer telnet on port 443. Telnet by default works on port 23.

You can telnet on any port you want to.

I'm only suggesting using telnet as a tool to test connectivity, I don't expect him to get a shell that way. Only to see if he can open a connection. I do it all the time as a diagnostic. It's a nice diagnostic because almost any computer you sit down at will have telnet on it.

Right now, open a command prompt and run:
telnet gmail.google.com 443

I get a connection:
Trying 216.239.57.98...
Connected to 216.239.57.98.
Escape character is '^]'.

Thats all I expect. Pick another port they aren't listening on, it won't connect. As an aside, telnet is also a nice diagnostic for plaintext services like ftp and smtp.
 
XWRed1 said:
You can telnet on any port you want to.

I'm only suggesting using telnet as a tool to test connectivity, I don't expect him to get a shell that way. Only to see if he can open a connection. I do it all the time as a diagnostic. It's a nice diagnostic because almost any computer you sit down at will have telnet on it.

Right now, open a command prompt and run:
telnet gmail.google.com 443

I get a connection:
Trying 216.239.57.98...
Connected to 216.239.57.98.
Escape character is '^]'.

Thats all I expect. Pick another port they aren't listening on, it won't connect. As an aside, telnet is also a nice diagnostic for plaintext services like ftp and smtp.

This does work, you'll be able to see the connection on the server (using something like 'netstat' if you are using windows server), but on the client machine the telnet window just goes blank as there is no telnet-able service running on that port. It never really tells you it made a connection, but if it doesn't connect you will get an error message. Just an FYI.
 
well the world knows our server address so i telnet'd to it

cmd
telnet tpc.dynip.com 443

i got a blank screen after that - does that mean it connected?

i go through peoples systems, get them to turn off all firewalls and such, and it just seems so rare that say 5 out of say 20,000 people just cant connect to any of our 4 servers running. Uusally they are on Xp with the odd ME person :(
 
kct2 said:
This does work, you'll be able to see the connection on the server (using something like 'netstat' if you are using windows server), but on the client machine the telnet window just goes blank as there is no telnet-able service running on that port. It never really tells you it made a connection, but if it doesn't connect you will get an error message. Just an FYI.

I know this. All I said is it is a nice way to see if a port is accessible if you aren't sure. I'm not expecting to find a telnettable service on 443. Didn't I even say there shouldn't be anything useable there? :D
 
Code:
xwred1@stoneburner:~$ telnet tpc.dynip.com 443
Trying 66.212.224.33...
[b]Connected[/b] to tpc.dynip.com.
Escape character is '^]'.

I was able to connect fine.

So your thing *is* listening on 443.

I was able to connect with my browser too, said you were using a 3rd party certificate for "Jesse". Told Firefox to go ahead and connect anyway, use your certificate. Now it grinds waiting for more data from your end... which is a problem on your end, not mine.
 
XWRed1 said:
I know this. All I said is it is a nice way to see if a port is accessible if you aren't sure. I'm not expecting to find a telnettable service on 443. Didn't I even say there shouldn't be anything useable there? :D

I was simply explaining what would happen, not to you, but to Mr.Guvernment, when he made a successful connection using the method you described. I figured you knew what you wrote would work, my point wasn't to verify what you said, but to expand on what Mr.Guvernment could expect to see.

Mr.Guvernment said:
i got a blank screen after that - does that mean it connected?

As you can see, what I wrote was necessary because exactly what I described happened. For some reason he still asked if it was connected :confused:

XWRed1 said:
Code:
xwred1@stoneburner:~$ telnet tpc.dynip.com 443
Trying 66.212.224.33...

[b]Connected[/b] to tpc.dynip.com.
Escape character is '^]'.

I was able to connect fine.

So your thing *is* listening on 443.

I was able to connect with my browser too, said you were using a 3rd party certificate for "Jesse". Told Firefox to go ahead and connect anyway, use your certificate. Now it grinds waiting for more data from your end... which is a problem on your end, not mine.

The fact you or I can connect is irrelevant, we know that the port is open on the server because of the thousands of other users that are able to connect. You need to have the user having trouble connecting try to telnet in on that port.

But simply being able to connect to port 443 is not enough to establish a SSL connection, the server certificate needs to be trusted by the client system too. The fact your server certificate is self-signed to a server name different than your public domain name, and expired 4 years ago could be a problem if the connection was being made by a standard browser. But looking at your company's website it would seem like your software would have to be coded to accept that specific server certificiate as it doesn't look like it requries or uses any specific version of Windows or IE. So, if the effected users are able to telnet to the correct port on the server, I am not sure what else to suggest.
 
The port is certainly listening on port 443, to connect on 443 you need to download our client, which will allow you to connect on port 443 - i beleive our client creates is own SSL certifcate with each new client that connects - not too sure will have to ask our developers about it though.


Also, upon checking that certificate - it expired in 2001, that was actually just around i got the job and shortly after , March 2001, i set up our company in Antigua :D, Jesse njo longer works for us but was one of the original programmers for our software.

I would also assume it hangs on FireFox or any browser is because we are not serving any HTTP(s) web sites off 443, it is all a client / server based application.
 
Back