Sign in to follow this  

ping help

This topic is 3632 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

as we all know, ping test for a connection eg ping google.com checks for connection between my home and google.com now suppose ping A ping B are being tested . but these tests connection between home to A and between home and B . but how to ping between A and B i.e how to check connection between A and B where A and B may be google.com and yahoo.com thanks in advance

Share this post


Link to post
Share on other sites
Cannot be done, unless you have remote access to one of hosts.

With IP spoofing you could bounce packets between the hosts, but you would never be able to receive the result.

The reason for this is simple: if this were possible, then it would be possible to hijack third party connection for data transfer (ping carries payload as well). Imagine torrent protocol using this to transfer data.

Even more - it would be possible to store data in ether. This would create networked volatile memory, similar to DRAM. And if such third-party routing were possible, these connections could initiate each other. Very interesting concept, but impossible to allow.

The idea is simple: host O sends 64k ping between hosts A and B. The ping results are sent to C, which, using same routing, bounced them between C and D. Ping results of that are sent to hosts A and B. And presto - JK flip flop. All you need now is some way to obtain these results, which could be obtained by some form of dynamic routing table somewhere in between remote hosts. Possibly through DNS update propagation. Such RAM would have several minutes latency on access, but still, ....

A similar concept was proposed several years ago using DNS cache, which allowed for some very interesting concepts, but unfortunately has the capacity to literally break the internet as a whole.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
With IP spoofing you could bounce packets between the hosts, but you would never be able to receive the result.


That is not fully true, as Antirez' paper demonstrates.

Share this post


Link to post
Share on other sites
Quote:
Original post by bulgurmayo
Quote:
Original post by Antheus
With IP spoofing you could bounce packets between the hosts, but you would never be able to receive the result.


That is not fully true, as Antirez' paper demonstrates.


The method requires B to be in controlled environment (must not send any packets during scan). This is essentially a remote host you have access to. You also do not receive results, merely an indication something happened, what exactly isn't deterministic.

Share this post


Link to post
Share on other sites
Quote:
Original post by asdfwe
iam not sure(since iam beginner in networks)
can socket programmimng help in any way to solve my problem??


It is impossible to solve due to the way internet protocol is designed.

The only way you can do this, is if you have accesss to either host A or host B (yahoo or google in your example). Then you can either login into one of the hosts and perform the ping from there, or install a "ping service" on one of them and you contact that.

But you need administrator-level access to either host A or host B.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Quote:
Original post by bulgurmayo
Quote:
Original post by Antheus
With IP spoofing you could bounce packets between the hosts, but you would never be able to receive the result.


That is not fully true, as Antirez' paper demonstrates.


The method requires B to be in controlled environment (must not send any packets during scan). This is essentially a remote host you have access to. You also do not receive results, merely an indication something happened, what exactly isn't deterministic.


I disagree. The only constraint on what you call B is that is receives almost no traffic at the time you are doing the indirect probe. This is by far a much lesser constraint than requiring it to be a remote host. Moreover I have experimented this technique with success and it never required my having access to any remote host.
You could see for yourself and give it a try using Antirez' tool called hping.

Share this post


Link to post
Share on other sites
Quote:
Original post by bulgurmayo
I disagree. The only constraint on what you call B is that is receives almost no traffic at the time you are doing the indirect probe. This is by far a much lesser constraint than requiring it to be a remote host. Moreover I have experimented this technique with success and it never required my having access to any remote host.
You could see for yourself and give it a try using Antirez' tool called hping.


What's the tracert between www.yahoo.com and www.google.com?

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Quote:
Original post by bulgurmayo
I disagree. The only constraint on what you call B is that is receives almost no traffic at the time you are doing the indirect probe. This is by far a much lesser constraint than requiring it to be a remote host. Moreover I have experimented this technique with success and it never required my having access to any remote host.
You could see for yourself and give it a try using Antirez' tool called hping.


What's the tracert between www.yahoo.com and www.google.com?


I am not sure I understand how this relates to the problem. traceroute is different from pinging or port scanning.

As for ISP blocking spoofed packets, well that would definitely make this technique unusable, and it would be a safe thing to do. But last time I tried spoofed packets were not blocked by my ISP.

Another thing that would make this technique unusable, would be to have the OS send unpredictable IPID.

Share this post


Link to post
Share on other sites
Quote:
Original post by bulgurmayo
I am not sure I understand how this relates to the problem. traceroute is different from pinging or port scanning.


trace route is ping with variable TTL.

for (ttl = 1; ttl < MAX_TTL; ttl++) {
ping(target_address, ttl);
}


Note that subsequent pings may be routed over different hosts, resulting in inconsistent results. Running traceroute several times can also yield different routes.


But ok, what's the ping between www.yahoo.com and www.google.com? How would you use SYN/ACK spoofing technique to determine that?

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Quote:
Original post by bulgurmayo
I am not sure I understand how this relates to the problem. traceroute is different from pinging or port scanning.


trace route is ping with variable TTL.

for (ttl = 1; ttl < MAX_TTL; ttl++) {
ping(target_address, ttl);
}


Note that subsequent pings may be routed over different hosts, resulting in inconsistent results. Running traceroute several times can also yield different routes.


But ok, what's the ping between www.yahoo.com and www.google.com? How would you use SYN/ACK spoofing technique to determine that?



Both traceroute and ping are different. In fact I am not even sure traceroute is build in the way you describe, in my memory it used UDP. Anyway traceroute brings much more information than ping.

Now I agree with you, using this technique to ping between yahoo and google will be difficult because both are under heavy traffic 24h / day.
But pinging between www.thesamallpetshotwithlowtraffic.com and google or yahoo would be possible.

Share this post


Link to post
Share on other sites
Quote:
Original post by bulgurmayo
Both traceroute and ping are different. In fact I am not even sure traceroute is build in the way you describe, in my memory it used UDP. Anyway traceroute brings much more information than ping.


No, both traceroute and ping use ICMP packets. Traceroute does it with varying TLL fields, ping with fixed TTL fields. They use the exact same underlying packets.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Quote:
Original post by bulgurmayo
Both traceroute and ping are different. In fact I am not even sure traceroute is build in the way you describe, in my memory it used UDP. Anyway traceroute brings much more information than ping.


No, both traceroute and ping use ICMP packets. Traceroute does it with varying TLL fields, ping with fixed TTL fields. They use the exact same underlying packets.


http://en.wikipedia.org/wiki/Traceroute disagrees

Share this post


Link to post
Share on other sites
Quote:
Both traceroute and ping are different. In fact I am not even sure traceroute is build in the way you describe, in my memory it used UDP. Anyway traceroute brings much more information than ping.


The fact that Traceroute and Ping both use the same ICMP packets, and the very same information, is a basic of the TCP/IP networking stack. The fact that you don't know it, and more seriously, you don't look it up when people tell you about it, adds significant weakness to your argument.

Traceroute couldn't use UDP, because that would require every host on the internet to run a special Traceroute service for it to work. Clearly, that's not the case.

The main difference between the Ping and the Traceroute program, other than the loop Antheus suggested, is that the Traceroute program does some additional presentation (such as doing IP->name look-up) to generate a nice table.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
Both traceroute and ping are different. In fact I am not even sure traceroute is build in the way you describe, in my memory it used UDP. Anyway traceroute brings much more information than ping.


The fact that Traceroute and Ping both use the same ICMP packets, and the very same information, is a basic of the TCP/IP networking stack. The fact that you don't know it, and more seriously, you don't look it up when people tell you about it, adds significant weakness to your argument.

Traceroute couldn't use UDP, because that would require every host on the internet to run a special Traceroute service for it to work. Clearly, that's not the case.

The main difference between the Ping and the Traceroute program, other than the loop Antheus suggested, is that the Traceroute program does some additional presentation (such as doing IP->name look-up) to generate a nice table.


I know what traceroute and ping do, and even knew how to build the required packets from scratch.

http://en.wikipedia.org/wiki/Traceroute disagrees with you, and I am sure I could find other sources that go in the same way.

Has anybody even tried what is described in Antirez' article ? This is the best way to see for yourself. At the time I read the article I used hping and it worked.

Share this post


Link to post
Share on other sites
Quote:
Original post by bulgurmayo
http://en.wikipedia.org/wiki/Traceroute disagrees with you, and I am sure I could find other sources that go in the same way.


Yes, and UDP packet is encapsulated in IP header, which has time to live parameter - relying on exactly the same principle. The problem is, it's still UDP packet and as such may be dropped by router - routers are not required to respond with expiry.

This is different from original ICMP design which is pure internet layer packet and *must* be handled by network stack. Of course, with proliferation of Windows hosts vulnerable to some ICMP-based attacks causing OOB overrun (notorious Ping Of Death) and some worms exploiting similar weaknesses, most ISPs cut down on ICMP traffic.

Using UDP for same functionality works around some of those issues, but is less reliable, and still relies on fundamental internet protocol mechanic that the ICMP based trace/ping uses, it just uses different payload.

Quote:
Has anybody even tried what is described in Antirez' article ? This is the best way to see for yourself. At the time I read the article I used hping and it worked.


Of course it works, that was never a question.

How will you use that to determine ping time between two remote hosts? Any hosts.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
Yes, and UDP packet is encapsulated in IP header, which has time to live parameter - relying on exactly the same principle. The problem is, it's still UDP packet and as such may be dropped by router - routers are not required to respond with expiry.

This is different from original ICMP design which is pure internet layer packet and *must* be handled by network stack. Of course, with proliferation of Windows hosts vulnerable to some ICMP-based attacks causing OOB overrun (notorious Ping Of Death) and some worms exploiting similar weaknesses, most ISPs cut down on ICMP traffic.

Using UDP for same functionality works around some of those issues, but is less reliable, and still relies on fundamental internet protocol mechanic that the ICMP based trace/ping uses, it just uses different payload.


Honestly I don't know the historical reason behind the different implementations. I have made some quick tests and apparently my windows box (windows XP sp2, tracert.exe command) sends ICMP echo requests and my linux box (debian 4.0, traceroute command) sends UDP packets. So we are both right, but this seems to contradict the reasons you are giving.

Quote:
Original post by Antheus
Of course it works, that was never a question.

How will you use that to determine ping time between two remote hosts? Any hosts.


My apologies if I misread your comments, all this time I never got you agreed it was possible to check a route between 2 hosts without having a remote connection, but had concerns about getting the ping time.

Well to me, there seems to be too much bias in practice to get this information.

Share this post


Link to post
Share on other sites
Seems that the use of UDP isn't widely discussed, but here's explanation of the benefits.

The traceroute mechanic depends on TTL member of IP header. What the payload is doesn't matter.

What would seem to be the case is that routers filter only certain type of ICMP packets, namely traceroute or ping requests.

By sending UDP you only bypass the request problem, but rely on other host either properly implementing ping service on specified port, or properly reporting destination unreachable. In addition, routers along the trace must properly reply about TTL expiry - some choose not to so.

The application layer version has two problems. One is that some routers are black holes, and never respond except to packets they know they will handle. The other is that in addition, services running on routers may choose not to respond to faulty requests.

This is different from ICMP, where handler is always known and has known behavior.

Overall, there's no real reason to use UDP, except if ICMP packets are being blocked somewhere. ICMP version yields more consistent results, and also complies with RFC.

Share this post


Link to post
Share on other sites
Interesting that newerLinux traceroute uses UDP for the payload. That certainly wasn't the case back when the basic infrastructure was put up, and the canonical traceroute description in reference material still assumes ICMP. As explained by Antheus, ICMP is still the fundamental reporting mechanism, though. A pure UDP-layer traceroute (or TCP-layer) does not exist, for the obvious reasons.

Anyway, thanks for the pointer! That being said, I don't see how you can measure anything other than actual connectivity between the two hosts -- you can't find the route between them, and you can't measure the round-trip time to any degree of precision (although you can make some rough estimates about propagation delay).

Share this post


Link to post
Share on other sites
True, I do not see how time can be measured or how routes can be discovered. But firewall rules between both hosts can be disclosed, in a very stealth manner. Honestly at the time I discovered the article I liked the idea very much, and the tool he wrote : hping, is something very valuable to have around.
Just thought it would be worth sharing.

Share this post


Link to post
Share on other sites
Sequence number prediction is a well documented problem and if it wasn't for protocols like BGP, it would have been resolved already. Heavy traffic is not the only problem Bulg, most firewalls I know of use randomisation of the sequence number to prevent this type of thing (or attacks that use the same principle). The technique you have shown is interesting and my hat off for the person that thought of it, but wont work as easily as you may think. Even more importantly, it could be open to legal repercussions should you be caught doing so.

Share this post


Link to post
Share on other sites

This topic is 3632 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this