https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-11-16T08:16:14ZpfSense bugtrackerpfSense - Feature #3882: Add OUI database to the base system, remove dependency on nmaphttps://redmine.pfsense.org/issues/3882?journal_id=225152015-11-16T08:16:14ZJim Pingle
<ul><li><strong>File</strong> <a href="/attachments/1440">update_oui.sh</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1440/update_oui.sh">update_oui.sh</a> added</li></ul>The main questions are:
<ul>
<li>Do we ship with a file crafted from the IEEE data or build it dynamically on the box?</li>
<li>Do we host a copy of the file on our infrastructure (like bogons) or pull straight from IEEE?</li>
<li>How often should it be updated? Does it change that often?</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Attaching an updated version of the script since the format of the IEEE source changed slightly.</p> pfSense - Feature #3882: Add OUI database to the base system, remove dependency on nmaphttps://redmine.pfsense.org/issues/3882?journal_id=225162015-11-16T09:44:43ZKill Bill
<ul></ul><p>Jim P wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.)</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.)</p> pfSense - Feature #3882: Add OUI database to the base system, remove dependency on nmaphttps://redmine.pfsense.org/issues/3882?journal_id=360392018-03-08T18:44:15ZJon Gerdesgerdesj@blueloop.net
<ul></ul><p>Why not reuse this: <a class="external" href="https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=manuf;hb=HEAD">https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=manuf;hb=HEAD</a> the license is GPL2.</p>
<p>If it's good enough for the WS community, its good enough for me. It also means that pfSense falls neatly into line with WS for packet capture exports, which are generally read in WS.</p>
<p>That file could be treated similarly to bogons with a, say, one month pull with a random spread across systems:</p>
<p>These lists: <a class="external" href="https://primes.utm.edu/lists/small/millions/">https://primes.utm.edu/lists/small/millions/</a> get you quite a few primes or generate your own and store locally. Randomly pick (with a nod to how much entropy is available on a given platform) one per install/per upgrade/per download/whatever and keep those in a list. Now use those primes to create cronjobs that require downloads. 1 year in seconds is roughly 31.5M. 1 month is 2.6M etc. Scale the time period and pick appropriate primes to generate a time to put into cron. Once the job is done, generate another appropriate prime and update cron. I don't know if something similar to "at" is available in BSD, which might work better with this scheme. With big enough lists of primes and decent spread of time, this should spread the load nicely both on the sources and the firewalls themselves.</p>
<p>I've bodged around one or two problems using prime numbers in scheduled tasks ...</p>