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.
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.
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.
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
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.