I agree it would be nice to make VyOS compatible with more platforms and able to serve as a drop-in replacement for them.

I gave your code a brief review. Some areas for improvement I see:

1. The installation path is hardcoded. That will make packaging harder. There is also no dependency checking or anything — CMake, autotools, or whatever else could provide that.

2. Option parsing is hand-coded, argument order is rigid.
   
   2.1 Error handling is rudimentary. E.g., --mtu just passes the argument to atoi, which means it will cheerfully set it to zero if the user types --mtu fdsf or accept a negative MTU.
   
   2.2. Argument format is idiosyncratic: reminiscent of iproute2 for no clear benefit, since there are no subcommands and arguments are not composable. E.g., the destination address syntax is dst 192.0.2.1 but MTU syntax is --mtu.
   
   Using GNU getopt — the de facto standard — would make that code much simpler and more robust at no cost, and options should better follow the usual UNIX format (--destination/-dand the like).

3. There is no support for reading the configuration from a file, tunnel parameters can only be passed via command line options. This can be worked around with systemd environment files, but it would be a lot easier if we could just point it to a file — for both actual operation and testing (VyOS config scripts run in stages: "verify", "generate", "apply" — "generate" produces config files, "apply" restarts daemons. If there's a config file, automated tests can check if configs are generated correctly without actually running the process.).

4. I'm not an expert in the behavior of the TUN/TAP driver so I may be wrong here, but I'd like to see this bit clarified. Now, the process uses two threads: one for receiving tunneled packets, the other one for sending them. The receiver thread uses read(), which is blocking by default. Would it be better to use polling on the socket's file descriptor instead of busy-waiting for data on it, or there are some reasons why that is not a concern?

Thank you for your understanding regarding this feature request!

And thank you very much for your review.

1. I'll fix it.
2. I'll try to use getopt.
3. I'll add support for reading the configuration from a file.
4. As you said, read() is blocking by default. So I'll try to use epoll. Actually I'm not an expart in socket programming, so I don't know poll() before telling me. I'll learn more :)

After all improvements are fixed, I'll post here.