ip-win32 netsh issue on Korean and Japanese Windows OS

[vbokashov]

Well, I got some issue running OpenVPN client on localized Korean and Japanese Windows with “ip-win32 netsh” option.

This is (on Korean) or similar what I have in the logs:

---

Tue Jul 16 01:38:19 2013 NETSH: C:\Windows\system32\netsh.exe interface ip set address 로컬영역연결2 static 10.8.0.6 255.255.255.252
Tue Jul 16 01:38:19 2013 ERROR: netsh command failed: returned error code 1
Tue Jul 16 01:38:24 2013 NETSH: C:\Windows\system32\netsh.exe interface ip set address 로컬영역연결2 static 10.8.0.6 255.255.255.252
Tue Jul 16 01:38:24 2013 ERROR: netsh command failed: returned error code 1
Tue Jul 16 01:38:29 2013 NETSH: C:\Windows\system32\netsh.exe interface ip set address 로컬영역연결2 static 10.8.0.6 255.255.255.252
Tue Jul 16 01:38:29 2013 ERROR: netsh command failed: returned error code 1
Tue Jul 16 01:38:34 2013 NETSH: C:\Windows\system32\netsh.exe interface ip set address 로컬영역연결2 static 10.8.0.6 255.255.255.252
Tue Jul 16 01:38:34 2013 ERROR: netsh command failed: returned error code 1
Tue Jul 16 01:38:38 2013 NETSH: command failed
Tue Jul 16 01:38:38 2013 Exiting due to fatal error

---

The problem is that in cases like that netsh requires quotes for NIC name, so "netsh.exe interface ip set address “로컬영역연결2” static 10.8.0.6 255.255.255.252" perfectly works.

So, the fix may be as easy as add quotes to TAP adapter name, or make netsh call configurable .. As I understand quotes will not break anything.

[vbokashov]

client config

[vbokashov]

server config

[Samuli Seppänen]

This topic was briefly discussed In a community meeting on 8th Aug 2013:

pekster: netsh [blah] Local Area Connection 5 works, but `netsh [blah] überdev
         [more blah]` does not
pekster: You need to pass the OS "überdev" and then it works

[JoshC]

A duplicate bug, #318, was closed out recently with some additional info on this issue.

Additionally, the submitter of that bugreport referenced the following github pull request, which I have included here for completeness: ​​https://github.com/OpenVPN/openvpn/pull/8

[Gert Döring]

This is not about quoting, as it turns out, but about the way non-ASCII characters are represented. A patch has been committed to master and release/2.3 (8f5a4598662f4b2abe7acfe8f68c90a8b03f2dc8) and will be part of 2.3.3.

So I think this bug can be closed. Right?

(We won't fix it for 2.2.x, as it is very likely that we'll not do an updated version in the 2.2.x train)

[ValdikSS]

Please test this patch when server pushes IPv6 routes. I have this issue on Russian Windows OS, but only when IPv6 is enabled on server side and the server pushes IPv6 address and routes to client. If it works, then everything is fine.

If you provide windows build with this patch, I can help to test it.

[Gert Döring]

I think this should be fixed in the newly released 2.3.3 build on

​http://openvpn.net/index.php/open-source/downloads.html

could you please test and report whether we can close this?

[Gert Döring]

Asking again: is this fixed? If I do not receive a reply in two weeks' time, I assume "reporter not interested anymore" and go ahead and close it.

We have added a number of UTF8 related fixes to the windows builds in version 2.3.3, so it should be fixed...

[ValdikSS]

I'll check it today on russian windows 8.1.

[Gert Döring]

cool, thanks

[ValdikSS]

Everything works as expected on Russian windows 7. Sorry for the late reply.

[Gert Döring]

Cool. Thanks for testing and reporting back.

Closing the ticket, one less to go :-)