Knowing latency without ICMP?

Is it possible to use TCP pings to know the latency of a host to another
like a regular ICMP ping would?

My ISP blocked all ICMP traffic and i need to know the latency of a few
dedicated server ill be leasing, the problem is that i need to know the
latency to my ISP users, because they also would be the main target.

Any other solution to know latency without using ICMP? Taking into
consideration that i dont yet have access to the dedicated servers.


Thanks in advance,

Apocalypse 2000

Apocalypse 2000 wrote:

> Is it possible to use TCP pings to know the latency of a host to another
> like a regular ICMP ping would?

Yes. Check out the following application:

http://www.hping.org/


--
I am currently looking for contract work: http://ianakiev.com/contract

> Is it possible to use TCP pings to know the latency of a host to another
> like a regular ICMP ping would?
>
> My ISP blocked all ICMP traffic and i need to know the latency of a few
> dedicated server ill be leasing, the problem is that i need to know the
> latency to my ISP users, because they also would be the main target.
>
> Any other solution to know latency without using ICMP? Taking into
> consideration that i dont yet have access to the dedicated servers.

Does your ISP block UDP packets as well? You could send UDP packets on a
round trip and measure how long it takes to hear an echo.

Jem Berkes <(E-Mail Removed)> wrote:
>> Is it possible to use TCP pings to know the latency of a host to another
>> like a regular ICMP ping would?
>>
>> My ISP blocked all ICMP traffic and i need to know the latency of a few
>> dedicated server ill be leasing, the problem is that i need to know the
>> latency to my ISP users, because they also would be the main target.
>>
>> Any other solution to know latency without using ICMP? Taking into
>> consideration that i dont yet have access to the dedicated servers.
>
>Does your ISP block UDP packets as well? You could send UDP packets on a
>round trip and measure how long it takes to hear an echo.

How do you "send UDP packets on a round trip"?

--
Floyd L. Davidson <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) (E-Mail Removed)

>>Does your ISP block UDP packets as well? You could send UDP packets on
>>a round trip and measure how long it takes to hear an echo.
>
> How do you "send UDP packets on a round trip"?

You would have to have an application on the other end that co-operates. I
guess such a facility does not exist though... hmm

On Sun, 24 Aug 2003 18:12:22 +0000, Apocalypse 2000 wrote:

> Is it possible to use TCP pings to know the latency of a host to another
> like a regular ICMP ping would?
>
> My ISP blocked all ICMP traffic and i need to know the latency of a few
> dedicated server ill be leasing, the problem is that i need to know the
> latency to my ISP users, because they also would be the main target.
>
> Any other solution to know latency without using ICMP? Taking into
> consideration that i dont yet have access to the dedicated servers.
>
>
> Thanks in advance,
>
> Apocalypse 2000

If I'm reading the IP specification right, the responding host ought to
set the TTL field of the IP header to 255... if you can get the other side
to respond (to your TCP "ping" as you say), you ought to be able to
average 255 - the received TTL's and get a pretty good idea of the number of
hops between you and the other side. I don't think regular sockets allow
you access to the IP headers, though, so you might need to write a program
to fake a TCP packet or two with raw sockets.

On 25 Aug 2003, Jem Berkes wrote:

> > Is it possible to use TCP pings to know the latency of a host to another
> > like a regular ICMP ping would?
> >
> > My ISP blocked all ICMP traffic and i need to know the latency of a few
> > dedicated server ill be leasing, the problem is that i need to know the
> > latency to my ISP users, because they also would be the main target.
> >
> > Any other solution to know latency without using ICMP? Taking into
> > consideration that i dont yet have access to the dedicated servers.
>
> Does your ISP block UDP packets as well? You could send UDP packets on a
> round trip and measure how long it takes to hear an echo.

UDP echo should be turned off, because of its potential to be used as an
amplifier as part of a "fraggle" attack (or is it smurf? Whatever!).

This probably won't help the original poster, but I can't imagine a
legitimate reason to block ICMP, so I would advise finding another ISP!

There is probably a web site that will ping the server for you and report
times. For sure, you could use www.samspade.org and run traceroute to the
target -- it then shows repsonse times.

>

"Jem Berkes" <(E-Mail Removed)> wrote in message
news:Xns93E2DF6B2B340jbuserspc9org@130.179.16.24.. .
> > If I'm reading the IP specification right, the responding host ought
> > to set the TTL field of the IP header to 255... if you can get the
> > other side to respond (to your TCP "ping" as you say), you ought to be
> > able to average 255 - the received TTL's and get a pretty good idea of
> > the number of hops between you and the other side. I don't think
> > regular sockets allow you access to the IP headers, though, so you
> > might need to write a program to fake a TCP packet or two with raw
> > sockets.
>
> I don't think that's going to work too well unless you are sure what the
> TTL field is set to (it's probably not 255). Sniffing my wire I'm seeing
> "original" TTLs of 64 and 128, so you would have to know what number
you're
> dealing with. And this tells you the number of HOPS, not the latency in
> milliseconds.

Here is what i used:

http://www.mainnerve.com/lft/

- - - - -
Tracing ______________________________________.

TTL LFT trace to 216.239.39.99:80/tcp
1 10.0.0.1 1.0ms
2 0.0.0.0 49.0ms
3 0.0.0.0 47.0ms
4 ISP.host.sanitized.com (0.0.0.0) 47.0ms
5 ISP2.host.sanitized.com (0.0.0.2) 70.0ms
6 sl-st20-mia-12-0.sprintlink.net (144.223.244.37) 73.0ms
7 sl-bb22-orl-14-1.sprintlink.net (144.232.20.14) 77.0ms
8 sl-bb20-atl-10-2.sprintlink.net (144.232.19.129) 193.0ms
9 sl-bb21-atl-14-0.sprintlink.net (144.232.12.142) 90.0ms
10 144.232.8.182 89.0ms
11 agr3-loopback.Atlanta.cw.net (208.172.66.103) 96.0ms
12 dcr1-so-0-2-0.Atlanta.cw.net (208.172.75.9) 97.0ms
13 dcr2-loopback.Washington.cw.net (206.24.226.100) 103.0ms
14 bhr1-pos-10-0.Sterling1dc2.cw.net (206.24.238.166) 105.0ms
15 csr12-ve240.Sterling2dc3.cw.net (216.109.66.83) 105.0ms
16 216.109.88.222 105.0ms
17 216.239.47.46 107.0ms
18 [target] 216.239.39.99:80 112.0ms
- - - - -


I had to use cygwin to use it in window because i dont have linux in this bo
x.

But umap also let you "tcp ping" perfectly fine from ICMP


There's 100's of reason to block ICMP...and almost none to keep it.


Thanks guys,

Apocalypse 2000

> Here is what i used:
>
> http://www.mainnerve.com/lft/

Very neat! However I still think lft listens for ICMP time exceeded
messages from routers - if incoming ICMP is blocked by the ISP, I don't
think this will work.

"Jem Berkes" <(E-Mail Removed)> wrote in message
news:Xns93E3E1181183Ajbuserspc9org@130.179.16.24.. .
> > Here is what i used:
> >
> > http://www.mainnerve.com/lft/
>
> Very neat! However I still think lft listens for ICMP time exceeded
> messages from routers - if incoming ICMP is blocked by the ISP, I don't
> think this will work.


Oh yes it works, my ISP has outgoing ICMP blocked, worked for me, i was the
original poster :P.