$100 for MAC prefix to vendor resolution
-
Do you think it is good idea to modify pfsense-utils.inc by replacing it from a package? especially now when pfSense-2.0 is still beta and this file can be easily changed by any commit…
Probably community should decide on whether we need this functionality at all? It looks nice but is it needed? -) -
I've requested merge.
-
I am sorry but this can be a package per se and does not need to be in pfSense.
In the package you can put a page same as status->dhcp_leases with your extra changes. This way you make sure nmap is installed.That is just my opinion.
-
Anyway it seems topic starter is not interested anymore.
-
So after sending you on that journey, he ended up reneging on the bounty he offered up?
-
@submicron:
So after sending you on that journey, he ended up reneging on the bounty he offered up?
Well… I haven't heard anything from him/her since his/her last post.
I'll probably do a package as ermal and Perry suggested as major job is done here -) -
Give them a little while and if you don't get a response in a few days/weeks, we can always issue a bountypig. ;)
-
I am not sure I know what bountypig is but anyway can we decide on preferable design please? We do not need nmap to be installed for this to work. We need the only one file nmap-mac-prefixes which is a text file with pairs MAC(3 octets) - Vendor name. We can put this file whenever we want and make this stuff independent of nmap package.
So two variants:- It is in 'mainline' but we permanently store mac-prefixes file somewhere.
- A package that replaces pfsense-utils.inc, diag_arp.php, status_dhcp_leases.php, status_interfaces.php and installs mac-prefixes file. We can even leave pfsense-utils.inc untouched if we put function load_mac_manufacturer_table() in all of the rest files.
What variant would be preferable?
Thanks. -
What is the license on that nmap file? Is it BSD, MIT, Public Domain, GPL? That may impact if we ship with it or not.
-
What is the license on that nmap file? Is it BSD, MIT, Public Domain, GPL? That may impact if we ship with it or not.
Sorry, I do not know anything about licenses. At the beginning this file states:
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.
Can we create our own 'file'? - as I said it is a text file and I believe this information (MAC ranges assigned to manufacturers) is publicly available. We do not have to use this file from nmap.
-
If it's an IEEE standard file I think it's OK to use theirs, or make a new one from the raw OUI data. If there is no license stated in the nmap file it may be OK to include theirs regardless.
-
Ok. And finally can we have a final word on what variant is preferable - 1) or 2) please?
Thanks. -
-
is probably out for 2.0, but for 2.1 it may be a possibility. We're trying to get RC1 out so adding features at this point isn't really feasible.
-
would be fine as a package, though patches would be better than replacing whole files. I wouldn't bother with an nmap dependency, I'd just include the data file you need.
-
-
Good. I'll go with 2) then without nmap dependency.
Thanks. -
I've created a package, let me know what you think.
Thanks. -
Hey guys, sorry, I haven't been getting any e-mails about replies, and too busy to check the forum.
Evgeniy, looks like I owe you the bounty. Could you please contact me directly at andrew@di.vc? I'm able to pay immediately.
If anyone else thinks I owe him, too, please send in your claims.
Happy new year!
peace…
-
Hi infofarmer,
have you tested this package?
It seems it is not available as was never merged. -
Nope, I haven't. It would be nice to have it upstream, but I can pay now for the work you've already done, and let you get it upstream whenever you have spare time.
-
Nope, I haven't. It would be nice to have it upstream, but I can pay now for the work you've already done, and let you get it upstream whenever you have spare time.
I'll e-mail you my own packages repository server where you can install it from.
-
This is a very cool project / request, Evgeny I am very appreciative for your work and hope it shows up in the main package repository soon. :) The only problem with something like this is that the MAC database can become stale, so it would be nice if you added a mention to one of the pages about the location of the file so a user could manually update it if needed.
