parse_oui_database takes in a file path as a &String that is used to open the file in a parsing function. IMO there are a number of problems here.

First, you should almost never take in a &String as a function argument. This basically means you have a reference to a owned object. It forces an allocation of everything passed into the function only to take a reference of it. It excludes types that are simply &strs forcing the caller to convert them to a full String - which involves an allocation. The function should just taking in a &str as it is cheap to convert a String to a &str (cheaper to use than a &String as well as &String have a double redirection).

Sometimes it might be even better might be to take in a impl<AsRef(str)> which means the function can take in anything that can be converted into a &str without the caller needing to do it directly. Though on larger functions like this that might not always be the best idea as it makes it generic and so will be monomorphised for every type you pass into it. This can bloat a binary if you do it on lots of large functions with lots of different input types. You can also get the best of both worlds with a generic wrapper function to a concrete implementation - so the large function has a concrete type &str and a warpper that takes a impl <AsRef<str>> and calls the inner function. Though in this case it is probably easier to just take in a &str and manually convert at all the one call sites.

Second. String/&str are not the write types for paths. Those would be PathBuf and &Path which both work like String and &str (so all the above applies to these as well). These are generally better to use as paths in most OSs dont have to be unicode. Which means there are files (though very rarely) which cannot be represented as a String. This is why File::open takes in a AsRef<Path> which your function can also.

Lastly. I would not conflate opening a file with parsing it. These should be two different functions. This makes the code a bit more flexible - you can get the file to parse from other sources. One big advantage to this would be for testing where you can just have the test data as strings in the test. It also makes the returned error type simpler as one function can deal with io errors and the other with parsing errors. And in this case you can just parse the file directly from the internet request rather than saving it to a file first (though there are other reasons you may or may not want to do this).

Welcome to Rust, I hope you enjoyed learning and using it :)

One major advice would be to run cargo clippy, which gives a lot of helpful hints. Apart from that I also have some feedback.

    40	struct VendorOuiData {
    41	    vendor_organization: String, // Vendor Organization

These comments should be doc-comments (///) so that cargo doc picks them up.

    49	fn fetch_oui_database(url_string: &String) -> Result<String, Box<dyn std::error::Error>> {

Not saying that your return type is bad, but in general you might be interested in crates thiserror and anyhow that simplify error handling.

    51	        .timeout(Duration::new(60, 0))

Duration::from_mins(1) would be much more readable.

    66	                panic!("{}", err);

You should almost never panic. Your function already returns a Result<>, so you should be using that for error handling.

    70	    } else {
    71	        // HTTP Status is not 200

Not Rust specific, but usually I recommend to handle errors first, and return from the function early. This way you reduce cognitive load on the reader, and reduce nesting of if-blocks.

   150	                let mut parts = line.splitn(2, '\t');

There's a convenient method to split in two substrings that you could have used:

let (mac_address, vendor_organization) = line.split_once('\t').unwrap_or(("", ""));

   166	                vendor_oui_data.vendor_address += line
   167	                    .trim()
   168	                    .split(' ')
   169	                    .filter(|s| !s.is_empty())
   170	                    .collect::<Vec<_>>()
   171	                    .join(" ")
   172	                    .as_str();

I would probably write a regular expression that replaces all contiguous whitespace with a single space instead.

   173	                vendor_oui_data.vendor_address.push('\n');

Aren't you trimming this new line off in line 181?

   181	        vendor_oui_data.vendor_address = vendor_oui_data.vendor_address.trim().to_string();

This is somewhat inefficient, since you'll be allocating and copying your string here.

You panic a lot on errors in functions where you return a result. Almost all of these are due to input problems not programming logic errors. These really should be return from the functions as errors so higher up functions can handle them how they might need to rather than just imminently crashing the program. Really panics should only be used when the situation should never occur and if it does that indicates a bug in the program - or you are being lazy with small/test code/one off scripts (but in this case why return any errors at all, you might as well just .unwrap() on everything instead of ?.

I just scrolled through it, so no deep insights, but at first glance it looks pretty good.

One thing I saw, and that probably every rust programmer has to learn in the beginning, is to use slices for function parameters whenever prossible. Pretty much every time you use fn foo(s: &String) you should use fn foo(s: &str) and the same goes for &Vec<T> -> &[T]. Calling these works still the same so just changing the function definitions should work.

The advantage of this is, that now you can use every type that can be dereferenced as the slice, so you can now call foo like this foo("bar"); or with a String foo(&String::from("bar"));. The same applies for &[T] which can be called with &Vec<T> or an array &[T; N]

Only skimmed quickly.

• Four different hex representations for the same 3 bytes is extremely wasteful. You don't need to store more than a [u8; 3]. You can create a "mapped" struct with those representations if caching them is somehow useful for the use-case. And since we're micro-optimizing memory usage, Box<str> instead of String (for the two fields with actual string data) would be more efficient since those values are not meant to be mutable. You can then serialize to one of the many efficient binary formats around (e.g. borsh). This is not JavaScript, so you can oftentimes not be bound to JSON.
• Your parsing code looks both unrobust (potentially fragile hard-coded assumptions) and unnecessarily complex. Something much simpler can probably be done with some trivial regex usage.

This is a pet peeve of mine, but don't put main last. Its like opening a book to be greeted by a random chapter - probably one near the end and you have to hunt through it to find where the story actually starts, which is probably near the end.

This is a IMO horribly hangup from languages that require you to declare something before you can use it. You don't need to do that in rust. So put your functions in order that makes sense to read them from top to bottom. This typically means main should be one of the first functions you see - as it is the entry point to the code. In other files this might be the main functions a user is expected to use first. Sometimes you might want to see some datastructures before that. But overall things should be ordered by how it makes sense to read them to make it easier to make sense of the program.