On 14 September 2012 11:39, Stuart Henderson wrote:
> On 2012/09/13 13:54, Matthew Dempsky wrote:
>> On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst wrote:
>> > This adds a -T portnum option to ping. I haven't polished the output
>> > because I'm not sure if this is desirable or not, but I found i
On 2012/09/13 13:54, Matthew Dempsky wrote:
> On Thu, Sep 13, 2012 at 12:02 PM, Ted Unangst wrote:
> > This adds a -T portnum option to ping. I haven't polished the output
> > because I'm not sure if this is desirable or not, but I found it
> > useful. If it's not a "hell no, never in base" I ca
f it's not a "hell no, never in base" I can finish it up some.
>
> Is there precedent for having TCP-based ping in any other OS's ping(1)
> utility? It seems like adding a separate tcpping(1) utility and
> leaving ping(1) for ICMP would be more appropriate.
>
>
me.
Is there precedent for having TCP-based ping in any other OS's ping(1)
utility? It seems like adding a separate tcpping(1) utility and
leaving ping(1) for ICMP would be more appropriate.
FWIW, nmap has a lot of TCP ping options; e.g., sending just SYN and
ACK packets for pings instead of a complete TCP handshake.
On Thu, Sep 13, 2012 at 03:02:09PM -0400, Ted Unangst wrote:
> So sometimes a machine is hiding behind a firewall that blocks icmp
> (looking at you, amazon ec2), but I want to know if it's up and/or how
> long away it is. tcp to the rescue.
Seems like a bit of a "rude" method of testing whether
> I haven't polished the output
> because I'm not sure if this is desirable or not, but I found it
> useful.
I'd like it, it's always made sense to me to test a service using the
protocol it uses and would remove a package install.
--
_
So sometimes a machine is hiding behind a firewall that blocks icmp
(looking at you, amazon ec2), but I want to know if it's up and/or how
long away it is. tcp to the rescue.
This adds a -T portnum option to ping. I haven't polished the output
because I'm not sure if this is desirable or not, bu
