yaa110/async-tun

Asynchronous allocation of TUN/TAP devices in Rust using async-std

Async TUN/TAP

Asynchronous allocation of TUN/TAP devices in Rust using async-std. Use tokio-tun for tokio version.

Getting Started

• Create a tun device using TunBuilder and read from it in a loop:

async fn async_main() -> Result<()> {
    let tun = TunBuilder::new()
        .name("")            // if name is empty, then it is set by kernel.
        .tap(false)          // false (default): TUN, true: TAP.
        .packet_info(false)  // false: IFF_NO_PI, default is true.
        .up()                // or set it up manually using `sudo ip link set <tun-name> up`.
        .try_build()         // or `.try_build_mq(queues)` for multi-queue support.
        .await?;

    println!("tun created, name: {}, fd: {}", tun.name(), tun.as_raw_fd());

    let mut reader = tun.reader();
    let mut buf = [0u8; 1024];
    loop {
        let n = reader.read(&mut buf).await?;
        println!("reading {} bytes: {:?}", n, &buf[..n]);
    }
}

fn main() -> Result<()> {
    task::block_on(async_main())
}

• Run the code using sudo:

➜  sudo -E /path/to/cargo run

• Set the address of device (address and netmask could also be set using TunBuilder):

➜  sudo ip a add 10.0.0.1/24 dev <tun-name>

• Ping to read packets:

➜  ping 10.0.0.2

• Display devices and analyze the network traffic:

➜  ip tuntap
➜  sudo tshark -i <tun-name>

Supported Platforms

• Linux
• FreeBSD
• Android
• OSX
• iOS
• Windows

Examples

• read: Split tun to (reader, writer) pair and read packets from reader.
• read-mq: Read from multi-queue tun.

async-tun's Issues

Flushing write buffer sometimes takes a long time

Hello!

Im having issues with your library and I traced it down to flushing buffers and was wondering if you had advice.

I set up a virtual machine and have tunnels created between my machine and the VM. I can ping through the interface with varying levels of success. Tracking down the issue it seems flushing the buffer can sometimes take 10-60 seconds, followed by a few flushes taking milliseconds, then another taking a long time. I don't think bandwidth is a problem since I'm sending a small amount of data (100's of bytes) once a second.

I did an strace and sometimes see errors but nothing seems consistent with the long delay. Here are two examples where the flush had a long wait (not all have errors).

futex(0x55cd2389a2d8, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---
futex(0x55cd2389a2d8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x55cd23899ec0, FUTEX_WAKE_PRIVATE, 1) = 0
lseek(11, -48, SEEK_CUR)                = -1 ESPIPE (Illegal seek)
futex(0x7f6364000ce8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364003600, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364000ce8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364003600, FUTEX_WAKE_PRIVATE, 1) = 1
...
futex(0x55cd2389a2d8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x55cd23899ec0, FUTEX_WAKE_PRIVATE, 1) = 0
lseek(11, -48, SEEK_CUR)                = -1 ESPIPE (Illegal seek)
futex(0x7f6364000ce8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364003600, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364000ce8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f6364003600, FUTEX_WAKE_PRIVATE, 1) = 1

I have also seen this behavior between two physical machines.