Bug 504855 - vpnc uses 100% CPU after sometime
vpnc uses 100% CPU after sometime
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: vpnc (Show other bugs)
15
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-09 14:49 EDT by Felix Möller
Modified: 2011-11-18 07:34 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 10:13:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of vpnc process (38MB extracted) (182.69 KB, application/x-gzip)
2009-06-09 14:49 EDT, Felix Möller
no flags Details
Patch to fix connection stability issues (2.67 KB, patch)
2011-06-28 01:02 EDT, Eric Work
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 479632 None None None Never

  None (edit)
Description Felix Möller 2009-06-09 14:49:05 EDT
Created attachment 347074 [details]
strace of vpnc process (38MB extracted)

Description of problem:
My university uses a Cisco VPN. 

The following pcf file is provided:
Description=Verbindung zur Universitaet Muenster
!Host=vpnserver.uni-muenster.de
AuthType=1
!GroupName=vpnstandard
GroupPwd=
!enc_GroupPwd=xxx
Username=
SaveUserPassword=0
UserPassword=
enc_UserPassword=
!EnableBackup=1
!BackupServer=vpnserver2.uni-muenster.de
EnableNat=0
TunnelingMode=0
TcpTunnelingPort=10000
PeerTimeout=90
!EnableLocalLAN=0

I can import and use the VPN perfectly with NetworkManager. After maybe an hour being connected with little traffic vpnc starts using 100% CPU. Disconnecting and connecting again solves the issue.

I straced the process while it used 100% CPU see attachment.

Version-Release number of selected component (if applicable):
[root@macbook fm]# rpm -q vpnc
vpnc-0.5.3-3.fc11.i586

How reproducible:
allways (three out of three times today)

Steps to Reproduce:
1. connect to the above mentioned vpn
2. wait 
3. look at cpu load
  
Actual results:
100% CPU load

Expected results:
little load
Comment 1 Richard W.M. Jones 2009-06-09 14:54:39 EDT
The strace is lots of ...

select(7, [3 4 6], NULL, NULL, {32, 0}) = 1 (in [6], left {31, 999994})
time(NULL)                              = 1244551811
select(7, [3 4 6], NULL, NULL, {32, 0}) = 1 (in [6], left {31, 999994})
time(NULL)                              = 1244551811
select(7, [3 4 6], NULL, NULL, {32, 0}) = 1 (in [6], left {31, 999994})
time(NULL)                              = 1244551811

This isn't really too useful.  Can you install the
vpnc-debuginfo package, then when it hits 100% CPU,
attach to it with gdb and see where it is looping in
the code.
Comment 2 Felix Möller 2009-06-09 16:27:11 EDT
Attaching gdb I get the following:

Loaded symbols for /lib/libresolv.so.2
0x00a58422 in __kernel_vsyscall ()
(gdb) bt
#0  0x00a58422 in __kernel_vsyscall ()
#1  0x004fdead in ___newselect_nocancel () from /lib/libc.so.6
#2  0x00a2f079 in vpnc_main_loop (s=<value optimized out>) at tunip.c:853
#3  vpnc_doit (s=<value optimized out>) at tunip.c:1064
#4  0x00a3b54c in main (argc=4, argv=0xbfe17194) at vpnc.c:3309

are there any other gdb command that would help?
Comment 3 Richard W.M. Jones 2009-06-10 04:44:56 EDT
So it seems to be looping around the big loop
(in the source at tunip.c:845 or the inner loop
at tunip.c:848).

You could use gdb to follow it around that loop
to see what conditions are and aren't satisfied.

However I'd caution that since the code is
optimized, it will be a bit hard to follow,
so it might be better to recompile vpnc without
any optimization (no -O flags) first.

I can't reproduce this here -- I use vpnc
daily, and have not seen this issue.
Comment 4 Felix Möller 2009-06-11 05:46:32 EDT
I modified /usr/sbin/vpnc to dump stdin to a file. The following gets passed to vpnc.

Script /usr/libexec/nm-vpnc-service-vpnc-helper
Cisco UDP Encapsulation Port 0
IPSec gateway vpnserver.uni-muenster.de
IPSec ID vpnstandard
DPD idle timeout (our side) 90
NAT Traversal Mode none
Xauth username f_moel03
Xauth password xxx
IPSec secret xxx

Will try to reproduce with this and plain vpnc.
Comment 5 Felix Möller 2009-06-11 11:47:10 EDT
I have compiled it myself with -O0.

[root@macbook fm]#  /home/fm/vpnc/tags/vpnc-0.5.3/vpnc nm
[root@macbook fm]# cat /etc/vpnc/nm.conf 
#Script /usr/libexec/nm-vpnc-service-vpnc-helper
Cisco UDP Encapsulation Port 0
IPSec gateway vpnserver.uni-muenster.de
IPSec ID vpnstandard
DPD idle timeout (our side) 90
NAT Traversal Mode none
Xauth username f_moel03
Xauth password xxx
IPSec secret xxx

(gdb) bt
#0  0x00ea8422 in __kernel_vsyscall ()
#1  0x00ac6ead in ___newselect_nocancel () from /lib/libc.so.6
#2  0x0804e641 in vpnc_main_loop (s=0xbfc876cc) at tunip.c:853
#3  0x0804f01c in vpnc_doit (s=0xbfc876cc) at tunip.c:1064
#4  0x0805cafc in main (argc=2, argv=0xbfc87904) at vpnc.c:3305
(gdb) c

854				if (presult == 0 && (s->ike.do_dpd || enable_keepalives)) {
Current language:  auto; currently c
(gdb) s
883				DEBUG(2,printf("lifetime status: %ld of %u seconds used, %u|%u of %u kbytes used\n",
(gdb) s
889			} while ((presult == 0 || (presult == -1 && errno == EINTR)) && !do_kill);
(gdb) s
890			if (presult == -1) {
(gdb) s
896			if (FD_ISSET(s->tun_fd, &refds)) {
(gdb) s
901			if (FD_ISSET(s->esp_fd, &refds) ) {
(gdb) s
905			if (s->ike_fd != s->esp_fd && FD_ISSET(s->ike_fd, &refds) ) {
(gdb) s
911			if (timed_mode) {
(gdb) s
912				time_t now = time(NULL);
(gdb) s
*__GI_time (t=0x0) at ../sysdeps/unix/sysv/linux/time.c:31
31	  time_t res = INTERNAL_SYSCALL (time, err, 1, NULL);
Current language:  auto; currently minimal

I have no idea, how to operate gdb and which conditions to watch out for ... ;) Could you provide some more help?
Comment 6 doolan 2009-06-26 16:24:12 EDT
I also have vpnc 0.5.3 but I don't use networkManager. I use a static IP and simply run vpnc on the command line after struggling with networkManager for quite some time. I also have the 100% cpu issue every couple of days, even though I connect to our VPN most days for up to 8 hours a day.

Let me know if I can help track this problem down it any way.
Comment 7 Felix Möller 2009-10-08 05:01:20 EDT
I still experience this bug. With my university it happens reliable after arround 60 minutes. 

Anything that can be done to solve this issue? I could provide credentials if needed.
Comment 8 Richard W.M. Jones 2009-10-08 05:17:31 EDT
Sorry, we use vpnc here daily and no one has reported this issue.
You could try reading about gdb.  There is an extensive manual
available here:
http://www.gnu.org/software/gdb/documentation/
Comment 9 Felix Möller 2009-10-08 05:42:48 EDT
Richard, I have allready compiled vpnc with -O0 an run it in gdb (see comment #5). What other information would be helpfull so what should i look up in the gdb documentation?

I'd appreciate some guidance and as said you may try yourself.
Comment 10 Felix Möller 2009-10-18 16:23:58 EDT
Ok, as this is really annoying I have updated my system to rawhide.
Sadly this does not help at all.

I have written a mail to the upstream mailinglist. http://lists.unix-ag.uni-kl.de/pipermail/vpnc-devel/2009-October/003272.html Maybe they have an idea.
Comment 11 Bug Zapper 2009-11-16 05:02:40 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Felix Möller 2009-11-30 18:27:37 EST
I added a Debug 3 to my configfile and now I have the following in my logs:
Dec  1 00:21:30 thinkpad vpnc[8139]: HMAC mismatch in ESP mode
Dec  1 00:21:34 thinkpad vpnc[8139]: HMAC mismatch in ESP mode
Dec  1 00:21:34 thinkpad vpnc[8139]: HMAC mismatch in ESP mode
Dec  1 00:21:35 thinkpad vpnc[8139]: HMAC mismatch in ESP mode

Running with Debug 2 the CPU load does not go to 100%.

Ubuntu seems to have the same problem:
https://bugs.launchpad.net/fedora/+source/vpnc/+bug/479632
Comment 13 Bug Zapper 2010-11-04 07:09:39 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Dawid Gajownik 2010-12-03 23:07:04 EST
I had the same problem on F9 and F11 (100% CPU usage). On F13 it's a bit better - vpnc uses only fraction of CPU power, but connection still fails after one hour. This time depends only on VPN gateway configuration:

WK-MDF-r1#sh crypto ipsec security-association lifetime 
Security association lifetime: 4608000 kilobytes/3600 seconds

WK-MDF-r1#

I found in Ubuntu Launchpad link to the patches that fix this bug:
http://www.gossamer-threads.com/lists/vpnc/devel/3442
They need some adjusting to properly apply on Fedora's SRPM but they work for me.

HTH
Comment 15 Bug Zapper 2010-12-05 01:52:16 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 16 Bug Zapper 2011-06-02 14:02:48 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bug Zapper 2011-06-27 10:13:37 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 18 Eric Work 2011-06-28 01:01:35 EDT
This problem still exists in Fedora 15.  Applying the patches from http://www.gossamer-threads.com/lists/vpnc/devel/3442 fixes the problem and makes my connection very stable.  I've been connected to a Cisco 870 for about 4 hours, and one of those hours I was away from the computer.  Previously I would have been lucky to stay connected for one hour.  The patches from the thread above appear to fix some general functional issues.  I have attached a combined and updated version of the patch.  If this patch could be applied to the current vpnc package I think many people would appreciate it.  Ubuntu has already applied these patches a long time ago.
Comment 19 Eric Work 2011-06-28 01:02:49 EDT
Created attachment 510195 [details]
Patch to fix connection stability issues
Comment 20 Richard W.M. Jones 2011-06-28 03:25:29 EDT
Why have upstream not applied this patch?
Comment 21 Eric Work 2011-06-28 03:31:45 EDT
No idea.  Version 0.5.3 has been the latest version since 2008.
Comment 22 Reginaldo Ribeiro 2011-11-18 07:34:17 EST
Hi. How to apply this patch in Verne?

Note You need to log in before you can comment on or make changes to this bug.