abaumhauer / eui48 Goto Github PK

View Code? Open in Web Editor NEW

18.0 18.0 23.0 91 KB

Rust implementation of IEEE EUI-48 datatype, also known as MAC-48 for network Media Access Control addressing

License: Apache License 2.0

Rust 100.00%

crates eui macaddr macaddress networking rust

eui48's People

Contributors

Stargazers

Watchers

eui48's Issues

Index out of range panic when displaying ParseError::InvalidByteCount

The following code panics:

fn main() {
    println!("{}", eui48::MacAddress::parse_str("123456ABCDEF1").unwrap_err());
}

ohazi@avocado:~/source/eui48_index_out_of_range$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/eui48_index_out_of_range`
thread 'main' panicked at /home/ohazi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eui48-1.1.0/src/lib.rs:300:21:
range end index 7 out of range for slice of length 6
stack backtrace:
   0: rust_begin_unwind
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
   2: core::slice::index::slice_end_index_len_fail_rt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:76:5
   3: core::slice::index::slice_end_index_len_fail
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:68:9
   4: <core::ops::range::Range<usize> as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:408:13
   5: <core::ops::range::RangeTo<usize> as core::slice::index::SliceIndex<[T]>>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:455:9
   6: core::slice::index::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:18:9
   7: core::array::<impl core::ops::index::Index<I> for [T; N]>::index
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/array/mod.rs:348:9
   8: <eui48::ParseError as core::fmt::Display>::fmt
             at /home/ohazi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/eui48-1.1.0/src/lib.rs:300:21
   9: core::fmt::rt::Argument::fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/rt.rs:142:9
  10: core::fmt::write
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/mod.rs:1120:17
  11: std::io::Write::write_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/mod.rs:1762:15
  12: <&std::io::stdio::Stdout as std::io::Write>::write_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/stdio.rs:727:9
  13: <std::io::stdio::Stdout as std::io::Write>::write_fmt
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/stdio.rs:701:9
  14: std::io::stdio::print_to
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/stdio.rs:1020:21
  15: std::io::stdio::_print
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/stdio.rs:1097:5
  16: eui48_index_out_of_range::main
             at ./src/main.rs:2:5
  17: core::ops::function::FnOnce::call_once
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
ohazi@avocado:~/source/eui48_index_out_of_range$

The culprit is this line: https://github.com/abaumhauer/eui48/blob/master/src/lib.rs#L300

In ParseError::InvalidByteCount(found, eui), found is the number of bytes encountered (in this case seven bytes, more than the expected six bytes), and eui is the eui48 that was created out of the first six bytes. You cannot index into eui beyond six, which is what &eui[..found] on line 300 appears to be trying to do.

is_unicast() and is_local() return bad results

is_unicast() and is_local() functions did not correctly check the low order bits in the highest octet due to a logic error. #9

eui48 into the standard library for rust?

Hi @abaumhauer,

Have you considered creating an RFC (I could assist) to get this work merged into the rust standard library? I find it surprising that std::net only caters for IP addresses, even though anyone doing anything remotely serious with networking would probably also be interested in Mac addresses?

For example, diesel recently added support for Postgres' MAC address data type, but they implemented it as a simple [u8; 6]. Having interoperability between crates by using a standardised type might be quite awesome.

Cheers,

Feature Request std::cmp::Ord trait

Could the eui48::MacAddress implement std::cap::Ord? I am happy to try to help if needed. I am just learning rust, so I may not be a lot of help. But am happy to try.

The address parser doesn't do any usefull validation

The mac address parser is way to lenient. It will accept any character as delimiter. It accepts these as input:
c9L3AsB7q12N34r56 => c9:3a:b7:12:34:56
effect affect => ef:fe:0c:af:fe:0c

It is ok to cope with some odd input, but this is like no validation is done at all.

correct link to documentation

The documentation link on crates.io and in the README https://doc.rust-lang.org/eui48 returns an 404 error

Disable the rustc-serialize feature by default

rustc-serialize has been deprecated for a long time now. The next breaking change release should disable it by default, or drop support entirely.

Export to Eui48 array

Some existing modules have been already written to use [u8; 6] as a storage type to store an EUI48 style Mac addresses, and their APIs are defined to be so.

Importing their data to eui48::MacAddress is feasible via MacAddress::new(), but exporting eui48::MacAddress to [u8; 6] is not directly feasible, but would require separate implementation.

This issue is to propose to implement pub fn MacAddress::to_array(&self) -> Eui48 {}, which works as an inverse function of ::new().

Missing .travis.yml file

Big binary size

I have this code:

fn main() {
    eui48::MacAddress::parse_str("00:11:22:33:44:55").unwrap();
}

When I compile with eui48's master branch and release profile, I get a binary of 1.4mb:

oblique@dystopia /~tmp/eui48-example
% cargo build --release
   Compiling memchr v2.4.1
   Compiling regex-syntax v0.6.25
   Compiling rustc-serialize v0.3.24
   Compiling aho-corasick v0.7.18
   Compiling regex v1.5.4
   Compiling eui48 v1.1.0 (/home/oblique/git/eui48)
   Compiling eui48-example v0.1.0 (/tmp/eui48-example)
    Finished release [optimized] target(s) in 17.78s

oblique@dystopia /tmp/eui48-example
% strip target/release/eui48-example

oblique@dystopia /tmp/eui48-example
% du -h target/release/eui48-example
1.4M	target/release/eui48-example

I noticed that you do not use any unicode features of regex, so I changed regex dependency of eui48's Cargo.toml to:

regex = { version = "1.3.9", default-features = false, features=["std"], optional = false }

and then I got a binary of 604kb:

oblique@dystopia /tmp/eui48-example
% cargo build --release
   Compiling regex-syntax v0.6.25
   Compiling regex v1.5.4
   Compiling eui48 v1.1.0 (/home/oblique/git/eui48)
   Compiling eui48-example v0.1.0 (/tmp/eui48-example)
    Finished release [optimized] target(s) in 8.42s

oblique@dystopia /tmp/eui48-example
% strip target/release/eui48-example

oblique@dystopia /tmp/eui48-example
% du -h target/release/eui48-example
604K	target/release/eui48-example

I decided to write the parsing manually and I got a binary of 264kb:

oblique@dystopia /tmp/eui48-example
% cargo build --release
   Compiling eui48 v1.1.0 (/home/oblique/git/eui48)
   Compiling eui48-example v0.1.0 (/tmp/eui48-example)
    Finished release [optimized] target(s) in 0.55s

oblique@dystopia /tmp/eui48-example
% strip target/release/eui48-example

oblique@dystopia /tmp/eui48-example
% du -h target/release/eui48-example
264K	target/release/eui48-example

Also in the latest case, compilation time is under a second.

Use is_human_readable methods with serde

Currently, a cargo feature controls whether a MAC is (de)serialized as a formatted string or in binary. Since cargo features are resolved once for every dependency tree, it is impossible to use this crate for both formats in the same application, even through different crates (no direct dependency). serde has a helper method for determining whether the format should use a text or binary representation where both are possible, you should probably use that instead:

Compile time feature to use MacAddressFormat::HexString

A canonical display format of MacAddress, which uses '-' separator, is losing its popular adoption in industry uses. Instead HexString format, which uses ':' separator is more widely used.

This issue is to propose to add a conditional compiler feature, "disp_hexstring". This feature enforces the Display format to use HexString, as used in Debug, and eliminates a burden to explicitly specify the format type in every display case.

Maintenance status ?

Hey there,
First, thanks for this library, we use it at work in a bunch of places!

I noticed several PRs are pending and the crate hasn't been updated in a while.

Would you be interested in introducing additional maintainers ? I'd be glad to help!

abaumhauer / eui48 Goto Github PK

eui48's People

Contributors

Stargazers

Watchers

Forkers

eui48's Issues

Recommend Projects

Recommend Topics

Recommend Org