The issue occurs when multiple plugins are selected for scanning. But, when only one plugin is selected, it reports
appropriately.

Example scenario: 
(Quoting from Carsten)
Test is running gb_vmware_prdts_mult_vuln_win.nasl and gb_thunderbird_mult_vuln_july08_win.nasl against a host which
has installed vmwareplayer 2.0.1 and Thunderbird 1.5.12. Only a warning for the vmware player is shown. Disabling the
vmware check and running only the thunderbird test will bring up the Thunderbird warning.
Running Firefox and Thunderbird test against a host with both vunerable versions brings sometimes zero, one or  two
warnings only by running the test a few times without any changes.

Observing the logs and the saved KB items, it looks like some of the plugins are failing to launch or they exit
intermittently without traversing the entire code.

Work around:
When "checks to perform concurrently" is set to 1, all plugins report appropriately. 

Date: 2009-08-04 11:25
Sender: Felix Wolfsteller

Closing this issue.

All known 'problematic' checks have been fixed.

Testing took place on two different instances of Windows XP.

With a server that lists at least ports 139 and 445 in the
'non_simult_ports' configuration (openvasd.conf), parallel checks
do not lead to inconsistent reports anymore.

Big thanks to Chandrashekhar B (did the main work), Michael Wiegand
and Thomas Reinke.

Date: 2009-07-17 09:57
Sender: Chandrashekhar B

The bug is fixed.

There is a non_simult_ports parameter to indicate not to launch
multiple plugins simultaneously on selected ports. This behavior
wasn't working appropriately. The fix is committed by Felix to
svn.

Tested with multiple Windows plugins with this parameter set
and included script_require_ports(139,445) in those Windows plugins,
and it all works fine.

Next Step:
Update all Windows plugins to include script_require_ports(139,
445) and then test will all Windows plugins.

Date: 2009-04-29 09:01
Sender: Felix Wolfsteller

Wrap- up of discussions via irc and the mailinglist:
----------------------------------------------------

Bugged scan results for SMB-dependend NVTs when concurrent checks
is set to > 1


Chandra, michael (mwiegand) and me (felix) spent quite some time
hunting this
bug, chandra was most successfull and provided most of these
information.


Surface:
--------
When "Concurrent Checks" is set to more than 1, scan
results differ.
More concrete, some issues are not reported when this option
is set to more than 1.


Setup:
------
Latest openvas-server, openvas-libraries, openvas-libnasl installed
on
OpenVAS- Server machine.
NVT Feed sync'ed.
Latest openvas-client installed on OpenVAS Client machine (might
be the same).
Target machine runs a WinXP with SP2, known user.
SMB- related NVTs selected (e.g. see next section), SMB credentials
provided.


Exemplary NVT set:
------------------
These NVTs (+dependencies) enabled ('Windows Bulletins' family):
[script filename, OID, script name]

* secpod_ms09-001.nasl, OID 900069 : Vulnerabilities in SMB Could
Allow Remote
Code Execution (958687)

* secpod_ms08-071.nasl, OID 900059 : Vulnerabilities in GDI Could
Allow Remote
Code Execution (956802) 


Technical:
----------
When Local Checks are done using a SSH- Connection, this connection
is shared
between multiple NVTs. This is implemented through
shared_socket_acuire() and
shared_socket_release() as in ssh_login_or_reuse_connection()
in ssh_func.inc.
For individual NVTs this behaviour of the server is hidden -
they get served
through a ~virtual socket that gets used as if it would be a
normal socket. When
open_sock_tcp() is called multiple times, underneath, there's
only one socket
opened but served through multiple virtual sockets

For Local Checks that utilize SMB (ports 139/445) this behaviour
is not really
implemented. Instead a different approach is used. Therefore
the server has to be
configured to open sockets to port 139/449 'non-simultanously'
(openvasd.conf 'non_simult_ports').
This should cause scripts that require this port to have to wait
for each other,
which however seems to never happen and so the socket access
'clashes'.


Solution:
---------
If the suspect described in the previous section is indeed the
culprit, there
are in principle two possible solutions:
1) Make the smb plugins use a socket sharing mechanism in the
way done for
ssh connections. smb_nt.inc can be updated to perform socket
register, acquire
and release procedures. But, this would impact thousands of Windows
related plugins.
2) Repair the non_simult_ports issue.
The second approach is preferred, as the first one requires a
lot of changes to
NVTs and individual result checking.


Related issues:
---------------
* A similar (surface) problem was observed with Local Checks
using SSH, but was fixed by
Chandra.

* Variable name collisions: When NVTs use the same names for
variables that are
not declared local, they collide. With the second proposed solution
(let them
wait for each other) this problem should not occur for SMB checks
anymore.

* On a Debian etch, the maximum number of sockets that NVTs could
open was 192.

Date: 2009-04-17 13:55
Sender: Chandrashekhar B

Upon more testing, it was discovered that the issue was only
with Windows related plugins that are using smb_nt.inc.

1. This can be confirmed by only selecting Linux based Local
Checks setting concurrency to more than 1 - Works normally.
2. Select only remote checks and increase the concurrency - Works
normally.

Only when Windows plugins are selected, the reports are different
each time we run when concurrency is more than 1.

The reason being smb_nt.inc doesn't implement the shared socket
acquire and release behavior as implemented in ssh_func.inc.

Next Step:
Need to modify smb_nt.inc and do more testing.