PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000831PacketFencepublic2009-10-27 16:532011-01-26 15:43
Reporterobilodeau 
Assigned Toobilodeau 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
Summary0000831: not careful enough when validating uplink parameter in switches.conf causes threads to hang later
Descriptionin SwitchFactory.pm we accept anything has an uplink:

        foreach my $_tmp (@_uplink_tmp) {
            $_tmp =~ s/ //g;
            push @uplink, $_tmp;
        }

but later down the road we compare uplink in an explicitly numerical way

        if ( $upLinks[0] == -1 ) {
            $logger->warn("Can't determine Uplinks for the switch -> do nothing");

we should validate both places

at first, only "dynamic" (no matter the case) and arbitrary length digits should be accepted

Oct 27 02:02:02 pfcmd(0) INFO: pidof -x pfsetvlan returned 27449 (pf::services::service_ctl)
Argument "dynamic" isn't numeric in numeric eq (==) at
        /usr/local/pf/lib/pf/vlan.pm line 148 (0000001)
    (W numeric) The indicated string was fed as an argument to an operator
    that expected a numeric value instead. If you're fortunate the message
    will identify which operator was so unfortunate.
    
thread failed to start: Can't use string ("0") as a HASH ref while "strict
        refs" in use at /usr/local/pf/lib/pf/violation.pm line 379 (0000002)
    (W threads)(S) The entry point function of threads->create() failed for some reason.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0000809closed obilodeau uplink parameter in switches.conf is case sensitive and our sample config doesn't write dynamic right 
related to 0000832closed obilodeau Warning in vlan.pm around line 152 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-10-27 16:53obilodeauNew Issue
2009-10-27 17:51obilodeauStatusnew => assigned
2009-10-27 17:51obilodeauAssigned To => obilodeau
2009-10-27 17:53obilodeauNote Added: 0001375
2009-10-28 14:08obilodeauRelationship addedrelated to 0000809
2009-10-28 14:25obilodeauNote Added: 0001376
2009-10-28 14:28obilodeauNote Added: 0001377
2009-10-28 14:28obilodeauStatusassigned => resolved
2009-10-28 14:28obilodeauResolutionopen => fixed
2009-10-28 14:31obilodeauRelationship addedrelated to 0000832
2011-01-26 15:43obilodeauStatusresolved => closed

Notes
(0001375)
obilodeau   
2009-10-27 17:53   
it would seem that there is already some validation in lib/pf/services.pm
(0001376)
obilodeau   
2009-10-28 14:25   
necessary fix is twofold:

1- test for empty array in vlan.pm at 150, this is only a warning so it'll be done later

2- on startup we do validate what's a good uplink parameter and we stop pfsetvlan if it's not good

so I loosed up the check to allow the dynamic keyword in an case-insensitive manner, related to our 809 fix already in place:

#
# old_revision [2a026176d98198d30d3f66bd404f6145477832f1]
#
# patch "pf/lib/pf/services.pm"
# from [b7bc8368e2acec7bfd1a5e6c488c1a448596eb10]
# to [64df13883484a57a3eb337b93bcd357ceca3b57a]
#
============================================================
--- pf/lib/pf/services.pm b7bc8368e2acec7bfd1a5e6c488c1a448596eb10
+++ pf/lib/pf/services.pm 64df13883484a57a3eb337b93bcd357ceca3b57a
@@ -994,7 +994,7 @@ sub switches_conf_is_valid {
             my $uplink = $switches_conf{$section}{'uplink'}
                 || $switches_conf{'default'}{'uplink'};
             if (( !defined($uplink) )
- || ( ( $uplink ne 'dynamic' )
+ || ( ( lc($uplink) ne 'dynamic' )
                     && ( !( $uplink =~ /(\d+,)*\d+/ ) ) )
                 )
             {
(0001377)
obilodeau   
2009-10-28 14:28   
fixed in rev: 0b3b5b3d2519ff23810ec5a0860c9174331defa5
http://mtn.inverse.ca/revision/info/0b3b5b3d2519ff23810ec5a0860c9174331defa5 [^]