0001590: System Scan violation closing too early - PacketFence

Bug Tracking System

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0001590

PacketFence

scanning

public

2012-10-29 11:20

2015-02-18 10:59

Reporter

jbehrend

Assigned To

Priority

normal

Severity

major

Reproducibility

always

Status

closed

Resolution

open

Platform

OS Version

Product Version

3.5.1

Target Version

investigate

Fixed in Version

Summary

0001590: System Scan violation closing too early

Description

I am trying to implement system scanning on registration with openvas.
The scan job gets created all right, openvas starts scanning but after a
few seconds PF moves the node from the registration vlan to the guest
vlan as if the scan was completed successfully.
My grasp on the subject was that it should wait for the scan to end and
see if there were any issues and _then_ move it to the guest vlan or the
isolation vlan if necessary.

Additional Information

This is the relevant code in
lib/pf/scan.pm:

line 254:
    # Start the scan
    my $failed_scan = $scan->startScan();
### by jan
# $failed_scan = '0';

    # Hum ... somethings wrong in the scan ?
    if ( $failed_scan ) {
        my $cmd = $bin_dir . "/pfcmd manage vclose $host_mac $SCAN_VID";
        $logger->info("TOO EARLY 2: Calling $cmd because failed_scan =
$failed_scan");
        my $grace = pf_run("$cmd");
        # FIXME shouldn't we focus on return code instead of output?
pretty sure this is broken
        if ( $grace == -1 ) {
            $logger->warn("Problem trying to close scan violation");
        }
    }

For some reason calling the start scan command reurns '1'. If I set
failed_scan = 0 all is well with scan report parsing and adding follow
up violations ... not the right way to approach the fix to the problem,
though

These are the corresponding log entries:

Oct 29 15:05:38 pfcmd(4223) TRACE: Scan task creation output:
<create_task_response status="201"
id="67c7f993-e6d1-4071-9bfd-4cd2edac3ecd" status_text="OK, resource
created"></create_task_response> (pf::scan::openvas::createTask)
Oct 29 15:05:38 pfcmd(4223) INFO: Scan task named 135151953699d3f4
successfully created with id: 67c7f993-e6d1-4071-9bfd-4cd2edac3ecd
(pf::scan::openvas::createTask)
Oct 29 15:05:38 pfcmd(4223) INFO: Starting scan task named
135151953699d3f4 (pf::scan::openvas::startTask)
Oct 29 15:05:38 pfcmd(4223) TRACE: Scan task starting command: omp -h
127.0.0.1 -p 9390 -u admin -w Mfe0JK1gD3TySEQVEUQbMxI9TAANYG -X
'<start_task task_id="67c7f993-e6d1-4071-9bfd-4cd2edac3ecd"/>'
(pf::scan::openvas::startTask)
Oct 29 15:05:38 pfcmd(4223) TRACE: Scan task starting output:
<start_task_response status="202" status_text="OK, request
submitted"><report_id>fbcda167-3e34-4310-98fc-4aa32fb22815</report_id></start_task_response>
(pf::scan::openvas::startTask)
Oct 29 15:05:38 pfcmd(4223) INFO: Scan task named 135151953699d3f4
successfully started (pf::scan::openvas::startTask)
Oct 29 15:05:38 pfcmd(4223) TRACE: attempt #0 to run query
scan_update_sql from module scan (pf::db::db_query_execute)
Oct 29 15:05:38 pfcmd(4223) INFO: TOO EARLY 2: Calling
/usr/local/pf/bin/pfcmd manage vclose 00:17:42:2d:d3:f4 1200001 because
failed_scan = 1 (pf::scan::run_scan)
Oct 29 15:05:39 pfcmd(4277) DEBUG: starting to parse 'manage vclose
00:17:42:2d:d3:f4 1200001' (pf::pfcmd::parseCommandLine)
Oct 29 15:05:39 pfcmd(4277) DEBUG: main cmd argument is manage
(pf::pfcmd::parseCommandLine)

Notes
(0003258) fgaudreault (viewer) 2012-10-29 11:21	I tagged the bug as "investigate" so we can reproduce it in the lab and target a version for the fix. Thanks for the report.

(0003913) lmunro (administrator) 2015-02-18 10:59	Obsolete bug tracker entries. PF 4 introduced changes that either make these irrelevant or impossible to reproduce. New issues are moving to github issues.

Issue History
Date Modified	Username	Field	Change
2012-10-29 11:20	jbehrend	New Issue
2012-10-29 11:20	jbehrend	File Added: pf.configs
2012-10-29 11:21	fgaudreault	Target Version	=> investigate
2012-10-29 11:21	fgaudreault	Note Added: 0003258
2015-02-18 10:59	lmunro	Note Added: 0003913
2015-02-18 10:59	lmunro	Status	new => closed

Relationships