Login Main site Create account

09.11.2007 18:06

New patch to make Cisco VPN Client work on 64bit systems!

Today I received an e-mail from Stephen Frost who wrote a patch to the latest Cisco VPN client which should fix the compile problems on 64bit systems.
The client didn't compile on 64bit systems with the following error message during compilation:
interceptor.c:778: error: invalid operands to binary -
Due to the lack of 64bit hardware, I can't confirm that it works so you'll have to do the testing for me ;)

Please add a comment if you tried the patch and report whether it worked or not for you.
Thanks, Stephen!

Comments added earlier to http://tuxx-home.at/archives/2007/11/09/T18_06_10/index.html:
Guest on 2007-11-13 22:57:43 wrote:
Thanks! It works great on Fedora 7 (Kernel 2.6.23).
Guest on 2007-11-14 23:51:15 wrote:
Nice job all! Works fin on OpenSUSE x86_64
Guest on 2007-11-21 21:27:31 wrote:
can't patch the sources. patch version is 2.5.9 call is patch < cisco_skbuff_offset.patch
patching file frag.c
Hunk #1 FAILED at 22.
1 out of 1 hunk FAILED -- saving rejects to file frag.c.rej
Alexander Griesser on 2007-11-21 21:54:06 wrote:
What version of the Cisco VPN client are you trying to patch?
Can i please see the file "frag.c.rej"?
Guest on 2007-11-26 14:04:27 wrote:
The patch works fine without errors (thx for that)
I was able to compile and load the driver and can connect , but after a few minutes the entire system freezes :o(

System: openSuSE 10.2 x86_64 SMP

Is the patch compatible with this kernel-version?
Is there a possibility to improve the debugging of the driver output?
Is there something to enable in the ".config" during build the kernel?

Thanks in advance...

With best regards
Alexander Griesser on 2007-11-26 14:29:25 wrote:
Can you see some information about the reason for the freeze in your
system logfiles? Does this only happen when the VPN connection is up or
when the kernel module is loaded for several minutes only?

Basically, the patch should be compatible with your kernel-version, yes.
Of course there would be ways to increase the debugging level of the driver
but currently there's no debugging information built into the driver by Cisco,
so we would have to add our own debugging information to it.

There's nothing special to enable in the kernel configuration for the Cisco
VPN client to work properly (of course, network related stuff should be
enabled, etc.) but if you're missing some vital configuration options, the
client module won't compile at all, so if it compiles, it's OK.
Guest on 2007-11-26 18:32:53 wrote:
hello Alexander,

Thank you for your fast reply

In the system logs I can't see anything (because kernel panic), so I captured the kernel messages with my notebook via a serial connection:

(I hope it's not too much for this comment board)
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
[<ffffffff88ba1474>] :cisco_ipsec:CBCDecryptUpdate+0xb4/0x160
PGD 111d03067 PUD 111d08067 PMD 0
Oops: 0000 [1] SMP
Modules linked in: cisco_ipsec(P) xt_TCPMSS ipt_MASQUERADE ipt_LOG xt_tcpudp xt_limit xt_pkttype pppoe pppox snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet ppp_generic slhc cpufreq_conservative cpufreq_ondemand cpufreq_powersave powernow_k8 freq_table binfmt_misc button xt_state ipt_REJECT iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables x_tables ext2 nls_iso8859_1 nls_cp850 vfat fat nls_utf8 ntfs loop dm_mod arc4 ecb blkcipher rc80211_simple rtl8187 mac80211 cfg80211 snd_hda_intel snd_pcm nvidia(P) ide_cd snd_timer cdrom ehci_hcd i2c_nforce2 snd soundcore snd_page_alloc i2c_core ohci_hcd usbcore forcedeth floppy parport_pc lp parport ext3 mbcache jbd edd fan thermal processor sata_sil24 sg sata_nv libata amd74xx sd_mod scsi_mod ide_disk ide_core
Pid: 0, comm: swapper Tainted: P #4
RIP: 0010:[<ffffffff88ba1474>] [<ffffffff88ba1474>] :cisco_ipsec:CBCDecryptUpdate+0xb4/0x160
RSP: 0018:ffffffff80568a50 EFLAGS: 00010203
RAX: 0000000000000000 RBX: ffff8101101122d0 RCX: 0000000000000087
RDX: 0000000000005a75 RSI: 0000000000000000 RDI: 0000000000000001
RBP: 0000000000000010 R08: 0000000000000000 R09: 000000002bb933d3
R10: ffff810118e14d50 R11: 0000000000000099 R12: ffffffff88be0a1c
R13: ffffffff88be0a1c R14: 0000000000000004 R15: 00000000000000c0
FS: 00002b4b131dd130(0000) GS:ffffffff804e8000(0000) knlGS:00000000f5effb90
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000114933000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8050c000, task ffffffff804b3400)
Stack: ffff8101101122d0 ffff810118e14d50 0000000000000010 0000049004d62508
ffffffff80568b14 ffff810103f7aa10 ffffffff88bd3500 0000000000000000
0000000000000010 ffff810104d624d0 0000000000000550 ffffffff88be058c
Call Trace:
<IRQ> [<ffffffff88ba8213>] :cisco_ipsec:AHChooseFeedbackUpdate+0x23/0x40
[<ffffffff88ba7a03>] :cisco_ipsec:AHFeedbackCipherDecryptUpdate+0x133/0x240
[<ffffffff88ba8d04>] :cisco_ipsec:B_AlgorithmDecryptUpdate+0x94/0xa0
[<ffffffff88b91668>] :cisco_ipsec:BSafeDecrypt+0x108/0x1a0
[<ffffffff88b91a1d>] :cisco_ipsec:BSafeESPDecrypt+0xfd/0x1e0
[<ffffffff88b953e0>] :cisco_ipsec:CNIReceiveComplete+0x110/0xb50
[<ffffffff88b9aea9>] :cisco_ipsec:ESPIn+0x69/0x210
[<ffffffff803b8766>] ip_local_deliver+0x1c9/0x28f
[<ffffffff88b9a5ca>] :cisco_ipsec:IPIn+0x8a/0x100
[<ffffffff88b9a267>] :cisco_ipsec:TransformIn+0x77/0xf0
[<ffffffff88b9550a>] :cisco_ipsec:CNIReceiveComplete+0x23a/0xb50
[<ffffffff88b94e59>] :cisco_ipsec:CNIReceiveIndication+0x599/0x660
[<ffffffff88b90186>] :cisco_ipsec:recv_ip_packet_handler+0x201/0x2d6
[<ffffffff8039c0f3>] process_backlog+0x84/0x102
[<ffffffff8039c2fd>] net_rx_action+0xa8/0x1ae
[<ffffffff881228d3>] :forcedeth:nv_nic_irq_optimized+0x95/0x22c
[<ffffffff80238e69>] __do_softirq+0x55/0xc4
[<ffffffff8020ccfc>] call_softirq+0x1c/0x28
[<ffffffff8020de3d>] do_softirq+0x2c/0x7d
[<ffffffff8020e073>] do_IRQ+0xb6/0xd3
[<ffffffff8020ae0b>] default_idle+0x0/0x3d
[<ffffffff8020c081>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff803f1385>] unix_poll+0x0/0xa5
[<ffffffff8020ae34>] default_idle+0x29/0x3d
[<ffffffff8020aed3>] cpu_idle+0x8b/0xae
[<ffffffff80516a80>] start_kernel+0x2ca/0x2d6
[<ffffffff80516140>] _sinittext+0x140/0x144

Code: 41 8b 04 b0 31 04 b3 44 39 f7 72 f0 31 f6 31 ff 39 ee 73 4b
RIP [<ffffffff88ba1474>] :cisco_ipsec:CBCDecryptUpdate+0xb4/0x160
RSP <ffffffff80568a50>
CR2: 0000000000000000
Kernel panic - not syncing: Aiee, killing interrupt handler!

In my tests, I've noticed, that I can load the driver, I can connect and can do a 'ping' with 56 (64)... 992 (1000) bytes size and all works fine.

But when I access to the Intranet of my company or open a ssh-session the system freezed after several minutes.

Here some optional Information:

after load the driver:
Cisco Systems VPN Client Version 4.8.01 (0640) kernel module loaded

Nov 26 14:38:50 blackbox kernel: Cisco Systems VPN Client Version 4.8.01 (0640) kernel module loaded
Nov 26 14:38:50 blackbox ifup: cipsec0
Nov 26 14:38:50 blackbox ifup: No configuration found for cipsec0

blackbox:~ # lsmod | head
Module Size Used by
cisco_ipsec 594632 0


So I set all values of "LogLevel" in the '/etc/CiscoSystemsVPNClient/vpnclient.ini"-config to value "3":
and start '/usr/local/bin/ipseclog /tmp/clientlog.txt'
46 14:55:48.557 11/26/2007 Sev=Info/5 IKE/0x4300000E
MODE_CFG_REPLY: Attribute = APPLICATION_VERSION, value = Cisco Systems, Inc ASA5510 Version 8.0(2) built by builders on Fri 15-Jun-07 19:29
79 14:55:49.827 11/26/2007 Sev=Info/4 IPSEC/0x43700037
Configure public interface: 24.48.1350482808.4294934784. SG: 1350482600.4294934784.1421316776.429493� ��@���@���

80 14:55:49.827 11/26/2007 Sev=Info/4 IPSEC/0x4370002F
Assigned VA private interface addr 24.48.1350482792.4294934784

81 14:55:57.459 11/26/2007 Sev=Info/4 IPSEC/0x43700019
Activate outbound key with SPI=0x00000018 for inbound key with SPI=0x00000030

82 15:04:59.903 11/26/2007 Sev=Info/4 IKE/0x43000013

83 15:04:59.903 11/26/2007 Sev=Info/6 IKE/0x4300003D
Sending DPD request to 195.XXX.XXX.XXX, our seq# = 735705384

84 15:04:59.965 11/26/2007 Sev=Info/5 IKE/0x4300002F
Received ISAKMP packet: peer = 195.XXX.XXX.XXX

85 15:04:59.966 11/26/2007 Sev=Info/4 IKE/0x43000014

86 15:04:59.966 11/26/2007 Sev=Info/5 IKE/0x43000040
Received DPD ACK from 195.XXX.XXX.XXX, seq# received = 735705384, seq# expected = 735705384

87 15:05:15.965 11/26/2007 Sev=Info/4 IKE/0x43000013
(the public IP is "x'ed" for security rasons)

At 15:08 the systems hangs.... :o(

Perhaps you have any hint's (hope :)

... or I have to downgrade

(the driver with kernel 2.6.20 works fine on this hardware)

Thanks in advance...

With best regards
Guest on 2007-11-27 08:19:26 wrote:
Great Work.

On Fedora-7 x86_64 work.

Alexander Griesser on 2007-11-27 09:38:39 wrote:
It seems as if something changed in the recv_ip_packet_handler() function (which would be easy to change) or something changed inside the closed
source libvpnapi. If the latter is the case, you're out of luck and can only file
a bug report to Cisco, if the first is the case, I think we will be able to work
around that, but this comment board is not the right place for this, so please
drop me an e-mail and I'll see what I can do for you.
Alexander Griesser on 2007-11-27 13:37:28 wrote:
I found a 4.8.01 version with a different patch (the link to the file for download is already patched). Please give it a try and report wheter it works better or not:

Guest on 2007-12-13 06:30:19 wrote:
I`m trying, for a while, to get working on 64 smp systems <BR />cisco vpnclient but I`m,- out of luck with slackware unoficial port slamd64,- and it works fine on Centos 5 Final <BR />thats with older version too i with patches or without patches even didn`t work with kernel <BR />and <BR />versions <BR /> vpnclient-linux-x86_64- <BR /> vpnclient-linux-x86_64- <BR /> vpnclient-linux-x86_64- <BR /><BR /><BR />all goes like mr guest said it compiles forks fine <BR />for a while, and latter when system gets a lilt more busy , I get Kernel crash with very similar symptoms <BR />like that kernel dump in Guests answer <BR /><BR />slamd (10.1.0) system Inetl Xeon (P4 prescot) single core 2 cpu <BR />centos 2 Opterons dual core <BR /><BR />where is the glue ? hardware ? red hat silently patched kernel themselfs ? <BR /><BR /><BR /><BR /><BR /> <BR />
Guest on 2007-12-15 13:11:57 wrote:
It worked on Ubuntu 7.10 x86_64

Excellent !

Guest on 2007-12-19 16:23:56 wrote:
I've got a similar issue; I get the exact same kernel panic. I've tried both 4.8.00 (patched) and 4.8.01 (unpatched) against my i686 arch 2.6.22 kernel, and I'm running into the same problem. I'll try the patched version above and see if that helps.

For now, I'm using the open source client (vpnc), but because of its inability to renew keys, I lose the connection for a few seconds every 8 hours while the service restarts itself to get a new key.

If you have any more information on this, please e-mail me, nathaniel.jacobsen at gmail.com
Guest on 2007-12-19 16:53:47 wrote:
One minor change to my post above, the current stable version of VPNC now supports rekeying, so I'm going to give up in the proprietary Cisco vpnclient for now.
Guest on 2007-12-21 11:30:22 wrote:
I upgraded to kernel on an athlon machine using vpnclient-linux-x86_64- When I attempt to connect, the client runs through all the available vpn connections, contacting the gateway and then \'locally terminates\' <BR />I also upgraded on a dual core to linux kernel and using vpnclient-linux-x86_64- with x86_64 patch; same effect. <BR />I can connect without problem using an old FC4 box.<BR />Thanks for your help.
Guest on 2007-12-25 01:25:37 wrote:
I have openSuSE 10.3 with kernel and the "vpnclient-linux-x86_64-" with patch "cisco_skbuff_offset.patch" worked perfectly. Not even a warning! Great job guys!

However, the vpnclient seems to only work when I use ethernet (eth0). When I use wireless (wlan0), the whole system freezes and I need to restart the laptop. Any ideas or patches to be able to use wlan0? For some reason, the vpnclient does not expect any internet connection being called "wlan", it only likes "eth".
Guest on 2007-12-25 20:27:27 wrote:
Guest on 2007-12-25 20:35:02 wrote:
I have FC7 on my T61 laptop with kernel. I am using \'vpnclient-linux-x86_64-4.8.01-0640-k9.tar.gz\'. When I have my wlan0 up then my laptop freezes the moment I bring up VPN. On my eth0 I do not experience the same problem. I would be interested in knowing if there is any solution for this. If there is anything I can try to debug this further I will be glad to hear and give it a go.
Guest on 2007-12-26 20:29:04 wrote:
Thanks a lot. Worked on a FEDORA 8 (
Guest on 2007-12-30 07:23:36 wrote:
Dear Alexander,
I wrote on 2007-12-25 01:25:37 cause my computer freezes when using the Cisco VPN client with the wireless "wlan0" connection. With "eth0" everything works great.

I have been doing some more testing and I suspect the problem might come from using the iwlwifi driver for the Intel 4965 wireless card. I have another laptop with openSuSE 10.3 but with an Intel 2915 card (which uses the ipw2200 driver), and the Cisco VPN client works well with "wlan0". Do you know of anybody else having this kind of problem? Do you know a way to tackle this problem?

Any kind of feedback would be very appreciated.
Guest on 2007-12-30 23:05:08 wrote:
I am using Arch Linux Kernel with vpnclient-linux-x86_64- and the skbuff patch and my system consistently crashes (freezes) after a couple minutes of use when the vpn is connected.

I've turned to using vpnc 0.5.1 and it's working great for me. In addition it also "feels" faster than the ciscovpn software FWIW...
Alexander Griesser on 2008-01-03 09:39:45 wrote:
Please let's discuss all these issues in the newly created forum:


This comment system is not suitable for debugging such stuff.
Guest on 2008-01-21 17:08:46 wrote:
Worked for me - Ubuntu 64bit
Guest on 2008-01-24 18:10:35 wrote:
what program do you need to run this, my computer does not recognize it...
Alexander Griesser on 2008-01-24 22:27:52 wrote:
Linux would be a good choice and a terminal emulator (e.g. xterm, konsole, whatever).

Please have a look at http://projects.tuxx-home.at/?id=cisco_vpn_client for further information about installation of the VPN client ant this patch.

BTW: As I already said above: Please use the forum to ask questions instead of posting them in here.
Guest on 2008-03-10 18:21:41 wrote:
Works on Ubuntu 7.10 for my system

$ uname -a
Linux mike-desktop 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 39
model name : AMD Athlon(tm) 64 Processor 4000+
stepping : 1
cpu MHz : 1000.000
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
bogomips : 2010.48
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Guest on 2008-03-13 06:51:56 wrote:
It works for me (Fedora 8, x86_64, kernel; the trick is that one has to apply this patch before applying the patch for 2.6.24
Guest on 2008-03-22 23:19:16 wrote:
Can this patch be used for Windows Vista 64 bit? Thank you.
Alexander Griesser on 2008-03-23 09:23:34 wrote:
Guest on 2008-04-25 13:47:58 wrote:
Failed on

make -C /lib/modules/ SUBDIRS=/root/vpnclient modules
make[1]: Entering directory `/usr/src/kernels/'
scripts/Makefile.build:46: *** CFLAGS was changed in "/root/vpnclient/Makefile". Fix it to use EXTRA_CFLAGS. Stop.
make[1]: *** [_module_/root/vpnclient] Error 2
make[1]: Leaving directory `/usr/src/kernels/'
make: *** [default] Error 2
Failed to make module "cisco_ipsec.ko".
Alexander Griesser on 2008-04-25 23:55:31 wrote:
I had a patch for this one lying around somewhere. Basically, you only need to change the word "CFLAGS" in /root/vpnclient/Makefile to EXTRA_CFLAGS and it should work.

Seems as if you've got a nasty compiler/automake system installed that is nitpicking on reusing the CFLAGS variable...
Guest on 2008-05-04 14:06:36 wrote:

the patch seems to work fine for me:
Had to apply the 2.6.24.final patch and the CFLAGS change in the Makefile as well.

homer:~> lsb_release -a
LSB Version: core-2.0-amd64:core-3.0-amd64:core- ...
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy

Thanks for the great work !

Guest on 2008-05-29 10:38:35 wrote:
Yep, this patch fixed the problem. First changed the CFLAGS ->EXTRA_CFLAGS and then added vpnclient-linux-2.6.24-final.diff patch. After these searched and found this page and it's patch, which finally made things to work.

Many thanks for the patch!

Env: Debian testing
Linux 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64 GNU/Linux
Guest on 2008-11-18 18:57:44 wrote:
works nicely on ubuntu 8.10 intrepid.

Your comment (HTML tags will be stripped !!):

To verify You are not a bot, type down text from this image.

Your try: