Project

General

Profile

Feature #3882

Add OUI database to the base system, remove dependency on nmap

Added by Jim Pingle about 3 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
Start date:
09/22/2014
Due date:
% Done:

0%


Description

Currently some pages that deal with MAC addresses, such as the ARP table and DHCP leases view, show the manufacturer of the device based on the information in the OUI database if it's available. That file is currently supplied by the nmap package when it is installed, but it would be nice to have in the base system without a package dependency.

The data is available from IEEE;
http://standards.ieee.org/develop/regauth/oui/public.html
http://standards.ieee.org/develop/regauth/oui/oui.txt

Attached is a basic script (much room for improvement) that will download the file and massage it into the same format as the nmap OUI list. It should be sufficient to tie the script into the build process to update periodically rather than having the systems all pull it directly from IEEE or us like bogons. Either that or we could keep a copy checked into the main repo as we do with other imported information (such as usr/local/share/mobile-broadband-provider-info/serviceproviders.xml )

update_oui.sh Magnifier (1.34 KB) Jim Pingle, 09/22/2014 09:59 AM

update_oui.sh Magnifier (1.34 KB) Jim Pingle, 11/16/2015 08:16 AM

History

#1 Updated by Jim Pingle almost 2 years ago

The main questions are:
  • Do we ship with a file crafted from the IEEE data or build it dynamically on the box?
  • Do we host a copy of the file on our infrastructure (like bogons) or pull straight from IEEE?
  • How often should it be updated? Does it change that often?

I wouldn't want to rely on the end user boxes pulling from IEEE especially since they could move the file or change the format at any time.

It makes more sense to have the script run on one of our servers periodically and keep a formatted version that can be updated like bogons, though if we automate the process, a change on the IEEE side could break the script/update file and hand out bad data without lots of safety belts.

If it doesn't change that often it may be just as good to keep a copy of the file in the source repo and update it with each release/image build. In terms of work/complexity running the script manually and putting the result in the repo is the easiest solution.

Attaching an updated version of the script since the format of the IEEE source changed slightly.

#2 Updated by Kill Bill almost 2 years ago

Jim P wrote:

I wouldn't want to rely on the end user boxes pulling from IEEE especially since they could move the file or change the format at any time.

Also, the script is not exactly a speed champ - would take minutes on Alix boxes. (Sure could be improved by rewriting the script, but I don't think it's worth the effort.)

If it doesn't change that often it may be just as good to keep a copy of the file in the source repo and update it with each release/image build. In terms of work/complexity running the script manually and putting the result in the repo is the easiest solution.

Frankly, none of the info there is critical, though it's useful to have that in the GUI. I'd say updating it once per release is just enough :-) (Also, if you ship the script, people could always put it to cron or update manually if desired.)

Also available in: Atom PDF