OK, there was a slight difference with the gnutls. OK I now have the gnutls 
libs matching with the exact same versions: Libcurl3-gnutls (7.52.1-3) and 
libgnutls30 (3.5.8-3).

I deleted the scan from the master, rebooted both master and slave, recreated 
the whole scan on the master, and started it: Very similar results

Master openvasmd.log
01h49.46 Status of REMOTESCAN (GUID) changed to Requested
01h49.46 Task REMOTESCAN has been requested to start by USER
02h04.52 Failed to write to server. The specified session has been invalidated 
for some reason. (<-- seven times, all at the same timestamp)
02h04.52 Failed to gnutls_bye: Error in the push function
02h05.18 Status of task REMOTESCAN (GUID) has changed to Internal Error

Slave openvasmd.log
01h49.47 Target GUID has been created by USER
01h49.49 Scan config GUID has been created by USER
01h49.49 Status of Task GUID has changed to New
01h49.50 Task GUID has been created by USER
02h05.18 Target could not be created by USER
02h05.18 LSC Credential (null) could not be deleted by admin (<--3 times, all 
with the same timestamp)


  *   Is there a different gnutls library I should be looking at?
  *   Is there another log file somewhere?
  *   Does the timestamps give you any further clues?
  *   On the firewall rules, does only the master  initiate the communication 
with the slave or does the slave also initiate it’s own communication?
  *   Weird that it could create the Scan Config, Scan Task, etc, but errored 
on the target? Could that be some database timeout or insert error?
  *   What should I look at next?

Thanks in advanced,

Mark


From: [email protected] [mailto:[email protected]] On Behalf 
Of Eero Volotinen
Sent: Friday, March 3, 2017 12:46 AM
To: Mark Spears <[email protected]>
Cc: [email protected]
Subject: Re: [Openvas-discuss] Scan with remote slave "Internal Error"

This is a bit offtopic, but let me google that for you:

https://wiki.debian.org/ListInstalledPackages
Eero

2017-03-03 8:35 GMT+02:00 Mark Spears 
<[email protected]<mailto:[email protected]>>:
Can you please give me an example of how to check which gnutls version I am 
running?

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] On 
Behalf Of Eero Volotinen
Sent: Friday, March 3, 2017 12:19 AM
To: Mark Spears <[email protected]<mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>
Subject: RE: [Openvas-discuss] Scan with remote slave "Internal Error"

check version of gnutls and downgrade it to same version that working slaves 
are running.

Eero

3.3.2017 8.02 ap. "Mark Spears" 
<[email protected]<mailto:[email protected]>> kirjoitti:
Kali rolling version 2016.2 on the master.
Kali ARM version 2.1.2

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] On 
Behalf Of Eero Volotinen
Sent: Thursday, March 2, 2017 11:52 PM
To: Mark Spears <[email protected]<mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>
Subject: Re: [Openvas-discuss] Scan with remote slave "Internal Error"

Sounds like problems with gnutls library. what linux os and version you are 
using?

Eeo

3.3.2017 7.06 ap. "Mark Spears" 
<[email protected]<mailto:[email protected]>> kirjoitti:
We have several remote slaves installed. Two of them have experienced issues 
recently. Both of them worked with a test host discovery scan sent from the 
master and then quit working. I don’t know if it was due to an improper 
shutdown causing corruption somewhere or an issue with the firewall rules... I 
would just like some help in troubleshooting.

The first one we resolved by re-installing the original VM it was working on. 
On installation, the only default changes that are made are to adjust which IP 
the manager is listening on based on the network the slave is being deployed 
at. All remote slaves are made from the same image. All the other slaves are 
working great.

The second one we have not yet resolved.


  *   Slave: Openvas-check-setup reports no errors
  *   Slave: systemctl status on the three openvas services (gsa, manager, and 
scanner) reports all active with no errors.
  *   Slave: journalctl -xe command reports no errors
  *   Slave: /var/log/openvas/gsad.log shows no errors
  *   Slave: /var/log/openvas/openvasmd.log shows the slave receiving info from 
the master:
Target GUID (GUID) has been created by user
Scan config GUID (GUID) has been created by user
Status of task (GUID) has been changed to new

  *   Slave: /var/log/openvas/openvassd.messages shows no errors
  *   Master: openvas-check-setup reports no errors
  *   Master: systemctl status one all 3 services reports all active with no 
errors
  *   Master journalctl -xe command reports no errors
  *   Master: /var/log/openvas/gsad.log reports no errors
  *   Master: /var/log/openvas/openvasmd.log shows
(event) Status of the task REMOTESCAN (GUID) has changed to Requested
(event) Task REMOTESCAN (GUID) has been requested to start by user
(lib) Failed to write to server: The specified session has been invalidated for 
some reason. (7 times…)
(lib) Failed to gnutls_bye: Error in the push function.
(event) Status of task REMOTESCAN (GUID) has changed to Internal Error

  *   Master: /var/log/openvas/openvas.messages shows
Openvassd 5.0.7 started
Client not present
Received the Terminated signal (which could have been me running openvas-stop 
after I get “Internal Error” on GSAD?)


  *   I’ve deleted the scan that remained on the slave. Rebooted both master 
and slave and then re-started the scan. Same results.
  *   I’ve deleted the scan that remained on the slave, deleted the 
scan/targets/etc on the master, rebooted both computers and then recreated the 
scan on the master and re-started the scan. Same results.
  *   I’ve deleted the scan that remained on the slave, rebooted it, created 
the scan directly on the slave, and started it. It will not start (or even get 
to “requested”) nor does it give any error message.

I’m way beyond the basic troubleshooting. What log files am I missing to 
review. Where is my golden bullet! Please advise.



_______________________________________________
Openvas-discuss mailing list
[email protected]<mailto:[email protected]>
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

________________________________
_______________________________________________
Openvas-discuss mailing list
[email protected]
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss

Reply via email to