--stats-every 1s can cause errors on very small scans

[Deedasmi]

nmap_proc = NmapProcess(targets="127.0.0.1", options="-sU -p 18000 -A") nmap_proc.sudo_run_background() parsed = NmapParser.parse(nmap_proc.stdout)

Traceback

(most recent call last):
File "/usr/local/lib/python3.5/dist-packages/libnmap/parser.py", line 90, in _parse_xml
root = ET.fromstring(nmap_data)
File "/usr/lib/python3.5/xml/etree/ElementTree.py", line 1334, in XML
return parser.close()
xml.etree.ElementTree.ParseError: no element found: line 33, column 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/$USER/PycharmProjects/hmap/test.py", line 15, in
parsed = NmapParser.parse(nmap_proc.stdout)
File "/usr/local/lib/python3.5/dist-packages/libnmap/parser.py", line 41, in parse
nmapobj = cls._parse_xml(nmap_data, incomplete)
File "/usr/local/lib/python3.5/dist-packages/libnmap/parser.py", line 92, in _parse_xml
raise NmapParserException("Wrong XML structure: cannot parse data")
libnmap.parser.NmapParserException: Wrong XML structure: cannot parse data

Nmap command:
sudo nmap -oX - -vvv -stats-every 1s -sU -p 18000 -A

nmap: timing.cc:710 bool ScanProgressMeter::printstats(double, const timeval*): Assertion 'ltime' failed.

Turns out it's an issue with nmap, not the lib. It would be nice if stats-every was an option we could control though.

[Deedasmi]

Richard,

Thanks for reporting this! This would happen if stats were requested (by --stats-every or by pressing a key) during a scan phase where no scripts were requested (as in the pre-scanning phase with default category scripts, I think). I added a check for 0 script threads to avoid a division by zero, and the problem went away. Look for the fix in the next release, but meantime use a longer --stats-every interval to avoid requesting during an empty scan phase.

Dan

Should be solved in next nmap release.