Re: [Patch] Showing TTL in default output

[Fyodor <fyodor () nmap org>]

On Fri, Jul 18, 2014 at 1:07 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:
> After some discussion on IRC, we've decided that this patch will be fine to
> apply for now, and that the other concerns about port state roll-up will be
> made into a todo item for later.

Nice! I've been playing with this new feature and have some minor
suggestions.  With the new code, "--reason -v" output looks like this:

Host is up, received echo-reply TTL 52 (0.050s latency).
Not shown: 993 closed ports
Reason: 993 resets
PORT     STATE    SERVICE REASON      TTL
22/tcp   open     ssh     syn-ack     52
25/tcp   filtered smtp    no-response 0
80/tcp   open     http    syn-ack     52
135/tcp  filtered msrpc   no-response 0

First of all, if we're going to have this feature, I think we might as well
always turn it on with --reason rather than requiring "--reason -v".  This
would simplify usage and documentation, and I think reduce confusion about
how to enable this option.

Related to that, maybe we should put the TTL info in the reason column
instead of adding a new column.  That can save horizontal space, which can
be particularly important in a table like this.  And it means we don't have
to put zeroes for the "not applicable" case, which is often the majority of
entries in the table.  So maybe it could look more like:

PORT     STATE    SERVICE REASON
22/tcp   open     ssh     syn-ack (ttl 52)
25/tcp   filtered smtp    no-response
80/tcp   open     http    syn-ack (ttl 52)
135/tcp  filtered msrpc   no-response

Hmm ... I guess this doesn't actually reduce the max line length (at least
in this example), but I still tend to prefer it.

Then regarding these lines:

Not shown: 993 closed ports
Reason: 993 resets

This goes into the roll-up stuff Daniel mentioned before.  If it said
something like "Reason: 993 resets (ttl 54)", that would give us some very
interesting information compared to the ttl 52 open ports in the table. Of
course there is some added complexity for the cases where the TTLs aren't
all the same, but it shouldn't be too terribly hard to deal with.  We
already have code there to deal with differences in reasons for the various
rolled up ports.

Cheers,
Fyodor
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/