Feature/macos - Support for macOS

[realityone]

Hi there,

Thanks for the project.

This is the macOS implantation using native macOS kernel API. But some behavior is different from Linux, some unimplemented!() are leaved.

And I add some very basic tests, consider we can setup a CI that rust-tun can grow more happily XD.

PTAL.

[meh]

Could you remove the reformatting commit please? I already have to use rustfmt at work and it's more of a hindrance than helpful.

[realityone]

Sorry for this. I will remove this commit soon.

Can you share the rustfmt config file so we can format our code in same style.

[meh]

I don't use rustfmt on my personal projects because it's a huge pain in the ass, I will consider it once it doesn't fuck up your source code whenever it feels like it.

Just try and follow the style of the rest, I'll fix anything that doesn't fit the style myself.

[realityone]

The reformat commit is removed.

PTAL.

[meh]

Thanks! I'll look at the code more carefully after work.

[JuniorJPDJ]

Are you going to merge it?

[meh]

Ahh, this is the project that had the pull request I needed to look at, I remembered I had one but couldn't find which one it was, looking at it now.

[meh]

@realityone did you try and see if this actually works?

I've been trying to get it to work but UTUN interfaces seem to act very differently from TUN/TAP interfaces, so it may make more sense to wrap the TUN/TAP driver for macOS instead?

[realityone]

Yes.

There are some differences between linux TUN/TAP interface and macOS UTUN interface. But it should be worked in most case.

I have tested on my machine and seems in right behavior.

1. Setup a tun device and split the reader and writer, when any byte is read from reader, panic and exist.

    let addr = Ipv4Addr::from_str("192.168.50.1").unwrap();
...
    let (mut r, _) = dev.split();
    loop {
        let mut buf = vec![0u8; 64];
        r.read(&mut buf);
        panic!("{:?}", buf);
    }

2. Add route in routing table.

$ sudo route -n add -net 192.168.50.0/24 192.168.50.1
$ route -n get 192.168.50.1
   route to: 192.168.50.1
destination: 192.168.50.0
       mask: 255.255.255.0
    gateway: 192.168.50.1
  interface: utun6
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1480         0 

3. Send ping to device. The reader process should be panic directly.

failures:

---- platform::macos::tests::test_tun_create stdout ----
        thread 'platform::macos::tests::test_tun_create' panicked at '[0, 0, 0, 2, 69, 0, 0, 84, 240, 139, 0, 0, 64, 1, 164, 202, 192, 168, 50, 1, 192, 168, 50, 1, 8, 0, 127, 91, 44, 125, 0, 0, 90, 18, 232, 100, 0, 5, 30, 168, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]', src/platform/macos/tests.rs:54:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[meh]

@realityone do you know if there's a similar ioctl to set whether to give packet information or not?

The first 4 bytes there seem to be similar to what Linux does when not passing IFF_NO_PI but the constants used seem to differ.

[realityone]

Actually I have searched before, there is no easy way to set whether to give the header or not by ioctl in Darwin.

Many software strip it and add it back manually.

• openvpn/tun.c#L1683
• ocserv/src/tun.c#L778

[meh]

I see, do you know what the format of those 4 bytes is? And what constants are used to identify the protocol?

I think the story right now with handling that kind of thing is kind of shitty for this crate, but I can't come up with a better way to do it without hindering performance, I'm just going to merge this with my changes and think about a better way to handle this packet information bullshit.

Thanks for your patience!

[meh]

This has been merged with a couple modifications.