everything seems to work for about 5 min and then vpnc dies suddently, no more tun0 and PID. /var/log/messages tells me this: vpnc[27670]: connection terminated by dead peer detection If that's any help, my company's firewall is a cisco PIX 501. my config file /etc/vpnc.conf is default (besides pwd/usr, etc..) Reproducible: Always Portage 2.1.4.4 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r9 i686) ================================================================= System uname: 2.6.23-gentoo-r9 i686 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz Timestamp of tree: Sun, 20 Apr 2008 10:34:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://192.168.0.1/gentoo-portage" USE="X aac acl alsa avahi berkdb cairo cdr cli cracklib crypt cups dbus dri dvd dvdr firefox fortran gdbm gif gnome gpm gtk hal iconv ipv6 isdnlog jpeg kerberos ldap lm_sensors midi mp3 mpeg mudflap ncurses nls nptl nptlonly opengl openmp pam pcre pdf perl png pppd python readline reflection samba server session spl srt ssl tcpd tiff unicode vim-syntax win32codecs wma x264 x86 xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Do you start by the init script or by hand? If the latter enable a higher debug level and attach the output or contact the original authors with it.
Created attachment 150904 [details] output of: vpnc --debug 3
I cannot find the output for the termination, so I am not quite sure your log is complete.
Do you want to test a SVN snapshot if the problem still exists?
(In reply to comment #4) > Do you want to test a SVN snapshot if the problem still exists? > Sorry about my silence, I was busy. I attached the full output: vpnc_debug_2.log2 It seems to be the same problem as bug #220795. I used to run an older vpnc version successfully in the past (same cisco PIX 501) but i forgot which version. We can try svn snapshots. C.
Created attachment 152569 [details] output of: vpnc --debug 2 --no-detach
*** Bug 220795 has been marked as a duplicate of this bug. ***
Ok, I added a snapshot (currently in testing so edit package.keywords file) to Portage. Please test it and report back.
I have a noob question: I have this in package.keywords: net-misc/vpnc ~x86 and after an emerge --sync I get this: # emerge -vp =net-misc/vpnc-0.5.2_pre20080509 These are the packages that would be merged, in order: Calculating dependencies /!!! A file is not listed in the Manifest: '/usr/portage/net-misc/vpnc/vpnc-0.5.2_pre20080509.ebuild' !!! All ebuilds that could satisfy "=net-misc/vpnc-0.5.2_pre20080509" have been masked. !!! One of the following masked packages is required to complete your request: - net-misc/vpnc-0.5.2_pre20080509 (masked by: corruption) I there something I'm doing wrong ?
(In reply to comment #9) > I have a noob question: > I have this in package.keywords: net-misc/vpnc ~x86 > and after an emerge --sync I get this: > I there something I'm doing wrong ? No. My fault. I regenerated the Manifest now, so in about an hour you can go an resync.
(In reply to comment #8) > Ok, I added a snapshot (currently in testing so edit package.keywords file) to > Portage. Please test it and report back. ...Bad news... I installed the svn snapshot: # emerge -vp vpnc [ebuild R ] net-misc/vpnc-0.5.2_pre20080509 USE="-bindist -hybrid-auth -resolvconf" 0 kB Still the exact same issue, see new attachement (vpnc_debug_2.log3) for debug output.
Created attachment 152825 [details] output of: vpnc --debug 2 --no-detach (vpnc-0.5.2_pre20080509)
I just checked vpnc 0.4.0 and I have similar problems there.
(In reply to comment #13) > I just checked vpnc 0.4.0 and I have similar problems there. Sorry guys, but I don't understand the code enough to investigate your issues.
Well, it seems adding the following line to the vpnc.conf for the svn snapshot does the trick: DPD idle timeout (our side) 0
(In reply to comment #15) > Well, it seems adding the following line to the vpnc.conf > for the svn snapshot does the trick: > > DPD idle timeout (our side) 0 Can the rest confirm this solution?
It seems only that this disables the dead peer detection completly. That has the effect, that the connection is dead but vpnc does not recognise this anymore. Without the option, at least after a minute or so (perhaps a minute is the default value for this setting?) vpnc detects it and quits. For me, always when vpnc detects a dead peer, then the connection was already broken. Restart of vpnc helps as usual then.
(In reply to comment #16) > (In reply to comment #15) > > Well, it seems adding the following line to the vpnc.conf > > for the svn snapshot does the trick: > > > > DPD idle timeout (our side) 0 > > Can the rest confirm this solution? > This would explain why an older version of vpnc worked well for christophe, because the dead peer detection was added recently in 0.5.0.
I just took a look into /var/log/messages and I see this: acbook ~ # tail -n 100 /var/log/messages May 18 13:50:51 macbook vpnc[30839]: sendto: Message too long May 18 13:50:51 macbook vpnc[30839]: sendto: Message too long May 18 13:50:52 macbook vpnc[30839]: sendto: Message too long May 18 13:50:52 macbook vpnc[30839]: sendto: Message too long May 18 13:50:52 macbook vpnc[30839]: sendto: Message too long May 18 13:50:52 macbook vpnc[30839]: sendto: Message too long May 18 13:50:53 macbook vpnc[30839]: sendto: Message too long ... macbook ~ # cat /var/log/messages | grep "Message too long" | wc -l 39745 (Really incredible! Sometimes this message was pushed 8 times per second. It always happens when the connection is died (or perhaps that is the reason why the connection is dieing?).) Funny that I don't have seen this before (or don't recognised). I am running vpnc with --no-detach, therefore I thought I get all messages in the terminal but don't seem so.
Sometimes, the connection breaks also without the message 'Message too long'. Whereby this is very seldom.
Ok boys, I prepared a new vpnc snapshot which hopefully fixes this as Joerg Mayer committed some patches to the trunk. Please test again. I'd like some feedback so I can tell Joerg about it.
(In reply to comment #21) > Ok boys, I prepared a new vpnc snapshot which hopefully fixes this as Joerg > Mayer committed some patches to the trunk. Please test again. I'd like some > feedback so I can tell Joerg about it. Hello guys, you still around to test it?
When you made the last snapshot, I was already using the SVN from the same time. I am also reading the mailinglist and it seems they are working more hard on it the last time. I have also looked into most of the code changes but none (of them I have looked at) is related to our problem. At least there is an interesting TODO of reconnecting and reusing the interface and also some other interesting TODOs. Atm, I do not depend on vpnc+wifi anymore as I finally have wired Internet here (thanks god...). Therefore I am not anymore an everyday user of vpnc. I think most of the problems were also related of the unstable wifi connection (a lot of packages gets lost always). But I will report back when there are any new information.
(In reply to comment #23) > But I will report back when there are any new information. I also do read upstream's mailing list and I was sure I read a commit that was relevant to your problems...anyway I cannot find it anymore.
In the URL field I referenced a post to the vpnc mailing list. Please try the patch there.
_p332 contains a possible fix. Upstream writes: "This patch has not been tested by anyone who experienced/reported the problem so far - it just looks like a possible fix." So please try and report back.
I not positive this is related, but my vpnc wasn't functioning and was producing the same "Message too long" error. The thing that was slightly different is that it was preventing me from being able to connect at all. A post I found on the Ubuntu forums led to my solution: I had exactly the same MTU problem described at http://ubuntuforums.org/showthread.php?t=432699 . Even though my symptoms were slightly different, it seems reasonable to hypothesize that the "Message too long" error in this bug might *also* be related to MTU problems.
vpnc 0.5.3 is in the tree now...I would like you to test it again if your failures still happen. Thanks in advance. Please also think about comment #27 as a possible solution.
I assume this as fixed.
i had a similar problem running vpnc-0.5.3 my connection was being terminated every +-20 seconds. i worked around it by disabling dead peer detection via --dpd-idle 0.
