$100 for MAC prefix to vendor resolution
-
@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.
-
Please do not append feature requests to active bounty projects unless you are willing to offer money to the bounty.
-
removed
sorry -
Or use the super secret unlinked pkg_mgr_settings.php to put in the alternate package URL, no editing of files required (only works on 2.0)
Serious though if you have it in package form (as a patch file against the package system perhaps, a git diff or diff -rub between a stock package repo and yours) it's easy for us to add it in.
It's when people don't have it in package form ("Here, upload all these files") that it's hard.
-
Serious though if you have it in package form (as a patch file against the package system perhaps, a git diff or diff -rub between a stock package repo and yours) it's easy for us to add it in.
Sorry, I do not get you… it's in your git since November 26th.
-
Ah, I see it there now. I didn't know it was there.
