Hi, Here's the summary of the previous IRC meeting.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 8th Aug 2013 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08> Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY cron2, derRichard, jamesyonan, mattock, novaflash, pekster, raidz, swg0101 and syzzer participated in this meeting. -- Discussed the "Windows 8 issue: TUN/TAP adapter does not start" issue: <https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08> Added all the new information/summary of the discussion to the bug report. --- Discussed the "ip-win32 netsh issue on Korean and Japanese Windows OS": <https://community.openvpn.net/openvpn/ticket/309> Added all the new information/summary of the discussion to the bug report. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
(21.00.42) mattock: ok, time to start (21.01.00) mattock: who's here? (21.01.07) mattock: topic here: https://community.openvpn.net/openvpn/wiki/Topics-2013-08-08 (21.01.09) vpnHelper: Title: Topics-2013-08-08 – OpenVPN Community (at community.openvpn.net) (21.01.59) jamesyonan [~jamesy...@c-24-9-78-222.hsd1.co.comcast.net] è entrato nella stanza. (21.01.59) modalità (+o jamesyonan) da ChanServ (21.01.59) ***derRichard is here (21.02.03) mattock: hi derRichard! (21.02.20) mattock: hi jamesyonan! (21.02.33) jamesyonan: hi mattock (21.02.33) novaflash [~novaflash@openvpn/corp/support/novaflash] è entrato nella stanza. (21.02.33) modalità (+v novaflash) da ChanServ (21.02.49) novaflash: *waves* (21.02.54) mattock: so today's main topic is Win8 tun/tap issues (21.03.08) mattock: and as Jamesyonan is the author of TUN/TAP driver, he's probably the best guy to help solve those (21.03.19) mattock: jamesyonan: did you have a look at the linked email thread? (21.03.37) raidz: side note> in regards to that ml post, I have seen two occurrences of this issues on different machines (21.03.44) mattock: jamesyonan: fyi: derRichard is the guy who reported this, and he's here now (21.03.44) ***syzzer waves too (21.03.55) mattock: raidz: that's not a side-note then (21.04.02) mattock: it's highly on-topic :) (21.04.32) raidz: lol (21.05.38) jamesyonan: this looks more like an issue with TAP address assignment than with the tap adapter itself (21.06.08) cron2_: uh, I'm here too, got distracted (21.06.10) derRichard: jamesyonan: playing with --ip-win32 did not help at all (21.06.35) raidz: hey cron2 (21.06.46) mattock: hi cron2 (21.06.53) derRichard: jamesyonan: i see this issue not always but 2-4 times out of 10 connections attempts (21.07.12) raidz: derRichard: I have noticed that same frequency (21.07.21) mattock: raidz: do you have further info on this issue? e.g. internal bug reports or something (21.07.26) raidz: consistently inconsistent (21.07.27) derRichard: after a reboot it works most of the time but aso not always (21.07.38) jamesyonan: did you try route-method netsh? (21.07.48) raidz: mattock: you have seen everything internal (21.08.06) derRichard: jamesyonan: yes. also without success (21.08.16) raidz: I have never seen this issue happen in a vm env only on physical hardware, not sure if that means anything or just by chance (21.11.47) mattock: raidz,derRichard: does this happen on all Win8 instances, or only some? (21.12.28) derRichard: mattock: so far only two of my customers are using win8. both face the issue (21.12.29) mattock: also, could this be related: https://community.openvpn.net/openvpn/ticket/207 (21.12.30) vpnHelper: Title: #207 (Windows 7 x64: KB2688338 affect the TAP interface) – OpenVPN Community (at community.openvpn.net) (21.12.43) derRichard: btw: on win7 i've never seen that (21.12.55) derRichard: most of my custeroms use win7 or xp (21.12.59) derRichard: *customers (21.13.04) mattock: derRichard: are customers using physical computers with win8 or virtual machines? (21.13.10) derRichard: physical (21.13.13) mattock: ok (21.13.14) raidz: mattock: for me, only some (21.13.29) mattock: raidz: only some physical you mean? (21.13.34) raidz: like right now, I am on Windows Server 2012 and don't have this issue (21.13.37) mattock: and no virtual (if that is not a coincidence) (21.13.45) raidz: and my personal laptop, don't have issue (Windows 8) (21.13.50) derRichard: mattock: i hade one of these computers in my office. fresh installed, no crapware, all updates installed. but still faced the issue (21.13.55) raidz: Virtual, I have never had a problem (21.14.09) raidz: however, my peronal laptop and win 2012 server, I am running pre 2.3 (21.14.13) raidz: lemme check version (21.14.26) mattock: jamesyonan: any clues what might be happening? (21.14.49) raidz: 2.2.2 (21.15.03) pekster: The odd thing I noted from earlier discussion too was that with --ip-win32 dynamic, derRichard was reporting no DHCP discover being sent by the OS (21.15.18) mattock: pekster: repeatedly? (21.15.19) pekster: netsh issues asside, it's strange that the OS isn't even "trying" to get an IP (21.15.26) jamesyonan: no ideas at this point (21.15.35) pekster: I'm not sure, ask derRichard who tested it. Works fine for me on Vista x64 with 2.3.2 (all I have on metal atm) (21.15.59) mattock: jamesyonan: any ideas how to debug this further? (21.16.19) mattock: can we build a debugging version of the TAP-driver or something? (21.16.37) raidz: I am not trying to say this is only related to physical, maybe it is an issue with virtual too, but I have just never seen it happen on virtual (21.17.58) jamesyonan: yes, you could certainly try debug build of TAP-driver -- if the problem is related to the DHCP handshake it might show up here (21.18.18) mattock: ok, we'll start with that, then (21.18.43) mattock: raidz: what is the status of the Windows TAP-driver build computer (a.k.a. jupiter)? (21.18.44) derRichard: okay. i'll try to reproduce it within virtualbox (21.18.52) raidz: mattock: lets ask novaflash (21.18.57) mattock: derRichard: sounds good (21.18.59) novaflash: hello (21.19.01) mattock: good to get this narrowed down (21.19.02) jglick ha abbandonato la stanza (quit: Quit: http://quassel-irc.org - Chat comfortably. Anywhere.). (21.19.02) novaflash: what do you need? (21.19.12) raidz: novaflash: status on jupiter migration to testing (21.19.20) novaflash: *checks* (21.19.27) jamesyonan: the problem is that if route-method netsh is also not working, it seems to point away from DHCP as being the culprit (21.19.29) novaflash: it's still copying to the new server (21.19.34) novaflash: in a few hours, it should be working (21.19.45) jamesyonan: have you looked at route-delay or tap-sleep? (21.20.06) mattock: novaflash: let me know when jupiter is migrated and I'll see if I can access it (21.20.24) novaflash: mattock: okay. i mayn eed to coordinate with david for ip addressing space and access to it and such (21.20.39) mattock: novaflash: I'll make a note of that (21.20.47) raidz: novaflash: david can get that taken care of pretty quick (21.21.15) jamesyonan: does route-method netsh fail always or intermittently? (21.21.57) pekster: If netsh fails, shouldn't the logs give a status code too? Maybe it's un-helpful like "status 1" or something (21.22.12) derRichard: jamesyonan: hmm. IIRC netsh method failed always (21.22.24) derRichard: but i'm not sure anymore. (21.22.42) pekster: You should see a log entry (f.eg with --ip-win32) like: NETSH: C:\Windows\system32\netsh.exe interface ip set address vpn0 static 172.19.43.230 255.255.255.224 (21.23.33) pekster: The curious thing would be to try the "manual" method and use those same commands from an elevated prompt to try and pin down if it's a syntax issue, or something specific to openvpn (21.23.50) pekster: Or just intermittently fails with a prompt too? (21.25.06) pekster: I think there's also an open bug for device names with international characters in them (21.25.32) mattock: made this a "proper" bug report so it doesn't get lost so easily (21.25.35) vpnHelper: RSS Update - tickets: #316: Windows 8 issue: TUN/TAP adapter does not start <https://community.openvpn.net/openvpn/ticket/316> (21.25.42) mattock: (thank you, vpnHelper) (21.25.44) pekster: Spaces work fine, like the default Local Area Connection 5 or w/e, but an accented letter does not. I tried patching the code to use a \" sequence around the device, but the windows-version of printf seems to strip out my quote :\ (21.26.23) pekster: (speaking of ways that netsh breaks, anyway. Slightly different bug/topic, so I won't detract form the win8 stuff if there was more to be said) (21.26.24) derRichard: my TUN/TAP adapter is named "Lan Verbindung 2" (German for Local Area Connection 2) (21.26.47) pekster: No accented characters though? (IIRC that's consistently failing now) (21.26.56) derRichard: no. plain ascii (21.27.42) derRichard: i tried also renaming it to "TAP". did not solve the issue (21.28.33) novaflash: derRichard: what OS is this on, windows 7 HP ? (21.29.03) derRichard: novaflash: no, Windows 8 32bits (21.29.20) novaflash: okay i have a test machine for that as well (21.29.41) novaflash: so i can reproduce it simply by installing openvpn 2.3 and renaming the tap adapter? (21.29.55) ***novaflash shudders at metro interface (21.30.11) pekster: The foreign-language bug, yes. That's not derRichard's issue though. https://community.openvpn.net/openvpn/ticket/309 (21.30.13) vpnHelper: Title: #309 (ip-win32 netsh issue on Korean and Japanese Windows OS) – OpenVPN Community (at community.openvpn.net) (21.30.21) cron2_: eek (21.30.40) pekster: I should add a comment to #309 as I did confirm that one locally (Vista x64) (21.31.03) derRichard: pekster: yes. sorry novaflash for the confusion. (21.31.06) pekster: I tried to poke at a fix briefly, but the win32 (mingw I guess?) version of printf is doing things differently than the *nix version does with my quotes (21.31.16) novaflash: derRichard: i don't mind, i just want to reproduce it now (21.33.07) novaflash: heh i guess nobody ever fixed that bug where if you try to start openvpn gui without admin rights first time it screams "unable to create registry keys" (21.33.10) cron2_: pekster: could be completely unrelated to printf, but something about 8bit and utf-16 APIs and string handling (21.33.28) derRichard: novaflash: i saw that one :D (21.33.29) pekster: Well, even the quote itself gets lost (21.33.33) pekster: Just \" in the string, fwiw (21.33.33) cron2_: novaflash: I *think* mattock covered that one (21.34.38) mattock: novaflash: yeah, that's been fixed, but not release yet (21.34.43) novaflash: cron2_: i just downlo... oh. (21.34.45) novaflash: okay (21.34.48) novaflash: :-D (21.34.50) mattock: I created a OpenVPN-GUI installer that handles that (21.34.54) derRichard: BTW: we (my company) are working on a new windows ui for openvpn. in a few months we will release it under gpl. (21.34.55) novaflash: neat (21.35.00) mattock: it's in openvpn-gui git repo now, but no openvpn version yet uses it (21.35.24) cron2_: mattock: ah! seems we really need to release a new windows version soon :-) (21.35.32) novaflash: derRichard: will it be pretty? screenshots? (21.35.35) mattock: derRichard: ah, let me know when that happens (21.35.45) mattock: cron2: yep, except that it needs some serious testing in the field (21.36.03) mattock: or otherwise the "stable" release of openvpn 2.3.3 (or something) might be horribly broken for 90% of the userbase (21.36.10) derRichard: novaflash: it is in a very early stage. but it will be pretty. (21.36.13) novaflash: mattock: you know how programs in windows can have shortcuts that you can assign the "run as administrator" flag? perhaps that would make sense on openvpn gui shortcuts. or perhaps that is what you did? (21.36.43) pekster: Applications can also set the "needs admin rights" thing in their manifest (21.37.01) pekster: Then if admins (but not "elevated") executaiton takes place, it'll prompt (21.37.02) novaflash: that might be better (21.37.15) novaflash: i still get tickets weekly about the hklm error (21.37.32) cron2_: there's also the openvpn interactive service that d12fk has developed, that enables GUI *and* openvpn.exe to run without privileges... (21.37.48) derRichard: mattock: yeah. we'll release a beta version as soon as possible. in fact, many of our customers have problems with the look&feel of the current ui. (21.37.50) cron2_: ... unfortunately, it's not finished yet... (21.38.07) mattock: novaflash: not sure, but executable's manifest file can have RequestExecutionLevel administrator or whatever (21.38.43) novaflash: mattock: that might be wise since openvpn gui cannot function at all without admin rights (21.38.53) novaflash: and the installer that we still have online right now just does not ask for admin rights (21.39.01) mattock: I think it can, but you need some "network operator" rights (21.39.01) novaflash: even the simplest thing like adding a route requires admin rights (21.39.03) mattock: to create the routes (21.39.13) novaflash: okay well it's not doing that either (21.39.15) novaflash: lol (21.39.16) mattock: not sure about superuser/admin rights (21.39.19) mattock: yeah, it's not atm (21.39.43) mattock: derRichard: did you notice jamesyonan's suggestion above: --tap-sleep and --route-delay? (21.40.07) ***derRichard looks (21.40.11) pekster: And someone used it to control the services instead with some registry tweaks. IIRC there's also a way to tell the application manifest to ask for the "highest available rights" when run, so if the user is an admin it'll prompt, otherwise not (if a site is using the Network Operators group, for instance) (21.40.33) pekster: I'm not well-versed in MSVC-fu, though (21.41.21) derRichard: jamesyonan: i tried --route-delay, it did not help. even afer minutes the tap was still down. but i did not try --tap-sleep (21.41.36) mattock: derRichard: can you try --tap-sleep also? (21.41.55) derRichard: no, but i'll next time (21.42.01) derRichard: i really hope it helps :D (21.42.22) mattock: ok (21.42.37) mattock: ok, so a summary of this topic: (21.42.47) mattock: here: https://community.openvpn.net/openvpn/ticket/316#comment:1 (21.42.48) vpnHelper: Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) (21.43.10) mattock: whatever the cause, I will build a debug version of the TAP-Windows driver for future use (21.43.21) mattock: if that will give us more info on this then it's good (21.43.24) raidz: mattock: I still have one of the problem machines (old laptop sitting on my office floor) anything you guys need tested can be done (21.43.36) mattock: raidz: ok (21.43.40) raidz: I can even bring it here and get it on our office network and you guys can remote in (21.43.51) mattock: raidz: that'd be really nice! (21.43.54) raidz: this issue is reproducable on that laptop (21.44.05) raidz: I will bring it in tomorrow (21.44.08) mattock: ok, let me know when the lappy is online (21.44.14) raidz: and give you ip (21.44.20) raidz: sounds good (21.44.47) mattock: jamesyonan: could you take a stab at the problem laptop at some point? (21.45.00) jamesyonan: there's a related issue here -- Microsoft is phasing out NDIS 5 (which the current TAP adapter uses) in the version of Windows after 8.1. (21.45.16) jamesyonan: So we need to update the driver to NDIS 6. (21.45.16) mattock: derRichard, raidz: can you add whatever further info you have here: https://community.openvpn.net/openvpn/ticket/316 (21.45.17) vpnHelper: Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) (21.45.22) mattock: jamesyonan: yeah, that one also (21.45.31) derRichard: novaflash: ok (21.45.45) novaflash: derRichard: ? (21.45.46) mattock: jamesyonan: do you have any plans/timeline for upgrading the tap-windows driver to NDIS 6? (21.45.55) derRichard: novaflash: whoops (21.46.07) derRichard: wrong nick (21.46.22) novaflash: i like my nick :( (21.47.02) jamesyonan: not sure I would be the right person -- I haven't used windows in years (21.47.05) raidz: mattock: if this is really important I can go home on lunch and grab that latop (21.47.09) raidz: *laptop (21.47.23) pekster: cron2_: I tried this, and it did something totally weird like keep the quotes but *not* include the %s for the device name: http://fpaste.org/30912/87632137/raw/ (21.47.23) mattock: raidz: I have to go to sleep soon, so it's not _that_ important for me (21.47.42) raidz: haha, ok, who will need access to this? (21.47.48) derRichard: jamesyonan: i thought you are the developer of the windows tuntap driver? (21.47.48) swg0101 [~swg0101@openvpn/user/swg0101] è entrato nella stanza. (21.47.51) novaflash: raidz: just everyone that wants your files. (21.48.00) raidz: i was just going to put it on private network, but can give it a public ip if necessary for other community members (21.48.03) pekster: cron2_: I'll just save the detailf for later now that I was reminded about the bug so I can come up with useful info: the tl;dr is that single and double quotes both failed amazingly, and the %s seemed to 'get lost" (21.48.07) raidz: my files will be gone (21.48.08) raidz: lol (21.48.17) cron2_: pekster: uh, argv_printf() is not printf(), it's special anyway (and does not need quoting) (21.48.20) novaflash: raidz: maybe teamviewer or something? (21.48.27) raidz: won't work (21.48.32) raidz: teamviewer will probably cut out (21.48.33) pekster: cron2_: Rigth, but the *OS* is the one that needs it (21.48.36) cron2_: it builds an argv[] vector, which is basically doing the "quoting" (21.48.53) novaflash: raidz: oh due to commercial/noncommercial use of tv? (21.49.00) raidz: nope, route stuff (21.49.04) swg0101: haha (21.49.04) pekster: cron2_: netsh [blah] Local Area Connection 5 works, but `netsh [blah] überdev [more blah]` does not (21.49.11) novaflash: right (21.49.14) raidz: unless its split tunnel (21.49.15) raidz: it will die (21.49.20) pekster: You need to pass the OS "überdev" and then it works (21.49.23) cron2_: pekster: OSes usually need the quotes to avoid shells (etc) breaking arguments with whitespace - in that case, I expect the issue to be with the CLI and UTF16 or so (21.49.28) pekster: Ah, k (21.49.37) cron2_: mmmh (21.49.49) cron2_: I think you'll need to mangle "actual" to contain the quotes (21.50.15) jamesyonan: well the fundamental problem with developing/fixing the TAP driver is that Windows is a black box (21.50.16) cron2_: %s basically instructs argv_printf() to take "this string" and use it for a new argv[] entry (21.50.28) pekster: cron2_: Well, maybe. The win32 stuff is running this all through cmd.exe anyway, right? (21.50.46) swg0101: jamesyonan: would it be easier to use netsh than DHCP then? (21.50.46) cron2_: pekster: no, exec() (-ish windows api) (21.51.09) raidz: swg0101: Thats what I was thinking (21.51.18) raidz: isn't that what ms prefers use of? (21.51.19) cron2_: pekster: try sprintf( actual_with_quotes, "\"%s\"", actual ) and passing actual_with_quotes to argv_printf(), to see what happens (21.51.34) swg0101: I always always found netsh be more reliable in terms of setting IP settings and such (21.51.39) raidz: yep (21.51.41) swg0101: and makes the connection process way more faster (21.51.52) swg0101: although I don't think in the current implementation the DNS servers are set (21.52.04) raidz: I am pretty sure ms suggests using that in newer versions (21.52.22) jamesyonan: the problem is that Windows has no VPN API, unlike every other major OS (21.52.41) pekster: swg0101: There's a DNS method to the netsh interface, yes (21.53.08) swg0101: sometimes setting the DNS servers in XP using netsh is a lil slow, but I think overall the speed should be faster than using DHCP (21.53.27) pekster: eg: http://fpaste.org/30915/13759879/ (21.53.49) swg0101: is that already in OpenVPN? (21.54.03) pekster: Yes, this is 2.3.2 (IIRC netsh support has been there longer than that -- you'd need git blame to see when) (21.54.20) swg0101: yeah, I used netsh a lil back in 2.2 (21.54.22) cron2_: netsh has been there since before I started, that is "2.0" (21.54.29) swg0101: but don't rem it setting the DNS servers correctly (21.54.32) swg0101: havent really tested it since (21.54.57) swg0101: it sets the IP okay though (21.55.00) swg0101: but the DNS didn't work (21.55.04) swg0101: I have to manually go and set those (21.56.12) jamesyonan: has anyone succeeded in using netsh to make TAP driver succeed on Windows 8? (21.56.55) swg0101: good question - I havent tested this myself (21.57.00) swg0101: got scared of Windows 8 and reverted back to 7 (21.57.17) swg0101: but as soon we get some VMs up, we could give that a whack (21.57.50) mattock: swg0101: I feel you might be a good person to try figuring this out on raidz's unhappy lappy with this bug (21.57.53) mattock: :) (21.57.59) pekster: If my Win8 Preview VM still lets me log in I can test netsh quick (but MS might have killed it after a time) (21.58.01) raidz: :-D (21.58.21) swg0101: planning to also do Win8.1 preview on testing as well (21.59.49) derRichard: guys, it's 9pm here in .at, i have to go now. thanks a lot and cu! :-) (21.59.53) swg0101: but I will report back once I got some results :D (22.00.16) swg0101: still getting all the Windows instances sorted (22.01.00) mattock: derRichard: bye! keep the bug report updated on any new findings, please! :) (22.01.09) derRichard: will do (22.01.10) mattock: swg0101: great, thanks a lot! (22.01.23) mattock: swg0101: if you can, please update the bug report (22.01.38) mattock: you need a community user account if you don't have one, but that's really easy, no email loops even (22.01.55) raidz: swg0101: are you going to test this on a vm? (22.02.08) swg0101: yep, any suggestions? (22.02.12) raidz: swg0101: are you just testing netsh commands? (22.02.29) raidz: swg0101: I will pick up my problem machine at lunch (22.02.30) swg0101: I am prob gonna test the different openvpn versions with 8 (22.02.37) swg0101: and see what I see (22.02.42) raidz: based on my previous tests, you may not run into this issue in a vm (22.02.47) raidz: but still try to repro it (22.02.52) mattock: swg0101: it's not 100% broken at least, but probably there are major issues (22.03.04) swg0101: but yeah, I haven't seen issues when I was running Win8 on my laptop (22.03.16) swg0101: but I do see people complaining on PT about this from time to time (22.03.27) mattock: "Swg0101 will try to reproduce this on various Windows 8 and 8.1 VMs and raidz's laptop." (22.03.36) mattock: that's now in the bug report/summary (22.03.46) swg0101: can you link me mattock (22.03.53) mattock: yeah, just a sec (22.04.16) mattock: https://community.openvpn.net/openvpn/ticket/316 (22.04.18) vpnHelper: Title: #316 (Windows 8 issue: TUN/TAP adapter does not start) – OpenVPN Community (at community.openvpn.net) (22.04.30) mattock: you can create a user account from the "Register" link if you don't have one (22.05.31) mattock: should we call this a day? It's getting a bit late here (10 PM) (22.06.28) novaflash: i think i would like to call it a day when we have reached 24 hours (22.09.29) mattock: oh, 110 minutes left... damn (22.11.35) cron2_: mattock: I'm somewhat lazy today, and since dazo is not there, I'd postpone the other stuff... (22.11.46) mattock: cron2: sounds like a plan (22.11.52) mattock: we got some progress on a few nasty bugs (22.11.55) ***cron2_ has plans to spend some serious time on openvpn patches and git and stuff, but "not today" (22.11.56) mattock: both related to Windows (22.12.07) mattock: "tomorrow" is always good :) (22.14.16) pekster: jamesyonan: Yes, I got my Win8 "Release Preview" eval copy build 8400 to work with --ip-win32 netsh (22.14.27) pekster: It gets an address fine (in tun mode, not other windows options besides --ip-win32) (22.14.38) cron2_: that's good (22.14.58) swg0101: pekster: did you get the DNS settings? (22.15.04) pekster: I didn't push any (22.15.22) pekster: It succesfully deleted them though (22.15.23) pekster: http://fpaste.org/30922/75989296/ (22.15.27) pekster: (sorry line wraps, cmd.exe sucks) (22.15.55) swg0101: 5 seconds heh (22.16.01) pekster: That's a VM though (22.16.47) pekster: --tap-sleep IIRC defaults to 5 on win32 due to OS limitations (22.19.05) jamesyonan: I don't think --ip-win32 netsh currently handles DNS or other settings
