Re: [Patch] Showing TTL in default output

[Jay Bosamiya <jaybosamiya () gmail com>]

Fyodor,

I feel that the reason we made it "--reason -v" instead of just making
it default for "--reason" is that some users might not be interested in
TTL information. They might be used to seeing things from --reason and
find the new output (i.e. with TTL) confusing. However, by saying
"--reason -v" they say that they want a "more verbose reason" (i.e. they
imply that they want more information) and we provide this to them. I
find that confusion from output is more important to take care of rather
than simplifying documentation (though I think that even the
documentation for "--reason -v" would not be that complicated).
I hope that clears it up. However, if you still think that we should
make it "--reason" instead of "--reason -v", it will be a very minor
change (changing line 1472 to "if (o.reason)"; or maybe removing
o.show_ttl everywhere and just using o.reason everywhere instead).

As for the different way of showing output (TTL in the reason column), I
don't see how it would save horizontal space. The TTL column makes the
table wider by 4 characters (always), but the "syn-ack (ttl 52)" method
would use more characters in most cases.

Also, I think that the reason we need to have a TTL column is to be able
to see (at a single glance) if any TTLs are different. When in a column
form, the numbers are almost instantly interpreted by a human (or alien,
if they have started using Nmap :D) and they can tell if there is any
anomaly (maybe one of the TTLs is off by one: possibly implying a
firewall, etc).
However, you might be able to judge which is better (separate column or
moving it to the reason column).

I will be looking into the roll-up stuff in a short while; and I do
agree that it would give a lot of interesting information. I personally
do not mind added complexity as long as it provides more useful information.

Cheers,
Jay

On Tuesday 29 July 2014 05:46 AM, Fyodor wrote:
> 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/