I’m usually seeing such (assumed to be) “stuck” scans at 99% progress at the end of the scan because there are still long running VTs like e.g. SSH login brute force or HTTP ones running which might take a good amount of time to finish.
Background: AFAICT the progress bar / percent is based on the still to be scheduled / launched VTs because the software stack / component responsible for this calculation has no prior knowledge how much time a VT would take to finish (some might be finished in one second while special ones like the SSH login brute force one is allowed to run for 15 Minutes).
I hope this report will help.
I have noticed this behavior happens when openvas tries to scan a smartTV with LGwebOSTV and it comes to be shut off during the scan. I’m not sure if the same thing happens even while a full scan is run against a different device and it comes to be “off” while the scan task runs.
When is “off”, the smartTV is still connected to the network (so it goes in a “suspend” state, and this is when I noticed this behavior)
Scan configs and many of the NVTs have configuration settings that can be adjusted. Timeout and connection attempt thresholds in particular may alleviate the symptoms of your problem. If the scanner is going through a long list of say, credentials to test, and the device is not responding, it may take a long time for the timeout to be reached each time the test runs. I guess that timeout settings are fairly liberal by default to allow for poor network conditions.
AFAICT this is the expected default behavior of the scanner for this case and might be indeed also a reason why such supposedly “stuck” scans are seen (which are actually just slow due to the previous mentioned timeouts which needs to hit first). But in this case the scan could stay on an arbitrary percentage / progress and not only at 99%.
When using Boreas and version 22.04+ of the scanner the following:
During a scan it might happen that a host unexpectedly shuts down, a firewall blocks the traffic, a network device issue break the connection, etc. This leads to many VT timeouts and long scan durations. This option checks the alive status of the host again after the provided amount of max VT timeouts are reached. If the host is considered dead the scan will be stopped for this host. Otherwise the scan will continue. This option requires Boreas alive test to be enabled. Default: option not set, disabled.
seems to be available since:
as a scanner preference which can be configured as desired (in e.g. the openvas.conf).
On a related note:
has also extended some reporting recently which makes the state of a scan more clear in the GUI.
Unfortunately i don’t have specific insights in the use of Boreas and this max_vts_timeouts, how it is/can be used or configured so i’m not able to give additional guidelines outside what have been provided previously.