Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Net-MAC-Vendor CPAN distribution.

Report information
The Basics
Id: 79369
Status: resolved
Priority: 0/
Queue: Net-MAC-Vendor

People
Owner: Nobody in particular
Requestors: jdalberg [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.18
Fixed in: (no value)



Subject: IEEE data parsing
Download (untitled) / with headers
text/plain 954b
It seems that the data downloaded from http://standards.ieee.org/develop/regauth/oui/oui.txt which is used for cache parsing now contains PRIVATE sections not separated from other OUI sections with the traditional \n\n, but with \n\s*\n. This means that when trying to lookup an OUI that has a PRIVATE out as a neighbor, you will get two entries in the result, i.e. try looking up 00-00-6D. This should yield a list with the first entry containing "CRAY COMMUNICATIONS, LTD.", and the last "UNITED KINGDOM", instead the first entry is "PRIVATE". It also seems that IEEE's internal lookup function, http://standards.ieee.org/cgi- bin/ouisearch, also used by Net::MAC::Vendor also has this problem, since it to will return two entries when asked for 00-00-6D. I have contacted them about the problem, but still, I guess Net::MAC::Vendor has to take this into account, so I also supply a patch with this PR that should help alleviate the problem.
Subject: Vendor.pm.patch
Download Vendor.pm.patch
text/x-diff 1.3k
--- Vendor.pm.orig 2012-09-03 14:41:13.000000000 +0200 +++ Vendor.pm 2012-09-03 14:41:28.000000000 +0200 @@ -198,7 +198,7 @@ sub fetch_oui_from_ieee parse_oui( extract_oui_from_html( - get( "http://standards.ieee.org/cgi-bin/ouisearch?$mac" ) + get( "http://standards.ieee.org/cgi-bin/ouisearch?$mac" ), $mac ) ); } @@ -239,13 +239,28 @@ mean unexpected input or a change in for sub extract_oui_from_html { my $html = shift; + my $mac = shift; - my( $oui ) = $html =~ m|<pre>(.*?)</pre>|gs; - return unless defined $oui; + my( $ouis ) = $html =~ m|<pre>(.*?)</pre>|gs; + return unless defined $ouis; - $oui =~ s|</?b>||g; + my @entries = split /\n\s*\n/, $ouis; + return unless defined $entries[0]; + return $entries[0] unless defined $entries[1]; + + my $entry = $entries[0]; + foreach my $e ( @entries ) + { + $e =~ s/^\s+|\s+$//; + $e =~ s/<\/?b>//gs; + my $foo = substr $e, 0, 8; + if ( $foo eq $mac ) { + $entry = $e; + last; + } + } - return $oui; + return $entry; } =item parse_oui( STRING ) @@ -308,7 +323,7 @@ sub load_cache return; } - my @entries = split /\n\n/, $data; + my @entries = split /\n\s*\n/, $data; shift @entries; my $foo = '';
This should be fixed in 1.19_01. If the CPAN Testers like it, that will become 1.20. Thanks,


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.