No handling of empty uptime strings results in errors

[MeanFlightChair]

https://github.com/postmodern/ruby-nmap/blob/43e851324f9f725ad6e51b88a1e80a5f4c5ae98e/lib/nmap/host.rb#L266-L276

The above method checks if uptime exists within an nmap report and then parses the lastboot attribute as a timestamp. This fails if lastboot is the empty string and no checking is done for this.

Nmap 7.92, when generating simple ping reports, contains the uptime tag without any of the attributes being filled. This ruby-nmap therefore fails for any ping only reports.

I have implemented a simple patch on my local branch by substituting:

@uptime ||= if (uptime = @node.at_xpath('uptime'))

with

@uptime ||= if ((uptime = @node.at_xpath('uptime')) && !(uptime['lastboot'].empty?))

If uptime is completely missing, the second part of the condition which I added is not evaluated, which avoids any [] referencing on an non-existent object. This handles the cases where uptime and associated strings are set to actual values, set to empty strings or when the uptime tag is completely missing from the report.

I have not submitted a PR as I don't usually use Ruby and am not sure of the most idiomatic way of doing this.

If someone can prettify my patch and get it implemented, that would be appreciated!

[postmodern]

Can you share the nmap command-line option flags your using to generate this XML output? I downloaded and built locally nmap-7.92 and cannot reproduce this using -PE or -P0 with example.com. It seems to me that if lastboot is empty, it should just be omitted from the XML output all together, because the nmap DTD says lastboot is IMPLIED (aka optional). This may be a XML bug in nmap-7.92.

[MeanFlightChair]

I have regenerated some XML files at my end to replicate my own results. The command run was nmap -sn <LOCAL_CIDR_RANGE>

I agree that the result of this when running nmap-7.92 is that the uptime node (with associated lastboot attribute) is ommitted. It appears that the sample XML I was working with was exported from zenmap. Running the same command in zenmap and then saving the report to xml introduces this error.

I understand if this is out of scope of this project, but would appreciate the patch nonetheless to ensure that a zenmap report can also be properly parsed.

[postmodern]

I would also suggest submitting a bug report to zenmap so this can be fixed at the source. They should filter out empty values from their attributes.

[postmodern]

Closing this as it was an issue with zenmap.