You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the oui.txt and iab.txt are supplied statically with the package.
The files are almost always outdated, unless an update for the python package was just being done. As of 0.8.0, the database is from August 2020. Thus, many modern hardware cannot be identified.
Currently, one sees a lot of "fake", i.e. locally administered MACs, because in order to limit tracking, Apple has elected to use "private", or better: random MACs (cf. https://support.apple.com/guide/security/wi-fi-privacy-secb9cb3140c/web). This is not differentiated by the implementation. At least, there should be a predicate that test for locally administered MACs.
See also: opnsense/core#5205 for a typical usecase for this library and why it would be beneficial to fix this here...
Therefore, I suggest offering a way for update the database either manually or regularly. This can easily be done by:
Also, the location of the database files should be selectable and not in the path for the scripts (like /var/lib/netaddr), such that clients may choose where to store those files.
For the second part, I suggest differentiating between "unknown" vendors and "private" MACs by matching for the second nibble of the MAC address:
One could improve that even more by adding some known locally administered MAC prefixes, like '52-54-00' for KVM virtual machines (VMware uses their own 'real' OUI prefixes already). This could be done by appending to oui.txt like so:
Currently, the oui.txt and iab.txt are supplied statically with the package.
See also: opnsense/core#5205 for a typical usecase for this library and why it would be beneficial to fix this here...
Therefore, I suggest offering a way for update the database either manually or regularly. This can easily be done by:
or better in python as an API function.
Also, the location of the database files should be selectable and not in the path for the scripts (like /var/lib/netaddr), such that clients may choose where to store those files.
For the second part, I suggest differentiating between "unknown" vendors and "private" MACs by matching for the second nibble of the MAC address:
One could improve that even more by adding some known locally administered MAC prefixes, like '52-54-00' for KVM virtual machines (VMware uses their own 'real' OUI prefixes already). This could be done by appending to oui.txt like so:
The text was updated successfully, but these errors were encountered: