Hi Sampo, See comments inline...
Sampo Nurmentaus <audiopoppi...@audioriders.fi> said: > > Hi James, > > The original reason for the new option for me was the > ability to move the device file away from /dev. Why not use --dev-node? > This was of cource a really special need to > help me porting openvpn to an embedded platform. > > How about if --dev would check if the given > device name begins with / and if so it would > use given string as a complete path to the device file? > > And --dev /dev/tun would be equivalent with --dev tun ? --dev doesn't really deal with path names of device nodes, that's --dev-node's purview. Instead --dev sets the name for the device unit allocated, as it appears under ifconfig, or if the name is generic, such as "--dev tun", chooses a dynamic name such as tun4. In my latest patch which merges --dev-name functionality with --dev, these are our options for dealing with tun/tap naming: --dev : sets the device name as it appears under ifconfig --dev-node : sets the device file for tun/tap device --dev-type : sets the device type "tun|tap" if it cannot be inferred from --dev or --dev-node So, for example, under linux 2.4, "--dev-node /dev/net/tun" is equivalent to "--dev tun". James > > > Best regards, > Sampo > > > > > A debian bug report was submitted that inspired me to look deeper into the > > operation of --dev and the new --dev-name flag. > > > > --dev-name was a patch for tun.c which I received a few months ago, which > > only > > really does anything for linux 2.4. On first glance it appeared nominally > > useful, so I merged it, but on further inspection it appears to be mostly > > redundant with --dev. > > > > It appears that the motivation for implementing --dev-name was that --dev > > assumes its argument is either "tun", "tap", "null", or tun/tap with a unit > > number (e.g. "tun4"). But --dev is limited in that it doesn't allow > > arbitrary > > renaming. > > > > In OpenVPN 1.3.2, if the --dev argument was larger than 3 chars, it was > > assumed that a unit number was present. In 1.4.1 that test was changed so > > that an ascii digit needed to be present to assume a unit number. If a unit > > number was present, then the name of the device (as it appears in ifconfig) > > would be changed to reflect the explicit unit number. What I think probably > > inspired the debian bug report is that in 1.3.2 if you said "--dev foobar > > --dev-type tun", openvpn would have renamed the tun device to foobar, > > because > > foobar is > 3 characters. In 1.4.1, no rename would occur because "foobar" > > doesn't contain any numerical digits. In 1.4.1, you would need to say > > "--dev > > tun --dev-name foobar" to get the same effect. This seems somewhat > > arbitrary > > and confusing. > > > > My conclusion is that the implementation of --dev and --dev-name is mostly > > redundant because --dev can just as easily set the device name based on its > > argument, if that argument is something other than "tun", "tap", "null". > > The > > current operation of "--dev tun" or "--dev tap" would be preserved so that a > > dynamic unit number would be allocated if, for example, "--dev tun4" is > > given. > > But you could also specify "--dev foo --dev-type tun" and a tun device > > named > > foo would be created. > > > > I've patched the current development release to remove --dev-name, and to > > allow --dev to set a specific device name as in the above paragraph. > > > > Download: > > > > http://openvpn.sourceforge.net/beta/openvpn-1.4.1.4.tar.gz (or CVS) > > > > James > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: eBay > > Get office equipment for less on eBay! > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > > _______________________________________________ > > Openvpn-devel mailing list > > Openvpn-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > --
