Re: [Patch] Showing TTL in default output

[Jay Bosamiya <jaybosamiya () gmail com>]

Fyodor,

After reading your mail, I was convinced that --reason (instead of
--reason -v) is better.
Also, after including the roll-up stuff (to be done later), there's
really no point keeping TTL info in a separate column. Rather, putting
it into the REASON column does put the info in context.
Taking into account all of this, I've committed the new output format as
r33531.

Cheers,
Jay

On Friday 15 August 2014 02:12 AM, Fyodor wrote:
> On Wed, Jul 30, 2014 at 12:47 AM, Jay Bosamiya <jaybosamiya () gmail com
> <mailto:jaybosamiya () gmail com>> wrote:
>
>
>     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.
>
>
> That's a good point, but we could also hypothesize about users who
> want the TTL information, but don't want all the other stuff which
> comes with -v.  But the users I'm most worried about are the ones who
> would like the TTL info, but might never know about or see it if it
> requires two non-default options to enable.  I see that as a bigger
> problem than the case that users might see this short output and
> somehow be annoyed by the information, even after they have specified
> --reason or -vv or -d (which enable --reason).
>  
>
>     They might be used to seeing things from --reason and find the new
>     output (i.e. with TTL) confusing.
>
>
> It is a pretty minor change in the Nmap output as a whole, so I think
> they can handle it.  And our policy is to try and find the best output
> at the current time and we're not afraid to change things.  The
> exception is XML output, which is meant to stay compatible and is what
> folks reading Nmap output programmatically should be using.  Nmap is 2
> weeks away from it's 17th birthday, and it would never have gotten
> this far if we were afraid to make changes.
>
>     However, by saying "--reason -v" they say that they want a "more
>     verbose reason"
>
>
> We Nmap developers may design our command lines with skill and care
> and subtlety, but I'm afraid you may be overestimating how many normal
> Nmap users do that :).  So I'd rather err on the side of including
> this extra bit of short information, particularly considering that
> they will have to specify --reason, -vv, or -d to get it anyway.
>
>     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.
>
>
> Yeah, I think the combined format probably is slightly longer (the
> longest lines are two characters longer in my previous scanme.nmap.org
> <http://scanme.nmap.org> example).  However, I think it is easier to
> read that way.  Including the TTL on its own line separates it from
> the reason and also gives this column of digits too much prominence,
> placing them at the same level as other fields like the service name
> and whether the port is open.  Putting the TTL in a parenthetical
> after the reason (like "syn-ack (ttl 53)") puts the information more
> in context.  And actually, maybe we don't really need the parenthesis.
>  If we just do "syn-ack ttl 53" it will be the same length as in the
> separate column mode.  So it would look 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
> 139/tcp  filtered netbios-ssn  no-response
> 445/tcp  filtered microsoft-ds no-response
> 9929/tcp open     nping-echo   syn-ack ttl 52
>
>  So the format above would be my suggestion.
>
>
>     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).
>
>
> That is a good reason for the column mode, but I think they will be
> roughly in a column with the combined output (as above) too.  If there
> are different types of responses (syn-ack, reset, etc.) the column
> numbers won't match up exactly, but I think it will be close enough to
> read.  And Nmap is better than humans at detecting subtle differences
> like this anyway, so this is sort of where the roll-up stuff you
> mention comes in.
>
>     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.
>
>
> Yeah, that could be interesting.
>
> Cheers,
> Fyodor

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