Opened 9 years ago

Closed 9 years ago

#567 closed Bug / Defect (fixed)

OpenVPN fails with no log output when config file is empty or (sometimes) has a non-whitespace syntax error

Reported by: badon Owned by:
Priority: blocker Milestone: release 2.3.11
Component: Generic / unclassified Version: OpenVPN 2.3.7 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Samuli Seppänen, Heiko Hund

Description

If a functional OpenVPN config file has an error in the first parsed item on a line, and the error is not extra whitespace, then OpenVPN will fail without any log output, which normally should indicate the first occurring syntax error on a specific line. The same result (maybe a different bug) will also occur if the config file has only a single empty line.

I have config files where this bug does NOT occur, but I'm not sure how they are getting around the code that triggers this bug. That may be a different bug, if somehow the syntax error is not being logged or not being detected. Those config files are a lot more complicated, but I think the simplest case with a config file that either has no content, or has only a single line with a single character is sufficient to reproduce this bug and fix it. It might be possible to isolate the bug where my other config files failed to log a syntax error, after this bug is fixed. Obviously, accurate log output will be helpful.

I chose to give this report "blocker" priority, because it conceivably can prevent research of other bugs, due to lack of log information. For example, it took me more than a year to notice a single character error in the config file that triggers this bug, which prevented isolation and reporting of such a simple bug. The fact that other, more complex config files had the same error, but did NOT trigger the bug, made it more difficult to find the problem. If the problem weren't an obvious syntax error, I would never have found it, and I never would have been able to report this bug (and thus fixing it would have been "blocked").

Tested with: OpenVPN 2.3.7 i686 (x64) Windows 7.

My search for previous reports of this bug:

https://community.openvpn.net/openvpn/query?status=accepted&status=assigned&status=new&status=reopened&summary=~log&col=id&col=summary&order=priority

Despite how simple this bug is, I was surprised there were no previous reports of it. I think the fact that it results in no log output is the sole reason why no one was able to report it.

Change History (14)

comment:1 Changed 9 years ago by Gert Döring

Cc: plaisthos added

Plaisthos: another magic 3-line fix?

comment:2 Changed 9 years ago by Gert Döring

Milestone: release 2.3.8
Version: 2.3.82.3.7

comment:3 Changed 9 years ago by plaisthos

When you say "no log output" do you no logging to a file or no message to the console? How are you starting OpenVPN under windows?

The issue query does not yield any bug which seem to be related in any way to this bug.

A single empty line gives me:

Options error: You must define TUN/TAP device (--dev)
Use --help for more information.

as expected.

If I cannot reproduce a bug in a simple way, it is not a "simple bug"

comment:4 Changed 9 years ago by badon

OK, then something more must be required to trigger this bug. This is completely reproducible on my system. I am starting OpenVPN GUI as administrator with a Windows shortcut that has the "target" as:

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect "some file.ovpn"

There is no logging to file, AND no message to the console. I don't have any problems with TUN/TAP in Windows, but maybe that's something that needs to be tested further to help you reproduce this bug? Do you run it as administrator?

comment:5 Changed 9 years ago by plaisthos

Instead of starting OpenVPN from a shortcut you should run the command from cmd.exe and see if that makes a diffences.

Probably OpenVPN logs the error and then the cmd window immediately closes without you having the chance to see the message.

comment:6 Changed 9 years ago by Gert Döring

Milestone: release 2.3.8release 2.3.9

@badon: have you tried running "openvpn.exe somefile.ovpn" directly from the CLI to see whether the problem is just in communicating the error back to the GUI (which is likely for a parsing problem)? This is sort of a known issue and not easy to fix, but it would be good to understand whether you're hit by that...

comment:7 Changed 9 years ago by januzi

Hello

I've spent some time trying to find a reason why I couldn't connect to the server. Let me tell you this, empty log file wasn't helping at all. Yes, there was parsing problem, and the Windows app should point it directly to the user. At this point it is just saying "I'm using this config file you've provided, everything is fine, carry on" and then it just fails trying to connect ... localhost, I guess, or something else that is set as default host (if empty, then why ffs it takes 2 minutes to display an error message?). I've tested the newest version and the problem is still there. You have got two options:

  1. modal window saying that there is an error in the config file (+ the problematic line/s)
  2. an error message in the client.log, or better, in the error.log

First one is better. That way you will point the user right into the proper direction. I hope that you'll fix this problem soon. And I mean FIX IT. Do not put another line into the FAQ saying what users should do. That's lazy way.

Last edited 9 years ago by januzi (previous) (diff)

comment:8 in reply to:  7 Changed 9 years ago by Gert Döring

Hi,

Replying to januzi:

First one is better. That way you will point the user right into the proper direction. I hope that you'll fix this problem soon. And I mean FIX IT. Do not put another line into the FAQ saying what users should do. That's lazy way.

I agree that this would be a good thing to have. We welcome your patches to openvpn-gui.

comment:9 Changed 9 years ago by Gert Döring

Cc: Samuli Seppänen Heiko Hund added; plaisthos removed
Milestone: release 2.3.9release 2.3.11

comment:10 Changed 9 years ago by Selva Nair

This is caused by two issues:

(i) The GUI does not pass "--log" as the first option, so such early errors do not get written to the log
(ii) The GUI communicates with OpenVPN through the management interface, but such errors happen before the management interface is connected.

(i) is fixed in the following pull request

https://github.com/OpenVPN/openvpn-gui/pull/15

For (ii) a partial remedy is in the following pull request

https://github.com/OpenVPN/openvpn-gui/pull/16

If an "early exit" by openvpn is suspected, it pops up a message box asking the user to view the log file for details.

Note that log is best viewed the "View Log" menu entry, to be sure that one is looking at the right log file. Note, however, "View Log" was buggy before commit 09334e71a0277ecf00e45b389c9238a150e13317

comment:11 in reply to:  10 Changed 9 years ago by Samuli Seppänen

Replying to selvanair:

I merged the two pull requests today. The fixes will be (soon) included in:

comment:12 Changed 9 years ago by Samuli Seppänen

This has now been fixed in latest Git "master" snapshot installers.

comment:13 Changed 9 years ago by Samuli Seppänen

Selva's fixes probably won't be backported to OpenVPN 2.3 - too much effort for too little gain. Plus we want to keep OpenVPN-GUI in OpenVPN 2.3 installers as stable as possible.h

comment:14 Changed 9 years ago by Samuli Seppänen

Resolution: fixed
Status: newclosed

We discussed this bug in today's IRC meeting and agreed that the Selva's fixes are good enough. I'm closing this bug now.

Note: See TracTickets for help on using tickets.