Bug 479317 - networking fails after VPN connection since NetworkManager-vpnc.x86_64 1:0.7.0-1.svn13.fc10
networking fails after VPN connection since NetworkManager-vpnc.x86_64 1:0.7....
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager-vpnc (Show other bugs)
13
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
: Reopened
: 480556 482967 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-08 15:03 EST by Gax
Modified: 2011-06-27 10:05 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 10:05:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 621698 None None None Never

  None (edit)
Description Gax 2009-01-08 15:03:59 EST
Since the yum update that included
/var/log/yum.log:Jan 08 10:55:00 Updated: NetworkManager-glib.x86_64 1:0.7.0-1.git20090102.fc10                                                                                                               
/var/log/yum.log:Jan 08 10:55:09 Updated: NetworkManager.x86_64 1:0.7.0-1.git20090102.fc10                                                                                                                    
/var/log/yum.log:Jan 08 10:55:21 Updated: NetworkManager-vpnc.x86_64 1:0.7.0-1.svn13.fc10                                                                                                                     
/var/log/yum.log:Jan 08 10:55:25 Updated: NetworkManager-openvpn.x86_64 1:0.7.0-18.svn11.fc10                                                                                                                 
/var/log/yum.log:Jan 08 10:55:37 Updated: NetworkManager-gnome.x86_64 1:0.7.0-1.git20090102.fc10

I did not have networking over VPN, even tho the client is connected and authenticated to the gatway.

i had to revert to NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10.x86_64 to get things working again.
Comment 1 Gax 2009-01-08 15:18:31 EST
if it helps, here is my route during the problem:
$ route                                           
Kernel IP routing table                                            
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
XXX.XXX.XXX.X   YYY.YYY.YYY.Y   255.255.255.255 UGH   0      0        0 eth0 
192.168.151.0   *               255.255.255.0   U     0      0        0 tun0 
192.168.150.0   *               255.255.255.0   U     0      0        0 tun0 
192.168.152.0   *               255.255.255.0   U     0      0        0 tun0 
YYY.YYY.YYY.Y   *               255.255.252.0   U     1      0        0 eth0 
default         *               0.0.0.0         U     0      0        0 tun0

and when reverting to older NetworkManager, netowrking was fin with:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
XXX.XXX.XXX.X   YYY.YYY.YYY.Y   255.255.255.255 UGH   0      0        0 eth0
192.168.151.0   *               255.255.255.0   U     0      0        0 tun0
192.168.150.0   *               255.255.255.0   U     0      0        0 tun0
192.168.152.0   *               255.255.255.0   U     0      0        0 tun0
165.112.132.0   *               255.255.252.0   U     1      0        0 eth0
default         YYY.YYY.YYY.Y   0.0.0.0         UG    0      0        0 eth0

note the diffrecess in the last "default" lines
Comment 2 Matthew Farrellee 2009-01-10 00:30:27 EST
I can confirm this same problem with...

NetworkManager-glib-1:0.7.0-1.git20090102.fc10.i386
NetworkManager-1:0.7.0-1.git20090102.fc10.i386
NetworkManager-gnome-1:0.7.0-1.git20090102.fc10.i386
NetworkManager-vpnc-1:0.7.0-1.svn13.fc10

Success with...

NetworkManager-vpnc-0.7.0-0.11.svn4326.fc10.i386
NetworkManager-glib-0.7.0-0.12.svn4326.fc10.i386
NetworkManager-gnome-0.7.0-0.12.svn4326.fc10.i386
NetworkManager-0.7.0-0.12.svn4326.fc10.i386

Invariant...

vpnc-0.5.3-2.fc10.i386

netstat -rn output for:

failure...

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY 255.255.255.255 UGH       0 0          0 wlan0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0

success...

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY 255.255.255.255 UGH       0 0          0 wlan0
0.0.0.0         YYY.YYY.YYY.YYY 0.0.0.0         UG        0 0          0 wlan0

(not shown are the routes configured for the vpnc connection)
Comment 3 Dan Williams 2009-01-19 10:34:21 EST
So basically, new NetworkManager isn't routing *all* traffic over the VPN, whereas previous version did?
Comment 4 Dan Williams 2009-01-19 10:39:15 EST
Could I possibly get somebody to mail me the lines from /var/log/messages that NetworkManager spits out that contain the VPN settings?  I'm specifically interested in what the VPN gateway and static routes that NM gets back from NetworkManager-vpnc are.  They should look like:

Jan 19 10:21:38 localhost NetworkManager: <info>  VPN connection 'My VPN' (IP Config Get) reply received. 
Jan 19 10:21:38 localhost NetworkManager: <info>  VPN Gateway: 1.2.3.4 
Jan 19 10:21:38 localhost NetworkManager: <info>  Tunnel Device: tun0 
Jan 19 10:21:38 localhost NetworkManager: <info>  Internal IP4 Address: 10.16.10.131 
Jan 19 10:21:38 localhost NetworkManager: <info>  Internal IP4 Prefix: 23 
Jan 19 10:21:38 localhost NetworkManager: <info>  Internal IP4 Point-to-Point Address: 10.16.10.131 
Jan 19 10:21:38 localhost NetworkManager: <info>  Maximum Segment Size (MSS): 0 
Jan 19 10:21:38 localhost NetworkManager: <info>  Static Route: 10.0.0.0/8   Next Hop: 10.0.0.0 
Jan 19 10:21:38 localhost NetworkManager: <info>  Static Route: 172.16.0.0/17   Next Hop: 172.16.0.0 
Jan 19 10:21:38 localhost NetworkManager: <info>  Static Route: 192.168.0.0/17   Next Hop: 192.168.0.0 
Jan 19 10:21:38 localhost NetworkManager: <info>  Internal IP4 DNS: 10.16.255.2 
Jan 19 10:21:38 localhost NetworkManager: <info>  Internal IP4 DNS: 10.16.255.3 
Jan 19 10:21:38 localhost NetworkManager: <info>  DNS Domain: '(none)'
Comment 5 David Woodhouse 2009-01-19 14:02:31 EST
*** Bug 480556 has been marked as a duplicate of this bug. ***
Comment 6 David Woodhouse 2009-01-20 02:50:14 EST
(In reply to comment #3)
> So basically, new NetworkManager isn't routing *all* traffic over the VPN,
> whereas previous version did?

Er, no. The other way round, I think...



(In reply to comment #1)
> if it helps, here is my route during the problem:
> default         *               0.0.0.0         U     0      0        0 tun0
> 
> and when reverting to older NetworkManager, netowrking was fin with:
> default         YYY.YYY.YYY.Y   0.0.0.0         UG    0      0        0 eth0



(In reply to comment #2)
> failure...
> 0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0
> 
> success...
> 0.0.0.0         YYY.YYY.YYY.YYY 0.0.0.0         UG        0 0          0 wlan0
Comment 7 Dan Williams 2009-01-20 10:44:47 EST
Right, misread the route dumps.  Will work on how to transparently transition to 0.7.1 here.

Instead of the obscure behavior before where, if the VPN server returned static routes *or* the user entered static routes in the conneciton editor, NM would never select the VPN as the default route, NM will now only make a connection the default route if the checkbox "Use this connection only for resources on its network" is checked in the Routes dialog in the connection editor for that connection.  This was added to allow more flexibility for users who, for example, had two ethernet NICs and wanted a specific one to be the default route, or to allow people to micromanage which connections got the default route and which didn't irregardless of what the VPN server sent.  There were many requests for this both on RH and upstream bugzillas, so it was added to 0.7.1.

What's missing is a transparent upgrade path to preserve user intent from before, where the user intent wasn't actually able to be expressed.
Comment 8 Dan Williams 2009-01-20 10:46:31 EST
(In reply to comment #7)
> never select the VPN as the default route, NM will now only make a connection
> the default route if the checkbox "Use this connection only for resources on
> its network" is checked in the Routes dialog in the connection editor for that

Correction: the above is reversed.  NM will only make a connection the default route if the checkbox "Use this connection only for resources on its network" is NOT checked.  That box must be unchecked (unchecked is the default) for any connection to get the default route.
Comment 9 David Woodhouse 2009-01-20 16:41:01 EST

(In reply to comment #7)
> Instead of the obscure behavior before where, if the VPN server returned static
> routes *or* the user entered static routes in the conneciton editor, NM would
> never select the VPN as the default route,

Er, wtf? The default route isn't special. It's just another normal route, with a small netmask. If I _give_ you a list of routes in my configuration, I most certainly do _not_ want you to make up another route and add it to my list. So this 'obscure' behaviour of which you speak is the _only_ behaviour which makes sense, surely? If I _wanted_ a route with a /0 netmask, I'd have included it in my list.

> This was added to allow more flexibility for users who, for
> example, had two ethernet NICs and wanted a specific one to be the default
> route, or to allow people to micromanage which connections got the default
> route and which didn't irregardless of what the VPN server sent. 

OK, now if we stop thinking of the 'default' route as special, and rephrase that accordingly...

We want to cope with people who have more than one connection, and both connections claim some route or other. And the user wants to control _which_ of the connections actually _gets_ the route to that particular range of addresses.

My approach to solving this would be a list of routes which are _deleted_ from those requested by the server. So if you know your VPN is going to request 192.168.0.0/16 and 10.0.0.0/8, you could say "actually, don't let it have 192.168.0.0/16". And that approach works nicely for the default route _too_.
Comment 10 Matthew Farrellee 2009-01-20 20:05:04 EST
(In reply to comment #4)

My output is the same as yours modulo the fake gateway and the IP4 address.

The "Ignore automatically obtained routes" and "Use this connection only for resources on its network" options seem to have no effect at all.

I tried "VPN Connections" -> "Configure VPN" -> "Wireless" to make my network connection "Use this connection only for resources on its network" with little luck. I actually managed to get NM to crash if I add a route, specify only the address and hit "Ok" with a netmask of 0, only to have NM crash.
Comment 11 Dan Williams 2009-01-20 23:15:08 EST
(In reply to comment #9)
> 
> (In reply to comment #7)
> > Instead of the obscure behavior before where, if the VPN server returned static
> > routes *or* the user entered static routes in the conneciton editor, NM would
> > never select the VPN as the default route,
> 
> Er, wtf? The default route isn't special. It's just another normal route, with
> a small netmask. If I _give_ you a list of routes in my configuration, I most
> certainly do _not_ want you to make up another route and add it to my list. So
> this 'obscure' behaviour of which you speak is the _only_ behaviour which makes
> sense, surely? If I _wanted_ a route with a /0 netmask, I'd have included it in
> my list.

Nobody actually does that, yet most VPNs (including the Cisco VPN client) actively try to ensure that the VPN is where your packets go.  Seriously.  I've never seen a VPN implementation run by anyone other than interested users actually push a route with a /0.  That's just not how things work in the real world.

Furthermore, some VPNs don't have the capability to push routes down to the client (PPTP) and thus if you want to route certain subnets over the VPN specifically, but not direct all your traffic over it, you need to manually enter some routes.  However, just because you've entered some routes does not necessarily mean you want only those routes to go over the VPN

Imagine you have eth0, and you normally route 192.168.1.0/24 and 192.168.2.0/24 over it.  However, when you're on VPN, you want traffic for everything *except* 192.168.1.0/24 to go over the VPN.  So you enter 192.168.2.0/24 into the "Routes" dialog in the connection editor, but you do *not* check "Use this connection only...".  In the correct implementation (and NM does not do this yet, but it will), the VPN gets /0 *and* 192.168.2.0/24, while only 192.168.1.0/24 is routed over eth0.  Contrived, but possible; say you are testing a mirror of whatever is on the VPN 192.168.2.0/24 on your local net because you're a sysadmin.  It's also possible with the current Fedora ifcfg scripts (set up a routes-eth0, routes-whatever and set GATEWAYDEV=whatever).

> > This was added to allow more flexibility for users who, for
> > example, had two ethernet NICs and wanted a specific one to be the default
> > route, or to allow people to micromanage which connections got the default
> > route and which didn't irregardless of what the VPN server sent. 
> 
> OK, now if we stop thinking of the 'default' route as special, and rephrase
> that accordingly...

Except that it *is* special.  It has properties that other routes don't, precisely because no other route can be lower than it, and thus after the default route, all route processing stops.  It's like a mail filter at the bottom of your filter list that dumps everything not already filtered into the trash; if it wasn't there, everything that didn't match would still be cluttering your inbox.

> We want to cope with people who have more than one connection, and both
> connections claim some route or other. And the user wants to control _which_ of
> the connections actually _gets_ the route to that particular range of
> addresses.

Yes, that's one of the things we want to do.  However, almost *never* is a /0 returned from either a DHCP server or a VPN, so we simply don't have the information to make that decision for the default route.  Thus it has to be either inferred, or explicitly stated by the user.

> My approach to solving this would be a list of routes which are _deleted_ from
> those requested by the server. So if you know your VPN is going to request
> 192.168.0.0/16 and 10.0.0.0/8, you could say "actually, don't let it have
> 192.168.0.0/16". And that approach works nicely for the default route _too_.

Could work, however you never know exactly what routes you're going to get from the DHCP server or the VPN server beforehand when you're configuring the connection if you do so manually, thus having a "if the server sends this route, ignore it" sort of thing doesn't work well.  However, if you're talking about *internally* to NetworkManager as an implementation detail of how to processing routing from multiple sources, that could be part of the solution.
Comment 12 David Woodhouse 2009-01-21 22:53:58 EST
Another option would be to assign priorities to each connection -- which could be directly translated into route metrics. That doesn't necessarily cover every use case though.
Comment 13 Matthew Farrellee 2009-01-21 23:34:45 EST
(In reply to comment #12)

For me and likely anyone else who's hit by this issue, we're just hoping our use case (that we had before) is expressible soon.

Alternatively, we can find a way to make the new package update widgets ignore NM packages.

I have a single interface, wlan0, everything flows through it. I start up a VPN interface, tun0, that has specific routes associated with it, 10/8 192.168.21/24. When the VPN is running I want it to handle only traffic for the routes I've configured. Everything else should go through the original interface.

This is simpler than what is being discussed. There isn't a 3rd interface with overlapping routes.

A priority scheme seems useful and reasonable. You'll have to do some clever work to split overlapping routes.
Comment 14 Dan Williams 2009-01-22 10:54:27 EST
(In reply to comment #13)
> (In reply to comment #12)
> 
> For me and likely anyone else who's hit by this issue, we're just hoping our
> use case (that we had before) is expressible soon.

Your use-case is the normal one for most of the Red Hat users I know.  It's completely expressable by checking the "Only use this connection for resources on its network" checkbox in the routes dialog of the IP4 tab for that VPN connection.  You can check that box now and get your desired behavior.

What's actually broken is the upgrade to svn4326 to git20090102.  Behavior in svn4326 used a somewhat broken heuristic to automatically "check the box" so to speak, but since that heuristic is broken, it was moved to an explicit user choice.  However, git20090102 doesn't have compatibility code to automatically check the box on upgrade.  You can check it yourself however.

> Alternatively, we can find a way to make the new package update widgets ignore
> NM packages.
> 
> I have a single interface, wlan0, everything flows through it. I start up a VPN
> interface, tun0, that has specific routes associated with it, 10/8
> 192.168.21/24. When the VPN is running I want it to handle only traffic for the
> routes I've configured. Everything else should go through the original
> interface.

You can get this capability by checking the "Use this connection only for resources on its network", and then manually entering your desired routes into the dialog.  Note that the VPN server will *also* send a set of routes which get applied (in addition to ones you've manually entered) unless you check the "Ignore automatically provided routes" checkbox.
Comment 15 Matthew Farrellee 2009-01-22 11:20:50 EST
(In reply to comment #14)

> You can get this capability by checking the "Use this connection only for
> resources on its network", and then manually entering your desired routes into
> the dialog.  Note that the VPN server will *also* send a set of routes which
> get applied (in addition to ones you've manually entered) unless you check the
> "Ignore automatically provided routes" checkbox.

I tried that, back in comment #10, with no luck.

I updated NM, service restarted it, edited the VPN to "Use this connection only for resources on its network" and then connected to the VPN. A /0 rule was still created for tun0.
Comment 16 Dimitris 2009-01-24 04:24:12 EST
Hi,

I am suffering the same issue as the submitter, and enabled the checkbox to fix it as suggested. 

I am really puzzled how on earth I got a default route pointing to an internal  ip (that of the br0 interface) of my openvpn gateway since it is not being pushed. As a result I lost connectivity to everything other than internal and had to fix it manually. I am using openvpn in windows also and I never got similar issue.

I think the new behavior is trying to be a little smarted than it should. I can understand the use cases that could make such a feature useable for NetworkManager, but I still cannot understand what I am seeing.
Comment 17 Dan Williams 2009-02-03 14:38:57 EST
*** Bug 482967 has been marked as a duplicate of this bug. ***
Comment 18 Dan Williams 2009-02-03 14:43:15 EST
The next update will automatically check the "Use this connection only for resources..." box on upgrade if there are manual routes assigned, which was the default behavior for NM 0.6 and earlier NM 0.7 builds up to 2008-10-10.  Cases where the server passed static routes and the user wants only those routes used for the VPN connection will need to check the box manually.
Comment 19 Matthew Farrellee 2009-02-21 09:57:31 EST
I can confirm that the bug I was running into appears to be caused by having multiple connections setup as the default interface, e.g. setup *without* "Use this connection only for resources on its network" checked.
Comment 20 Heather Keen 2009-02-25 12:40:48 EST
I have a vpn connection that since this software release will now only work successfully if I connect to it via the vpnc command line.  When I connect via the NetworkManager (which as exactly the same simple config) I am unable to connect to/ping any hosts at the other end. I've tried all combinations of the routes tick boxes.

netstat -rn differs only slightly:

via NM:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
XX.XXX.X.XX     10.0.11.1       255.255.255.255 UGH       0 0          0 eth0
192.168.140.0   0.0.0.0         255.255.255.224 U         0 0          0 tun0
10.0.11.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0

with command line:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
XX.XXX.X.XX     10.0.11.1       255.255.255.255 UGH    1500 0          0 eth0
192.168.140.0   0.0.0.0         255.255.255.224 U         0 0          0 tun0
10.0.11.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tun0

I can provide the verbosity from /var/log/messages if required.
Comment 21 Dan Williams 2009-11-06 01:55:46 EST
Is this still an issue with latest NetworkManager and NM-vpnc packages from updates?  Also try:

https://admin.fedoraproject.org/updates/F10/FEDORA-2009-10546
Comment 22 David Woodhouse 2009-11-10 21:25:16 EST
There's still no option to obey what we're told by the VPN server. Sometimes it wants us to add the default route; sometimes it doesn't.

In the case of the berkeley.edu VPN, the user actually gets to choose as they're logging in. They enter VPN type, username and password. And when they're running from the command line using the normal vpnc-script, everything works fine and they get what they asked for. But when they're using NetworkManager, its hardcoded setting overrides the server's indication of whether to set the default route or not.
Comment 23 Bug Zapper 2009-11-18 04:44:54 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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
Comment 24 Bug Zapper 2009-12-18 02:32:56 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.
Comment 25 David Woodhouse 2010-01-04 08:06:42 EST
Comment #22 still applies in Fedora 12. There's still no option to make NetworkManager just do what the VPN server tells it to.
Comment 26 Richard Burnison 2010-05-12 21:04:02 EDT
The scenario noted in comment #13 seems to be fixed in release 2.git20100411.fc12, currently in updates-testing.
Comment 27 Richard Burnison 2010-05-13 09:15:22 EDT
To clarify my previous comment, I was experiencing the same symptoms with NetworkManager-openvpn and forgot to properly cross-reference this bug's listed component.

My comment was not in regard to NetworkManager-vpnc and should be disregarded.
Comment 28 David Woodhouse 2010-06-15 17:04:58 EDT
I filed https://bugzilla.gnome.org/show_bug.cgi?id=621698 -- thought I'd done so a long time ago, in fact, but if so I can't find it.
Comment 29 David Woodhouse 2011-05-13 19:15:13 EDT
This is now fixed in F14 and F15 for OpenConnect, but not yet for vpnc (see my latest comment in the GNOME bug).
Comment 30 Bug Zapper 2011-06-02 14:18:31 EDT
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
Comment 31 Bug Zapper 2011-06-27 10:05:00 EDT
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.

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