search

openconnect / openconnect-gui

MOVED TO https://gitlab.com/openconnect/openconnect-gui
https://gitlab.com/openconnect/openconnect-gui
GNU General Public License v2.0
1.3k stars 241 forks source link

OpenConnect GUI hard crash in windows right after handshaking for juniper VPN connection #157

Open irakhlin opened 7 years ago

irakhlin commented 7 years ago

Description of the Issue

Using the GUI client, when attempting to establish a Juniper type VPN connection handshaking will complete correctly, and an IP will be obtained. However about 15 seconds into the tunnel being established the entire client will hard crash. Windows will prompt that the OpenConnect GUI program stopped responding and will close it, this happens about the exact same time into every connection without any useful information in the logs.

Specifications

Version: I have used the provided version 1.5 installer found here: http://openconnect.github.io/openconnect-gui/ Additionally, I have build a 64bit version of the client and installer using the following libraries: Openconnect: v7.08 GnuTLS: v3.5.8 Qt5: v5.8.0 (64bit) OpenConnectGUI: v1.5.0-2-ga12c7fc-dirty

I am testing this on Windows 10 (64bit) build 15014

Prerequisites

  1. I can reproduce the issue 100% of the time
  2. I am running the most up to date version of the provided 32bit client in addition to having build the most up to date version of a 64bit client.

Steps to Reproduce the Issue

  1. Create a connection profile for a Juniper VPN connection, and fill in the server URL.
  2. Click connect, when prompted respond to user name and password prompt
  3. Wait about 10 seconds, the connection will become "connected" with the icon becoming green
  4. Approx 10 seconds later the entire client will hard crash.

Expected Behavior

  1. Client should continue with established connection

Actual Behavior

  1. Client hard crashes.

Other Information

I have attempted to establish a juniper style vpn connection using both the 32bit (provided installer) and my own 64bit command line client (openconnect.exe) by passing openconnect.exe --juniper {server}, the client does not crash and the connection seems to establish correctly. There may be other issues around the setting of the control panel status but I believe this is more along the lines of the windows 10 issue, in either case however does the client crash or break the connection.

I understand this provides very little interms of debug information but I do not see anything relevent in the log file, If someone wants to perform a screen sharing session with me to see the issue reproduced or let me know what additional debugging may be enabled for useful information please let me know I am willing to help as much as possible in resolving this issue.

crash

horar commented 7 years ago

Thanks for the report, this is first GUI release with Juniper support. Unfortunately, I don't have access to this equipment - and I guess, your is not public testing equipment so I can tackle directly to it ;-)

From your report, the only difference is newest GnuTLS. The remaining should be more-less aligned with release version. But this should not be the problem.

I see, you are building the app, could you please try this?

  1. please make debug build of openconnect-gui.exe
  2. save into e.g. D:\gdbCommands.txt

    set pagination off set logging file D:\oc-gui.txt set logging on run bt info thread bt full q

  3. then invoke:

    c:\Dev\Qt\5.8\mingw53_32\bin\qtenv2.bat gdb -x D:\gdbCommands.txt c:\Users\lubom\Documents\Projekty_foss\build-openconnect-gui-Desktop_Qt_5_8_0_MinGW_32bit-Debug\bin\openconnect-gui.exe

Please adjust paths with respect to your PC. And then please upload the 'oc-gui.txt' file. Thanks.

irakhlin commented 7 years ago

I will give this a shot over the weekend and report my findings. I should have also added the following. In the previous build, I believe openconnect gui 1.4x you had updated the openconnect library to 7.07 which provided me with what I needed to enable juniper support. I modified the code in the gui client to set the default protocol for all connections to the 'nc' (juniper protocol). This had the desired effect as all my connections were able to authenticate and handshake with juniper servers, however the end result was identical to what we are seeing here. I would receive an IP address, and about 10 seconds in the client would hard crash. I did not think much of it because it was a very hacking approach but it should be noted that this was using all previous versions of the libraries so I would be surprised if gnutls was to blame, but who knows?

As far as my testing env, yes I test this against a work server however as I mentioned earlier I am fully comfortable doing screen sharing sessions. This issue is so easy to reproduce at this point I don't think you will need to waste much time even testing it against my server. Additionally if it helps I believe I still have the juniper VM template that they provide for "testing" their server product. It has a limit on how many users can be created and back end authentication types but this seems like it may be the perfect place to use it for testing as it creates a virtual juniper vpn server.

Before I give the above a test I just wanted to check a few things, would you rather I rebuild the debug client as 32bit or 64bit? Additionally I have been building all my client versions using msys2 but had no issue cross compiling in fedora, is there a preference?

nmav commented 7 years ago

If you are testing in fedora and debugging a crash, and easier path may be compiling for Linux, and then using valgrind to get info about the crash. If we are lucky the crash will occur in it.

irakhlin commented 7 years ago

Sorry let me clear that up; I mean I am building either in windows using msys2 or in fedora using the provided mingw64 packages. I only mentioned this incase you believed the difference between the two compilers were somehow creating different binaries/libraries. It does not seem that I can build openconnect-gui TARGETED for linux as I get XXX: only mingw and apple build supported yet.

irakhlin commented 7 years ago

Regardless, running my 64bit client and performing the debugging actions you mentioned here is what I am seeing, attached as a log file output here: full_debug_log.txt

irakhlin commented 7 years ago

err terrible line end formatting on that log let me know if this is easier to read output.txt

horar commented 7 years ago

Thanks for update of your observations and logs.

The simplest quick test could be put a 'return' statement in openconnect-gui/src/vpninfo.c:35 file, soemthing like:

... static void stats_vfn(void privdata, const struct oc_stats stats) { return; // temporary skip this stat info VpnInfo vpn = static_cast<VpnInfo>(privdata); const char* cipher; QString dtls;

cipher = openconnect_get_dtls_cipher(vpn->vpninfo); ...

We will just ignore statistic update on 'info' tab.

About 32/64 bit ... it shouldn't have impact. But when you want build it on Linux target, just comment this code in openconnect-gui/src/CMakeLists.txt:218

... set(additionalLib \${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}.app/Contents/PlugIns/platforms/libqcocoa.dylib) else()

message(FATAL_ERROR "XXX: only mingw and apple build supported yet")

endif() ...

Linux is supported as well; this was just a comment for me, to review this part when re-esigning build script. And then you can try valgrind on Linux OS as suggested..

(I ask about your test nevironment, just if it will possible to get temporary access to it; but if you have sample VM image, pre-configured image may help us play with issue i.e. debug the app and watch various internals...)

BrendanThompson commented 7 years ago

I am having this exact same issue. :(

horar commented 7 years ago

yes, I plan to release in near time next version 1.5.2; let see if it will solve this problem

irakhlin commented 7 years ago

Sorry for no update on this; I have had no time to look into this from my end. Do you believe any recent updates would have fixed this issue? I can perform the same tests as before with updated versions if you believe that to be the case.

horar commented 7 years ago

@irakhlin I don't have access to your configuration, but there are was release fewe changes that may solve problems reported by you; please len me know, thanks in advance...

elTorres commented 6 years ago

With 1.5.2 I get the same issue (Windows 10 1709 64 bit)

horar commented 6 years ago

hi @elTorres , the same issue? It was reported agains macOS - where all build made via HomeBrew are broken/non-portable.

You find a problem on Windows... could you please share mode details? Thanks. In addition, you can find a development snapshot

elTorres commented 6 years ago

Hi @horar , I have tested the development snapshot with same result

image

irakhlin commented 6 years ago

Just tried it against the same server/env (my work) and the issues seems to be slightly different but without knowing what specific troubleshooting youd want I cant say for sure. I use to get the same crash as the image above but now the connection stays up for about 20 seconds longer (still no actual traffic) and the app will die silently. Just tested it very quickly with your most recent snapshot. Let me know what information you would need again to help.

horar commented 6 years ago

@elTorres, @irakhlin do you test only GUI version of app or you face the same problems with console app?

elTorres commented 6 years ago

I tested both: GUI version throws the error I posted and command line is supposed to connect OK, but I believe that the routes are not well added as I can´t connect to any machine but I have no problems with official Pulse Secure client

horar commented 6 years ago

@elTorres ok, thanks for update...

rburtch3 commented 6 years ago

@horar I have this same issue when I connect to OpenConnect GUI on Mac. The app will connect, then it will crash and after that, I'm unable to access any internet webpages and I have to reboot my mac in order to fix that. Can you help?

horar commented 6 years ago

@rburtch3 hi, what version do you use on macOS? ur build it from source code or do u use pre-compiler package? ... IMHO u don't need to reboot, just disconnect and connect network to re-configure routes (when app crash, it setup vpn routes and after crash...)

rburtch3 commented 6 years ago

I use the latest pre-compiled package

Sincerely,

Ryan Burtch

On Jan 30, 2018, at 3:46 PM, Ľubomír Carik notifications@github.com wrote:

@rburtch3 hi, what version do you use on macOS? ur build it from source code or do u use pre-compiler package? ... IMHO u don't need to reboot, just disconnect and connect network to re-configure routes (when app crash, it setup vpn routes and after crash...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

horar commented 6 years ago

@rburtch3 I'm sorry :-) ... but the 'last' mean?? 1.5.1 dmg or 1.5.2 bottle or ?? (macOS packages are still just proof of concept)

rburtch3 commented 6 years ago

openconnect-gui-1.5.2.high_sierra.bottle.tar

Sincerely,

Ryan Burtch

On Tue, Jan 30, 2018 at 6:38 PM, Ľubomír Carik notifications@github.com wrote:

@rburtch3 https://github.com/rburtch3 I'm sorry :-) ... but the 'last' mean?? 1.5.1 dmg or 1.5.2 bottle or ??

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openconnect/openconnect-gui/issues/157#issuecomment-361783767, or mute the thread https://github.com/notifications/unsubscribe-auth/AGXZybQf3gy_Yg0XWazXPRZFUq5a1mP2ks5tP7YagaJpZM4L1rFI .

rburtch3 commented 6 years ago

Any thoughts?

Sincerely,

Ryan Burtch

On Tue, Jan 30, 2018 at 6:49 PM, Ryan Burtch rburtch3@gmail.com wrote:

openconnect-gui-1.5.2.high_sierra.bottle.tar

Sincerely,

Ryan Burtch

On Tue, Jan 30, 2018 at 6:38 PM, Ľubomír Carik notifications@github.com wrote:

@rburtch3 https://github.com/rburtch3 I'm sorry :-) ... but the 'last' mean?? 1.5.1 dmg or 1.5.2 bottle or ??

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openconnect/openconnect-gui/issues/157#issuecomment-361783767, or mute the thread https://github.com/notifications/unsubscribe-auth/AGXZybQf3gy_Yg0XWazXPRZFUq5a1mP2ks5tP7YagaJpZM4L1rFI .

horar commented 6 years ago

@rburtch3 , there are 2 issues:

...working on it as far as possible ;-)

jpmannin-p commented 6 years ago

Reproduced at my location with the version packaged in the 1.5.3 installer here on Windows 10 Pro (Version 1803, OS Build 17134.345)

I did notice that checking "Disable UDP" in connection settings prevents the crash. This did not fix my connection problems, though, however that is possibly an unrelated issue as public sites (like mit.edu) are accessible while the connection is on.

Spongman commented 5 years ago

i can verify that the windows 32-bit 1.5.3 build (from github releases) quits shortly (~5s) after connecting.

when 'Disable UDP' is checked (ugh, negative checkbox?!) it seems to be more stable (hasn't crashed yet).

horar commented 5 years ago

@Spongman hi, could you please try snapshot version? It will go in near time out as 1.5.4 with openconnect8