macOS : specific/fixed utun device name

[cattyhouse]

right now, hev creates a random utun name based on a list of current utun devices, e.g. if there are utun0 utun1 utun2 utun3 before hev runs, then hev creates utun4, no matter what is set for name:, you can even set name: whatever.

all though we can find it via netstat -nr | awk '/^198.18.0.1/ {print $4}' , the ip is one thing we know for sure, because it is configured in yml.

the reason for a fixed utun name is that 1) pf route-to only accept interface name as parameter 2) we don't have to modify pf.conf each time it starts

[heiher]

If a name is already in use, it cannot be assigned. But we need to let users clearly know that the actual allocated name is different from what is set in the config file. So, isn't it better to report an error when the two are different?

[cattyhouse]

If a name is already in use, it cannot be assigned. But we need to let users clearly know that the actual allocated name is different from what is set in the config file. So, isn't it better to report an error when the two are different?

there is no need to let user to know that or emit errors. i mean if we can do name: utun99 and it actually creates utun99, that would be nice, so we can route-to utun99 in pf.conf :)

[heiher]

I confirmed that the current code does not support static specified name. Maintain the routing configuration in the post-up script so that the actual dynamically assigned name can be obtained in the script's argv[1].

[cattyhouse]

thanks, usage:

• up.sh

  #!/bin/sh
  # -D : Define macro to be set to value on the command line.  Overrides the definition of macro in the ruleset
  pfctl -D tun_if=$1 -E -f /etc/pf.conf

[cattyhouse]

can you take a look at it again? i tried this sudo ~/Downloads/tun2socks-darwin-arm64 -device utun123 -proxy socks5://127.0.0.1:1080 -interface en0 and it is able to create a utun123 :

ifconfig | grep utun123 :

utun123: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

off-topic: this tun2socks has the same slow upload issue if using pf route-to method

[heiher]

It seems that macos tun supports both specified names and random assignment. Perhaps random assignment is better? which can effectively avoid failures caused by conflicts.

[cattyhouse]

It seems that macos tun supports both specified names and random assignment. Perhaps random assignment is better? which can effectively avoid failures caused by conflicts.

i think most app creates utun randomly, if hev supports specific name, then we can use e.g. utun9999, nobody is gonna use that. if the specified utun is in use, just emit an error and exit?

[heiher]

Looks good to me. I think we can support both:

specified name

tunnel:
    name: utunN # (N is a number)

if the specified utun is in use, just emit an error and exit.

random assign name

tunnel:
    name: utun

[cattyhouse]

great!

[heiher]

Fixed by: https://github.com/heiher/hev-socks5-tunnel/commit/9790dea4547bb9d6ca68d86058b2ed9a2c7353c7

[cattyhouse]

thanks! it works great!