Re: [Patch] Port and Host State Reasons

["Eddie Bell" <ejlbell () gmail com>]

> The functions state_reason_init and state_reason_summary_init initialize
> the state to ER_NORESPONSE, which is a reason that might plausibly be
> returned after a scan. Perhaps it's better to initialize it to
> ER_UNKNOWN instead, to make it more obvious if someone modifies the  > scan engine to handle another scan type but 
> forgets to call
> setStateReason.

Good idea. I've change this

> Why does the reason_id go in the XML output. The textual names seems
> like they'll be more robust.

reason_id wasn't in the old patch and now I think about it I'm not
sure why I put it in this time! I've taken it out seeing as it adds at
least 13 bytes per port for very little gain.

> When scanning a host that returns a response for every port (i.e., every
> port is unfiltered), there's an "extrareasons" element in the XML output
> with a count of 0:
>
>         <extrareasons reason="resets" reason_id="0" count="1702"/>
>         <extrareasons reason="no-responses" reason_id="33" count="0"/>

Fixed.

> Maybe you should enumerate the possible values the "reason" attribute
> of the "status" element can take (in the same way that the "state"
> attribute can take on only certain values.

I didn't do this because there would be over 50 different types
(singular and plural) which is bit excessive. Especially considering
the DTD doesn't seem to be used that much.

> In the output table, I think the REASON column should come before the
> SERVICE column. The reason for this is that REASON pairs naturally with
> STATE and SERVICE pairs with VERSION. This may cause problems if a
> program tries to screen-scrape Nmap's output, but then those programs
> are going to have trouble with an additional column anyway.

I don't know, service is probably more important then the reason. I
also am hesitant to change the order of the first three columns as
nmap has used this format for a long time....unless multiple people
think otherwise?

The updated code is available in SVN at /nmap-exp/ejlbell along with
my previous traceroute update

Thanks for testing it
 - eddie

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org