|
|
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.
James
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2005-01/msg00060.html on line 237
Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2005-01/msg00060.html on line 237
|