[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] OpenVPN eats all my CPU when using the mgmnt interface


  • Subject: Re: [Openvpn-users] OpenVPN eats all my CPU when using the mgmnt interface
  • From: Mathias Sundman <mathias@xxxxxxxxxx>
  • Date: Fri, 7 Jan 2005 07:22:10 +0100 (CET)

On Thu, 6 Jan 2005, James Yonan wrote:

On Wed, 5 Jan 2005, James Yonan wrote:

On Wed, 5 Jan 2005, Mathias Sundman wrote:

On Wed, 5 Jan 2005, Mathias Sundman wrote:

I just observed that one of my OpenVPN processes were using 99% of my CPU on
my newly installed password auth based firewall.

After some testing I've found that it's the management interface that's
causing it. Starting OpenVPN and everything is calm, but as soon as I connect
to the management interface, OpenVPN starts looping eating up all CPU, and it
does not stop after I disconnect from the management interface. I have to
restart OpenVPN to get rid of the problem.

Connecting with a OpenVPN client also causes openvpn to exit this loop.

openvpn@fw-ktn:/etc/openvpn$ openvpn --version
OpenVPN 2.0_rc5 i686-pc-linux [SSL] [LZO] built on Dec 16 2004

openvpn@fw-ktn:/etc/openvpn$ uname -a
Linux fw-ktn 2.4.26 #2 Wed Jun 30 15:30:57 CEST 2004 i686 unknown

This is what I get when running strace on the process:

poll([{fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=3,
events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI, revents=POLLNVAL}], 4,
10000) = 1
time(NULL)                              = 1104923675
poll([{fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=3,
events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI, revents=POLLNVAL}], 4,
10000) = 1

A little follow-up on this problem.

I had no problem reproducing it on an other machine, but I found another
interesting thing. The problem only occurs when running openvpn as a
tcp-server. If I use --proto udp the problem never occurs.

I've already found the bug. It only occurs in tcp server mode, in event poll mode, and when the management interface is being used. Event poll mode is used by all *nix OSes except for Linux 2.6, so the bug won't occur there.

The bug occurs because a subtle difference in behavior between poll and
epoll breaks the OpenVPN event abstraction layer which is supposed to
(from an API perspective) hide the differences between poll, epoll,
select, and WSAWaitForMultipleEvents. Basically epoll doesn't care if you
close a file descriptor in the event list -- it will do the sane thing and
remove it from the list automatically.  Poll on the other hand doesn't
like to see a closed fd in the event list, and will return immediately
with POLLNVAL.  So the fix is that the OpenVPN poll driver needs to
emulate the epoll behavior -- or OpenVPN needs to make sure that it
manually deletes all closed fds from any relevant event lists.

I should have a fix shortly.

Okay, here's a patch (attached) which fixes the above bug. Please test.

This patch also includes:

* --ifconfig-push now accepts DNS names as well as
 IP addresses.
* Added sanity check errors when --pull or
 --auth-user-pass is used in an incorrect mode.

Works like a charm! Thanks!

--
_____________________________________________________________
Mathias Sundman                  (^)   ASCII Ribbon Campaign
OpenVPN GUI for Windows           X    NO HTML/RTF in e-mail
http://www.nilings.se/openvpn    / \   NO Word docs in e-mail