netconfig: Fixed tun_open can only use tun0/tap0 if --dev is in dynamic device mode on Solaris

[Low-power]

So if a tun0 is already there, the program will fails.

[cron2]

Hi,

On Thu, Jul 14, 2016 at 10:46:58AM -0700, Low-power wrote:

So if a tun0 is already there, the program will fails. You can view, comment on, or merge this pull request online at:

https://github.com/OpenVPN/openvpn/pull/58

-- Commit Summary --

• Function open_tun changed: fixed always create tun0/tap0 on Solaris

-- File Changes --

M src/openvpn/tun.c (15)

-- Patch Links --

https://github.com/OpenVPN/openvpn/pull/58.patch https://github.com/OpenVPN/openvpn/pull/58.diff

Sorry, I cannot see why your patch would change anything for the case that you call "openvpn --dev tun0". In both cases, you end up with "ptr" pointing to the "0" in "tun0", and ppa being "0".

Your patch only makes a difference if someone uses a --dev name that is not starting with tun or tap, and for them, you are breaking functionality ("--dev foo3 --dev-type tun" is no longer working after your change).

So please explain in more detail what you are trying to achieve, and show logs that demonstrate what is not working before and how it is working with the patch.

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

[Low-power]

I see the dynamic search for tun/tap device number is done by commit https://github.com/OpenVPN/openvpn/commit/21ae2ec2b963e33e1b48b6cf9069e774b3f656b1, but there are 2 small problems. The tun/tap driver itself is able to find out the first free number as well by setting ic_dp to -1; and more important is the code "if ( *ptr == '\0' )" may dereferencing an uninitialized pointer that may result the program crash; according to the code, the only possible way to toggle this is using --dev "" but a segmentation fault shouldn't be caused by this.

[cron2]

Hi,

On Fri, Jul 15, 2016 at 05:51:25AM -0700, Low-power wrote:

I see the dynamic search for tun/tap device number is done by commit https://github.com/OpenVPN/openvpn/commit/21ae2ec2b963e33e1b48b6cf9069e774b3f656b1, but there are 2 small problems. The tun/tap driver itself is able to find out the first free number as well by setting ic_dp to -1; and more important is the code "if ( *ptr == '\0' )" may dereferencing an uninitialized pointer that may result the program crash; according to the code, the only possible way to toggle this is using --dev "" but a segmentation fault shouldn't be caused by this.

So just move the initialization "ptr = dev;" before the if(*dev) part, and all is well.

gert

USENET is not the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany [email protected] fax: +49-89-35655025 [email protected]

[Low-power]

The Segmentation fault

./openvpn --config /etc/openvpn/bridge-client.cfg --dev-type tap --dev ""

Fri Jul 15 20:23:13 2016 OpenVPN 2.3_git i386-pc-solaris2.10 [SSL (OpenSSL)] [LZO] [IPv6] built on Jul 15 2016 Fri Jul 15 20:23:13 2016 library versions: OpenSSL 0.9.8o 01 Jun 2010, LZO 2.03 Fri Jul 15 20:23:13 2016 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Fri Jul 15 20:23:13 2016 TCP/UDP: Preserving recently used remote address: [AF_INET]115.28.87.127:1194 Fri Jul 15 20:23:13 2016 Socket Buffers: R=[57344->57344] S=[57344->57344] Fri Jul 15 20:23:13 2016 UDP link local: (not bound) Fri Jul 15 20:23:13 2016 UDP link remote: [AF_INET]115.28.87.127:1194 Fri Jul 15 20:23:13 2016 TLS: Initial packet from [AF_INET]115.28.87.127:1194, sid=1dc58f2a 98ee88dc Fri Jul 15 20:23:13 2016 VERIFY OK: ****** Fri Jul 15 20:23:13 2016 VERIFY OK: ****** Fri Jul 15 20:23:13 2016 VERIFY OK: ****** Fri Jul 15 20:23:13 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Fri Jul 15 20:23:13 2016 [server] Peer Connection Initiated with [AF_INET]115.28.87.127:1194 Fri Jul 15 20:23:15 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Fri Jul 15 20:23:15 2016 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.2.101.1,ping 10,ping-restart 120,ifconfig 10.2.101.22 255.255.255.0' Fri Jul 15 20:23:15 2016 OPTIONS IMPORT: timers and/or timeouts modified Fri Jul 15 20:23:15 2016 OPTIONS IMPORT: --ifconfig/up options modified Fri Jul 15 20:23:15 2016 OPTIONS IMPORT: route-related options modified Fri Jul 15 20:23:15 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jul 15 20:23:15 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Fri Jul 15 20:23:15 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Fri Jul 15 20:23:15 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 段错误(吐核)

[ordex]

Mail addressing the segfault is on the ml.

Closing this PR.