PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001109PacketFenceerror-handlingpublic2010-11-03 12:322012-10-19 10:20
Reporterrafamiga 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version1.9.1 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
Summary0001109: Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/vendor_perl/5.8.8/Net/MAC/Vendor.pm line 243 (/bugs/view.php?id=1)
Description[17:18:32 0.12] root@niach:/etc/raddb# ~/pf/bin/pfcmd lookup node c8:bc:c8:6b:36:1c
Use of uninitialized value in pattern match (m//) at
    /usr/lib/perl5/vendor_perl/5.8.8/Net/MAC/Vendor.pm line 243 (0000001)
    (W uninitialized) An undefined value was used as if it were already
    defined. It was interpreted as a "" or a 0, but maybe it was a mistake.
    To suppress this warning assign a defined value to your variables.
    
    To help you figure out what was undefined, perl tells you what operation
    you used the undefined value in. Note, however, that perl optimizes your
    program and the operation displayed in the warning may not necessarily
    appear literally in your program. For example, "that $foo" is
    usually optimized into "that " . $foo, and the warning will refer to
    the concatenation (.) operator, even though there is no . in your
    program.
    
Steps To Reproduce
Additional InformationThis happens for this particular MAC, which belongs an iPad device. I tried this:

mysql -e 'select mac from node' pf | xargs -n 1 -i ~/pf/bin/pfcmd lookup node {}

and only three nodes caused error (sic!). What's more interesting, when I re-checked the other two, I'm now getting a clean response, with no error on "pfcmd lookup node ..." but c8:bc:c8:6b:36:1c gives me consistent error.

I can't rally tell why both CLI and web fails for this node.

Nevertheless, maybe a sanity check near line 243 of /usr/lib/perl5/vendor_perl/5.8.8/Net/MAC/Vendor.pm will prevent this from happening.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-11-03 12:32rafamigaNew Issue
2010-11-03 12:35rafamigaNote Added: 0001752
2010-11-19 14:38obilodeauTarget Version => 2.1.0
2010-11-19 14:41obilodeauCategory1.9.x => error-handling
2011-02-03 10:29obilodeauStatusnew => assigned
2011-02-03 10:29obilodeauAssigned To => obilodeau
2011-02-03 10:30obilodeauNote Added: 0001849
2011-02-03 10:31obilodeauStatusassigned => feedback
2011-02-03 10:48obilodeauNote Added: 0001852
2011-03-03 15:15obilodeauTarget Version2.1.0 => +1
2011-03-03 15:18obilodeauTarget Version+1 => +2
2011-03-07 11:30obilodeauNote Added: 0001900
2011-03-07 11:30obilodeauStatusfeedback => resolved
2011-03-07 11:30obilodeauResolutionopen => no change required
2011-05-04 11:51obilodeauStatusresolved => closed
2012-10-19 10:20fgaudreaultAssigned Toobilodeau =>
2012-10-19 10:20fgaudreaultTarget Version+2 =>

Notes
(0001752)
rafamiga   
2010-11-03 12:35   
As I thought,

print "undef\n" if ($html == undef);

brings "undef" for this particular node only. But I don't really have a clue how to check what causes such behavior.
(0001849)
obilodeau   
2011-02-03 10:30   
> Nevertheless, maybe a sanity check near line 243 of /usr/lib/perl5/vendor_perl/5.8.8/Net/MAC/Vendor.pm will prevent this from happening.

Problem is that Net::MAC::Vendor is an upstream module, it's not our code.

Can you reproduce the problem with PF 2.0.1?
(0001852)
obilodeau   
2011-02-03 10:48   
If you can reproduce with 2.0.1 can you try the patch I attached to 0001173?

Thanks
(0001900)
obilodeau   
2011-03-07 11:30   
Unable to reproduce and we properly handle Net::MAC::Vendor's return values where we use lookup().

Closing: lack of feedback and issue most probably already handled upstream