Bug 152000 - Cisco vpnclient Version 4.6.00 (0045)
Cisco vpnclient Version 4.6.00 (0045)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
There is no URL for this
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-23 23:57 EST by Neil O'Sullivan
Modified: 2015-01-04 17:18 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-26 21:22:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil O'Sullivan 2005-03-23 23:57:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2

Description of problem:
I have been using Cisco's vpn client for nearly 3 years under
RedHat 7.3 and it has worked absolutely reliably.  When migrating
to Fedora Core 3 I have had nothing but problems:

1.  compiling it (the upgraded GCC is much more picky about
function prototypes which are empty), but this was fixed by
a patch from a user on the internet.
2.  If the first connection fails (which in my case with FC3
has been EVERY case), retrying results in the following
messages which are not cleared even by a reboot:

Cisco Systems VPN Client Version 4.6.00 (0045)
Copyright (C) 1998-2004 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.6.10-1.770_FC3 #1 Thu Feb 24 14:00:06 EST 2005 i686
Config file directory: /etc/opt/cisco-vpnclient

Initializing the VPN connection.
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
^C^Fbind: Address already in use
bind: dst addr 0.0.0.0 port 500


Version-Release number of selected component (if applicable):
All version tested FAIL MISERABLY

How reproducible:
Always

Steps to Reproduce:
1.  Install Cisco VPN client Version 4.6.00 (0045)
2.  Try a connection (it either fails or the system freezes, much
more often the latter)
3.  In the 3 months that I've been trying to use FC3, I have been
absolutely and completely unable to connect.  
  

Actual Results:  First attempt fails (system hangs or connection rejected).  All subsequent
attempts ALWAYS result in the following output which, as far as I can tell,
takes DAYS to clear:

Cisco Systems VPN Client Version 4.6.00 (0045)
Copyright (C) 1998-2004 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.6.10-1.770_FC3 #1 Thu Feb 24 14:00:06 EST 2005 i686
Config file directory: /etc/opt/cisco-vpnclient

Initializing the VPN connection.
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
bind: Address already in use
bind: dst addr 0.0.0.0 port 500
^C^Fbind: Address already in use
bind: dst addr 0.0.0.0 port 500


Expected Results:  The connection should have completed without freezing the system to
the point where I have to power-cycle the laptop to get it back to
functioning order.  All subsequent attempts indicate that port 500
is busy.

Doing a 'sudo service vpn_client restart' has ABSOLUTELY NO EFFECT.
By default, my machine does NOT launch vpn_client at start-up; it
is initiated by me, the user.

How are we supposed to free this port for a reconnect attempt?

Not even a reboot clears it!  This is the sort of behavior one
would expect of Windows, except that rebooting Windows appears
to reset everything.


Additional info:

Personally, I would appreciate it if you could work with Cisco to
either verify that their software works with Fedore Core releases
or abandon the Fedora Core project altogether.  If all you are going
to do is break fundamental communication protocols with your core
releases, I will have to look to other competing releases such as
Gentoo, which I am told has no such problems (and keeps as up to
date as RedHat does).

I am giving this an initial severity of High because I am basically
unable to connect to work from home.  Rather than use my Linux
laptop, which I have been doing since 1998, I must use my Mac
laptop which has no such problems, but doesn't have the same
screen resolution as my laptop.

If I must revert back to RH7.3 just to be able to work from home,
then I might as well throw out this box and never use Linux again.

I work at Apple.  We have a relatively large Linux installation
for simulation purposes.  If you cannot improve the stability of
your releases, we'll migrate our several hundred servers to another
distribution in a blink of an eye.

I have significant input on that decision and I am completely
frustrated with the quality and reliability of Fedora.  We have
had similar issues with RH Enterprise (missing but required
DSO's, etc., which we must locate on the net and customize our
kickstart).  NOBODY has been happy with the results to date and
I have been suggesting we start evaluating other distro's because
RedHat appears to be losing its quality edge.  Without that, you
have nothing to differentiate yourself from any of the others.
Comment 1 Bill Nottingham 2005-03-24 15:20:08 EST
If a reboot doesn't clear the error, then the problem most likely lies on the
server end; there is probably some half-open connection that needs cleared, and
it doesn't want to reuse the connection. I don't have information on how to
clear the connection on that end, though... (it could be some saved config on
the client that it's trying to reuse as well.)

Ultimately, the issue lies with the Cisco module and how it interacts with the
kernel. The freezes that you mention are because of, and almost certainly *in*,
the Cisco module. As we don't have source for this, it's not something we can
debug, nor something we can fix.
Comment 2 Neil O'Sullivan 2005-03-25 01:51:32 EST
The fact that we had no such issues with RH7.3 but it occurs
reliably with FC3 is not necessarily indicative of a server-side
problem (although that remains a possibility, but the server-side 
software hasn't changed).

Working for a relatively large company yet using off-the-shelf
hardware (Dell Inspiron 8200) and finding that what used to work
with RedHat 7.3 fails reliably with FC3 tells me there are some
serious interaction incompatibilities between RedHat's FC3 and
Cisco's VPN software, which is a critical component to our daily
work.  Working with Cisco's VPN software is absolutely a re-
quirement for our environment.  If you cannot support that,
then your software is no longer an option.

For a Redhat employee to close this ticket without making any
effort to resolve the problem indicates to me that RedHat is
clearly not serious about releasing reliable software.  That
bodes ill both for my personal laptop but also for the hundreds
of RedHat 7.3 Linux boxes we have at work serving as compute
servers for simulations for which we are seeking future upgrades.

If RedHat is not serious about addressing this issue (which
the reply to this bug indicates), then please post clearly on
your web site that you do NOT support Cisco's VPN software and
have no plans to work with them to resolve any differences and
any problems with Cisco's VPN software will not be addressed by
RedHat.  That alone would have saved me weeks of wasted effort.

With that information, I can take that to management so we can
evaluate other distributions for future work and we will waste
no more time on RedHat evaluations.  The hundreds of installations
we have planned can be easily redirected to a vendor more interested
in resolving this issue.

While for the past 7 years I have been a RedHat devotee, the results
of this bug are indicative of an indifference to serious interoperability
to which I am unaccostomed.  But I have no problem loading other
products which will work better.  I don't care who gets paid, I just
want to make sure it works reliably, and the callous response to this
ticket indicates we should stop evaluating RedHat products and start
looking elsewhere.  I have been dragged into trying to fix issues with
RH Enterprise (mostly missing 32-bit standard libraries) which we have
had to search for from other vendors.  With Fedora Core 3 in such shoddy
shape and Enterprise effectively non-functional without human inter-
vention to add the missing libraries, we are unimpressed.

Personally I have been fighting the Windows battle for years.  The
response to this ticket is severely disheartening but if that is
official RedHat policy, then I expect this ticket is done and our
attempts at using RedHat products is terminated.  We will move our
hundreds of RedHat 7.3 compute servers to another distribution in
concert with our vendors, who regularly ask what platform, OS and
revision we want supported.

Thanks for your callous lack of support and indifference.

At least you were quick to say "No we don't support Cisco VPN
and if you need that, too bad."  At least we know where we
stand.

In the meantime, I will revert to RH7.3 until I find a distro
that works reliably with Cisco's VPN client.  The issues we
have encountered with RH Enterprise have been an endless
stream of show-stoppers (mostly missing 32-bit DSO's) so for 
the past 9 months we have been unable to move forward and
unable to recommend a reliable distro to our vendors.  They
have been pushing for RH Enterprise, but our experience has
been that this is not an option due to the frequently missing
32-bit versions of standard libraries.

We will indeed start evaluating other distro's first thing
tomorrow.
Comment 3 Bill Nottingham 2005-03-25 13:51:28 EST
The goals of Fedora are not, and have never been, to be a supported ISV
platform. See:
 
 http://fedora.redhat.com/about/rhel.html
 http://www.redhat.com/software/rhelorfedora/

for details. Problems with RHEL and third party software certainly will be
investigated; see:

 http://www.redhat.com/support/

for contact information. They'd be happy to help you, and certainly would be
interested in your comments about missing libraries.

As for the crash, it really has nothing to do with ipsec-tools (where this was
filed.)  Changing to kernel.

It does look like something changed in 2.6.10 that affected the VPN client; this
is not a change specific to Fedora. You might try the changes mentioned
at:
  http://www.ces.clemson.edu/linux/interceptor.c



 
Comment 4 Dave Jones 2005-03-26 21:22:34 EST
There is absolutely nothing I can do to fix problems in cisco's binary only
module (which has been proven to have issues with 2.6 kernels time after time).

You made the choice to use a binary only module, you get to live with the
problems associated with it.   As an alternative, I'd recommend you look into
vpnc, which is a completely userspace solution using the TUN/TAP driver.  It
does lack some features (notably rekeying after a few hours, and a few other
bits) but for the most part its reliable enough for day to day operation.

Fedora makes no attempt whatsoever to maintain any kind of backward compatable
kernel interface, so each rebase to a new kernel _will_ break this, and any
other binary only kernel module.  RHEL attempts to maintain a level of support
for one revision of the kernel over a longer period of time, however there is
still no guarantee that a binary module will continue work across two kernels
even if the interfaces remain the same. Bugs in other peoples drivers that we
can't fix are entirely out of our control.

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