Description of problem: nmap has out of date component vis /usr/share/nmap/nmap-mac-prefixes Version-Release number of selected component (if applicable): 3:7.80-11.fc34 How reproducible: /usr/share/nmap/nmap-mac-prefixes contains an old URL (http://standards.ieee.org/regauth/oui/oui.txt give 404 error) & the data is out of date or incomplete. Steps to Reproduce: 1. compare files /usr/share/nmap/nmap-mac-prefixes & /usr/share/hwdata/oui.txt 2. 3. Actual results: nmap shows a MAC address commencing B0:95:75 as Unknown (not in the file /usr/share/nmap/nmap-mac-prefixes and... 1C:3B:F3 is shown as Unknown also 48:D8:90 is Unknown Expected results: /usr/share/hwdata/oui.txt on FC34 gives TP-LINK TECHNOLOGIES CO.,LTD. and... 1C:3B:F3 is also TP-LINK TECHNOLOGIES CO.,LTD 48:D8:90 is FN-LINK TECHNOLOGY LIMITED Additional info: It might also be clearer what OUIs have been added if there were a comment starting with # at the point in the file where the comment line, in the nmap file /usr/share/nmap/nmap-mac-prefixes # We have added a few unregistered OUIs at the end. becomes relevant.
The composition of the MAC address tables probably now needs to take into account the propensity for devices (like iPhones & others) to change/hide/use non-assigned MAC addresses, which perhaps brings into question the validity of the tables themselves. Personally I like them & want to know the manufacturer of a MAC address, but it seems to be getting harder!
FEDORA-2022-d48d5031c8 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d48d5031c8
FEDORA-2022-db05340ff9 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-db05340ff9
FEDORA-2022-db05340ff9 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-db05340ff9` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-db05340ff9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d48d5031c8 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-d48d5031c8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d48d5031c8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-db05340ff9 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Thanks, some progress with lots of new OUIs, but... The previous version header was, # $Id: nmap-mac-prefixes 38008 2020-09-08 21:08:24Z dmiller $ generated with make-mac-prefixes.pl The new version header is, (still seemingly 6 months old) # $Id: nmap-mac-prefixes 38263 2021-08-06 05:09:06Z dmiller $ generated with make-mac-prefixes.pl # Original data comes from http://standards.ieee.org/regauth/oui/oui.txt # These values are known as Organizationally Unique Identifiers (OUIs) # See http://standards.ieee.org/faqs/OUI.html # We have added a few unregistered OUIs at the end. It would be useful for make-mac-prefixes.pl to be included in the nmap distribution rpm so that it might be improved &/or make it easier to resolve differences between, /usr/share/nmap/nmap-mac-prefixes and /usr/share/hwdata/oui.txt Additionally, The URL given for original data, http://standards.ieee.org/regauth/oui/oui.txt gives a 404 error. So a correct/working URL should be used. As does the other reference URL given, https://standards.ieee.org/faqs/OUI.html There is still no indication in the file where the point referred to in the last comment line above is, ie. where is the end of the data obtained from "standards" & which OUIs have been added? There needs to be a demarcation point, that shows that division.
(In reply to John Dodson from comment #7) > The previous version header was, > # $Id: nmap-mac-prefixes 38008 2020-09-08 21:08:24Z dmiller $ generated with > make-mac-prefixes.pl > > The new version header is, (still seemingly 6 months old) > > # $Id: nmap-mac-prefixes 38263 2021-08-06 05:09:06Z dmiller $ generated with > make-mac-prefixes.pl > # Original data comes from http://standards.ieee.org/regauth/oui/oui.txt > # These values are known as Organizationally Unique Identifiers (OUIs) > # See http://standards.ieee.org/faqs/OUI.html > # We have added a few unregistered OUIs at the end. Yes, that's true, but the upstream seemingly update it only in case of a new release. > It would be useful for make-mac-prefixes.pl to be included in the nmap > distribution rpm so that > it might be improved &/or make it easier to resolve differences between, > > /usr/share/nmap/nmap-mac-prefixes > and > /usr/share/hwdata/oui.txt I would include it, but it appears the script itself and its newest version is no longer available. It got removed in 2006: https://github.com/nmap/nmap/commit/b87a8f98036d8d195cb61eacb953a2958cb09c53 I found it also here (last revision it was included in): https://svn.nmap.org/!svn/bc/4112/nmap/scripts/make-mac-prefixes.pl I will ask the upstream about the new location (if any). > Additionally, > The URL given for original data, > http://standards.ieee.org/regauth/oui/oui.txt > gives a 404 error. So a correct/working URL should be used. > > As does the other reference URL given, > https://standards.ieee.org/faqs/OUI.html I will inform the upstream about this. So far I found out the below should be the correct source (didn't find the URL for faq yet): https://standards-oui.ieee.org/oui/oui.txt (or just https://standards-oui.ieee.org/) > There is still no indication in the file where the point referred to in the > last comment line above is, > ie. where is the end of the data obtained from "standards" & which OUIs have > been added? > There needs to be a demarcation point, that shows that division. I executed the mentioned make-mac-prefixes.pl and ran it against the newest oui.txt. In connection with what the last line of the script contains: ~~~ 77 # Now add a few extras which aren't oficially registered ... 78 print OUTFILE "525400 QEMU Virtual NIC\nB0C420 Bochs Virtual NIC\nDEADCA PearPC Virtual NIC\n"; ~~~ and the diff between the 7-month-old nmap-mac-prefixes and the newly generated results it looks the upstream adds only the below MACs: ~~~ 525400 QEMU Virtual NIC B0C420 Bochs Virtual NIC DEADCA PearPC Virtual NIC 00FFD1 Cooperative Linux virtual NIC 080027 Oracle VirtualBox virtual NIC ~~~ Also, it appears there are 1120 missing entries in the current nmap-mac-prefixes after parsing the new oui.txt. Anyway, thanks a lot for your comment!
Thanks for your efforts! It's greatly appreciated. Sadly when you mention upstream, in Eastern Australia at the moment everything is released, coming downstream & flooding us! We are luckier than Ukraine that's for sure! I guess we'll see what the next nmap release brings...
FEDORA-2022-d48d5031c8 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.