add Sys() for access to fd/handle

[songgao]

Fixes #60

Also abstract *water.Interface into an interface{} and have windows/unix implement different types. Unfortunately this breaks existing code that assumes a pointer type *water.Interface, but that should be an easy fix.

@chengxuncc let me know if this works for you!

[chengxuncc]

How about this? Expose windows Fd
Code like this:

fd := ifce.ReadWriteCloser.(*water.File).Fd()

[songgao]

I'm saddened that you had a commit but only submitted an issue. If you had made a PR or pointed me to that commit earlier, I'd have either taken that in or worked with you to get that in.

Putting that aside, I believe your commit would work, but I'd like this package to have symmetric features for different platforms when possible though. What you have in that commit only exposes the Handle on Windows. Additionally it exports additional types that are unnecessary.

[chengxuncc]

That's my bad.
Actually, there is an another issue, DHCP via FD should be configured before bringing up interface. That means FD should be exposed before bringing up device.

[chengxuncc]

Maybe we don't have to expose FD, there are limited functions on TAP-Windows Adapter V9 driver, we can enhance package by manipulating PlatformSpecificParams.
There are two modes, DHCP mode and static mode, DHCP mode can configure ip, mask, gateway and two dns server addresses, but static mode can only apply ip and mask (network, already implemented).

[songgao]

Interesting. I don't have much experience with Windows. Could you further explain how DHCP mode would work? I assume one would need to listen for DHCP requests by reading from the device, and respond to them with proper packets following the protocol. Are you suggesting that this would be handled by "TAP-Windows Adapter V9 driver"? Also, I think I'm gonna need some help understanding why setup has to be before the device is brought up.

If it's necessary, perhaps we could make bringing up the device optional. Currently on Linux and macOS we don't actually bring up the link at all, and one would have to issue additional calls for those.

It feels a bit weird to include networking config (either DHCP or manual) in this package, as everything else is below the link layer. Everything above is handled through reading/writing the device. I guess still depends on how it's gonna look like. On Linux, one can already do that with normal network facilities like netlink.

[chengxuncc]

In my opinion, there is no real DHCP when work on TUN mode, driver just tell system to apply network in the DHCP way. As for DHCP must be setup before device is brought up, it similar to use control code tap_ioctl_config_tun to setup network, which is static mode. When device was brought up, it couldn't be changed.

On Unix platforms, our library just work at the right point, there is no shell command, developers should know what they doing. It's same for Windows, we just control driver, and expose driver's functions.

I think I can enhance it at soon, and make a PR.