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
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.
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?
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.
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.
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?
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.
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.
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/
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.
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.
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
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
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
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
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.
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
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.
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.
Created attachment 510195 [details] Patch to fix connection stability issues
Why have upstream not applied this patch?
No idea. Version 0.5.3 has been the latest version since 2008.
Hi. How to apply this patch in Verne?