shellrow / netdev Goto Github PK

View Code? Open in Web Editor NEW

64.0 3.0 10.0 238 KB

Cross-platform library for network interface and gateway. Written in Rust.

License: MIT License

Rust 100.00%

rust rust-library rust-crate network network-inference gateway

netdev's Introduction

shellrow

Languages and Tools

Stats

Support

netdev's People

Contributors

Stargazers

Watchers

Forkers

eldad kingtous feifeigood dignifiedquire link2xt edamametechnologies franciraldo cyberhive brainplot

netdev's Issues

[Feature Request] dns

Would be nice to be able to get the dns.
Thanks!

Ideally `get_interfaces()` should return an `Iterator`

Returning some iterator type instead of the whole Vec directly would allow consumers to have more control over how memory is allocated.

This, however, would be a pretty major breaking change in the public API. If you agree with this change, I can attempt writing a PR.

Upgrade windows dependency

Looks like there is a security advisory for the currently used version out: https://rustsec.org/advisories/RUSTSEC-2022-0008

Announcement: Rebranding to netdev

About Rebranding

default-net is going to be rebranded as netdev starting from v0.23.0.
This rebranding reflects our commitment for future expansion, continuation, and better alignment with naming conventions.

As a part of this transition, v0.22.0 will be the final release under the default-net name.
All subsequent releases will be under the netdev name.

This rebranding will better align the library with its functionality and future development plans.
Thank you for your continued support and we look forward to bringing you more updates under the netdev brand.

Thank you.

Related release

`default-net` final release `v0.22.0` changes

Notice for users. (Mainly for crates.io README)

`netdev` `v0.23.0` changes

Support IPv6 gateway (route)
Support DNS Server
Support friendly_name for macOS
Replace Gateway to NetworkDevice
- Interface.gateway
Fix MacOS bug in get route info
Some refactoring

Interface Utilization

Is getting interface utilization like send and receive in the scope?

[Feature Request] Interface Speed

Would be nice to be able to get the interface's rated speed. for example 1000mbps for 1 gigabit, 10000mbps for 10 gigabit

Default Gateway not found on macos

Default gateway detection doesn't seem to work on macos, it fails with "Default Gateway not found" for me when calling
default_net::get_default_gateway().

Unexpected behaviour when no gateway is set

Tested on (raspbian) Linux.

Steps to reproduce:

Have a pi running on 192.168.1.101. In this case, file /etc/dhcpcd.conf (note this ends with cd.conf) contains a section,

interface wlan0
static ip_address=192.168.1.101
static routers=192.168.1.1
static domain_name_servers=8.8.8.8
static domain_search=

interface eth0
static ip_address=192.168.1.101
static routers=192.168.1.1
static domain_name_servers=8.8.8.8
static domain_search=

compile and run the example code
This gives the following output, as expected:

Default Interface
	Index: 2
	Name: eth0
	Friendly Name: None
	Description: None
	Type: Ethernet
	MAC: e2:5f:21:41:11:b2
	IPv4: [Ipv4Net { addr: 192.168.1.101, prefix_len: 24, netmask: 255.255.255.0 }]
	IPv6: [Ipv6Net { addr: fe80::217f:fa11:4a86:38fa, prefix_len: 64, netmask: ffff:ffff:ffff:ffff:: }]
	Flags: 69699
	Transmit Speed: Some(1000000000)
	Receive Speed: Some(1000000000)
Default Gateway
	MAC: 8c:59:73:65:ba:d8
	IP: 192.168.1.1

Now we edit the above section to read,

interface eth0
static ip_address=192.168.1.101
static routers=
static domain_name_servers=
static domain_search=

(the wlan interface is removed altogether).
We then reboot the pi. The above is intended to create an air-gapped network environment.

Running the code again results in

Default Interface
	Index: 7
	Name: vethc3d719f
	Friendly Name: None
	Description: None
	Type: Ethernet
	MAC: 56:12:1f:7d:6f:98
	IPv4: [Ipv4Net { addr: 169.254.125.86, prefix_len: 16, netmask: 255.255.0.0 }]
	IPv6: [Ipv6Net { addr: fe80::e330:9b42:1990:d81a, prefix_len: 64, netmask: ffff:ffff:ffff:ffff:: }]
	Flags: 69699
	Transmit Speed: Some(10000000000)
	Receive Speed: Some(10000000000)
Default Gateway: (Not found)

While the transmit/receive speed of this interface is reportedly higher than eth0/wlan0, it's a virtual device (pointing to master br-ef67...49):

5: br-ef6764190849: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:32:16:c3:bd:6b brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-ef6764190849
       valid_lft forever preferred_lft forever
    inet6 fe80::42:c6ff:fec3:ad6b/64 scope link 
       valid_lft forever preferred_lft forever
7: veth06ee6be@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ef6764190849 state UP group default 
    link/ether 5e:b1:24:aa:38:cf brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.243.193/16 brd 169.254.255.255 scope global noprefixroute veth06ee6be
       valid_lft forever preferred_lft forever
    inet6 fe80::5cb1:14ff:fea8:f8cf/64 scope link 
       valid_lft forever preferred_lft forever

In the pi's GUI I have disabled all interfaces but eth0.
/etc/interfaces points to /etc/itnerfaces.d/ which is empty.
On login I get

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

showing that the wlan interface has been switched off.

The actual hardware devices eth0, having been assigned 192.168.1.101, is still available for LAN traffic, however. What could be the reason it is not chosen as default once the gateway has been removed?

a strange bug?

sorry to bother you.
my environment:

Windows 11 21H2 22000.493
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active rustc version is rustc 1.58.1 (db9d1b20b 2022-01-20)
vscode
China mainland with proxy software.

detail:
when compiling my project, i find a strange bug from your project.
my code [example]:

always show:

and I found your project level by level finally.
the code which may have problem in my PC as follows. but i can't find a problem.

OK:

Failed:

i change the "1.1.1.1:80" to other ip which is not polluted by gov, still compile failed.

Packet.lib needed

Compile fails if Packet.lib is not in library path. There may be other issues compiling the example. Please expand the Readme as necessary to compile on clean system. I will create a pull request if I figure it out on my own.

FYI Winpcap has ceased development so if the Packet.lib is from winpcap perhaps we need to look to a different library.

Thank you for the library.
Paul

Here is the error message I received when compiling.
= note: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.29.30037\bin\HostX64\x64\link.exe" "/NOLOGO" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.1igodiqjgaoawuu9.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.1pg9t9ql7fg0osqp.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.2kw316jmo9acqzp1.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.3aa76zcs7j6jo6kg.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.40r240ybsdb7b1fl.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.42991ni7oufsb6db.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.4bfrclxrkvhnm0ab.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.4em406slwu7ocilq.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.4rfbv62pj6vvcywp.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.hqg58zfik31b434.rcgu.o" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.429h0472lilcpk60.rcgu.o" "/LIBPATH:C:\Users\paul\Source\rust\netinfo\target\debug\deps" "/LIBPATH:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libdefault_net-bda7b53030479e75.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libpnet_datalink-dca08bed085d0a8a.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libpnet_sys-91cb00b2b318454a.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libwinapi-47cc40cf81da0692.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\liblibc-72f74b019795b39c.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libipnetwork-cfbeee74a5d63926.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libserde-5e823267d5146cc6.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libpnet_packet-fe834420d891dccd.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libpnet_macros_support-4ad153696a9ae314.rlib" "C:\Users\paul\Source\rust\netinfo\target\debug\deps\libpnet_base-5b282237a1301c1f.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-d993d47465b92f2a.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libpanic_unwind-37c7849311f1d8d4.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd_detect-fd48b10da935ab5c.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_demangle-5e024ec6c173f149.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libhashbrown-3540b4805db710ba.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_std_workspace_alloc-637fbf9b0af4e593.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libunwind-3da750ed88354bea.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcfg_if-5a35687d8624bf69.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liblibc-5c6e234e3431724c.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc-332dac34332299ae.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_std_workspace_core-665ed95809278e59.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcore-c2100e40c13f915d.rlib" "C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcompiler_builtins-360663394438793f.rlib" "iphlpapi.lib" "Packet.lib" "advapi32.lib" "cfgmgr32.lib" "kernel32.lib" "user32.lib" "ws2_32.lib" "kernel32.lib" "ws2_32.lib" "bcrypt.lib" "advapi32.lib" "userenv.lib" "kernel32.lib" "msvcrt.lib" "/NXCOMPAT" "/LIBPATH:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "/OUT:C:\Users\paul\Source\rust\netinfo\target\debug\deps\netinfo.exe" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\intrinsic.natvis" "/NATVIS:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\liballoc.natvis" "/NATVIS:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\libcore.natvis" "/NATVIS:C:\Users\paul\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\libstd.natvis"
= note: LINK : fatal error LNK1181: cannot open input file 'Packet.lib'

how to obtaing the Gateway or Peer IP when using a VPN

In MacOS using command scutil --nwi returns the VPN server, how to achieve the same natively with rust, any ideas?

Feature request: netmask

Nice one. Would it be possible to add the netmask to the interface structure?

Replace deprecated _kSCNetworkInterfaceTypeBridge symbols

I'm writing to bring to your attention that Apple has deprecated the _kSCNetworkInterfaceTypeBridge symbols. This could potentially lead to issues or compatibility problems in the future. I would like to inquire if it's possible to replace these symbols with a more up-to-date alternative in your library.

Context

Symbol: _kSCNetworkInterfaceTypeBridge
Deprecated by Apple

Additional Information

If you need any further information or assistance, please let me know. I'd be happy to help in any way possible.

Thank you for your attention to this matter, and for your continued work on this library!

Name is not interface name

Expecting name to be something like Ethernet 2, Ethernet 3 rather than a GUID.

Update `windows` dependency to 0.48.0

Current dependency is 0.32.0 which is outdated.

Maybe it should be listed as windows = "0" so the library does not force particular version on the user.

get_interfaces does'nt return gateway for all the interfaces

When I call get_interfaces to list all the interfaces my computer has, it shows all them BUT the only interface that has a gateway listed is the default one. The remaining WAN ports doesn't show a gateway, although OpenWRT interface shows one for them.

[Feature Request] dhcp

Maybe it is nice to check the interface configured dhcp client or not for all platform

Bug in sockaddr_to_network_addr

on any platform other than android, this function is not working at all like intended.
the transmute is not working and the sockaddr_dl it produces is invalid: check any member of it, they are all wrong. the only part that is ok is sdl_data that contains sa_data, which is not what was expected anyway.

fix is here:
https://git.nextgraph.org/NextGraph/default-net/commit/a06134963af02c415fda83a9d270499118ff6570

/dev/bpf* requires elevated permissions?

On macOS Monterey I have numeric interfaces

$ ls /dev/bpf*
/dev/bpf0	/dev/bpf1	/dev/bpf2	/dev/bpf3

But opening them gives a

Permission denied (os error 13)
-1 Permission denied (os error 13)         
-1 Permission denied (os error 13)       
-1 Permission denied (os error 13)

Is that expected? Would you be open to a different implementation that doesn't require elevated privs?

[FeatrueRequest] iface link state

Would be nice to be able to get link state(linkup and linkdown) of the iface.
Thanks!

Slow execution

default_net::get_interfaces() takes 3 seconds on my ryzen 9 3900x cpu on windows 11.
Seems like an extremely long time for such info?

If connected via Wi-Fi the default network interface is not found on Windows

If the default network interface is the Wi-Fi adapter get_default_interface returns None because the Wi-Fi interface is not enumerated.

When connected via Wi-Fi GetAdaptersInfo returns the interface type IF_TYPE_IEEE80211, this is skipped so the interface is not added to the vector of interfaces.

https://docs.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_info

[Feature Request] Interface Type

Would be nice to be able to get interface type. Mainly looking for Ethernet and wireless type.

List of windows interface types for reference https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.networkinterfacetype?view=net-6.0

im sure linux and osx have their equivalent.

Fails to build on FreeBSD

Hello,

When I try to build the crate on FreeBSD 13.2 this error pops up(it works just fine on Linux):

default-net-0.20.0/src/bpf/binding.rs:82:1
   |
69 | pub struct bpf_hdr {
   | ------------------ previous definition of the type `bpf_hdr` here
...
82 | pub struct bpf_hdr {
   | ^^^^^^^^^^^^^^^^^^ `bpf_hdr` redefined here
   |
   = note: `bpf_hdr` must be defined only once in the type namespace of this module

There's two distinct definitions of that struct so I assume one applies to some OS(es) but not others

One idea would be to remove

pub struct bpf_hdr {
    pub bh_tstamp: libc::timeval,
    pub bh_caplen: u32,
    pub bh_datalen: u32,
    pub bh_hdrlen: libc::c_ushort,
}

and to add something like this?

#[repr(C)]
pub struct bpf_hdr {
    #[cfg(any(target_os = "freebsd", target_os = "netbsd"))]
    pub bh_tstamp: libc::timeval,
    #[cfg(not(any(target_os = "freebsd", target_os = "netbsd")))]
    pub bh_tstamp: timeval32,
    pub bh_caplen: u32,
    pub bh_datalen: u32,
    pub bh_hdrlen: libc::c_ushort,
}

or maybe the cfg for the struct fields should be the other way around.

thanks very much!

MacOs panic

We have observed an assertion failure in the version assertion in gateway/macos.rs as follows:

thread '<unnamed>' panicked at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/gateway/macos.rs:293:9:
assertion `left == right` failed
  left: 0
 right: 5
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::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:279:5
   4: default_net::gateway::macos::list_routes
             at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/gateway/macos.rs:293:9
   5: default_net::gateway::macos::get_default_route
             at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/gateway/macos.rs:412:11
   6: default_net::gateway::macos::get_default_gateway
             at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/gateway/macos.rs:431:26
   7: default_net::interface::unix::interfaces
             at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/interface/unix.rs:63:27
   8: default_net::interface::get_default_interface
             at /Users/andyduplain/.cargo/registry/src/index.crates.io-6f17d22bba15001f/default-net-0.17.0/src/interface/mod.rs:134:38

There is only one assert in the macos.rs code,

        assert_eq!(rt_hdr.rtm_version as u32, RTM_VERSION);

which is called after the error check:

        let rt_hdr = unsafe { std::mem::transmute::<_, &rt_msghdr>(buf.as_ptr()) };
        assert_eq!(rt_hdr.rtm_version as u32, RTM_VERSION);
        if rt_hdr.rtm_errno != 0 {
            return Err(code_to_error(rt_hdr.rtm_errno));
        }

Perhaps the error check should go before the assertion?

Before jumping in, note we're currently using 0.17.0.
As a version 0.21.0 is available at the time of this writing, we'll try with the most recent version of the crate and report back.