Bug 2022355 - nmap has out of date component
Summary: nmap has out of date component
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nmap
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Osvald 🛹
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-11 12:47 UTC by John Dodson
Modified: 2022-03-26 15:00 UTC (History)
3 users (show)

Fixed In Version: nmap-7.92-1.fc35 nmap-7.92-1.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-25 16:51:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description John Dodson 2021-11-11 12:47:34 UTC
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.

Comment 1 John Dodson 2022-02-22 23:24:22 UTC
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!

Comment 2 Fedora Update System 2022-02-23 13:35:05 UTC
FEDORA-2022-d48d5031c8 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d48d5031c8

Comment 3 Fedora Update System 2022-02-23 13:46:33 UTC
FEDORA-2022-db05340ff9 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-db05340ff9

Comment 4 Fedora Update System 2022-02-23 16:08:35 UTC
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.

Comment 5 Fedora Update System 2022-02-24 01:45:24 UTC
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.

Comment 6 Fedora Update System 2022-02-25 16:51:58 UTC
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.

Comment 7 John Dodson 2022-02-26 01:05:48 UTC
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.

Comment 8 Martin Osvald 🛹 2022-02-28 12:42:30 UTC
(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!

Comment 9 John Dodson 2022-03-02 08:11:59 UTC
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...

Comment 10 Fedora Update System 2022-03-26 15:00:19 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.