Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 620625 - pptp stopped working
pptp stopped working
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pptp (Show other bugs)
13
i686 Linux
low Severity high
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-02 23:14 EDT by yyetim
Modified: 2011-06-29 08:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-29 08:37:57 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)
Settings for failed connection (847.41 KB, image/png)
2010-08-02 23:14 EDT, yyetim
no flags Details

  None (edit)
Description yyetim 2010-08-02 23:14:23 EDT
Created attachment 436184 [details]
Settings for failed connection

Description of problem:


Version-Release number of selected component (if applicable):
pptp-1.7.2-9.fc13.i686
NetworkManager-pptp-0.8.0-1.git20100411.fc13.i686

How reproducible:
Always

Steps to Reproduce:
1. Create new vpn connection with pptp
2. Enter similar settings as in the attachment: 
3. Reboot, try connecting from network-manager-applet by clicking the connection.
  
Actual results:
Waits and /var/log/messages has:
LCP: timeout sending Config-Requests
Connection terminated.
VPN plugin failed: 1
short read (-1): Input/output error

Expected results:
Connected

Additional info:
Same settings work on a different distro (and used to work on Fedora)
Comment 1 Paul Howarth 2010-08-16 02:59:12 EDT
What has changed since this last worked for you?

When you say the same settings work on a different distro, is that on the same machine on the same network?

You may want to look at the PPTP problem diagnostic page:
http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_timeout
Comment 2 yyetim 2010-08-16 08:22:19 EDT
Yes, same machine with dual boot. I am posting a longer output below:


Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> Starting VPN service 'org.freedesktop.NetworkManager.pptp'...
Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 3308
Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN service 'org.freedesktop.NetworkManager.pptp' appeared, activating connections
Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state changed: 3
Aug 16 08:20:53 yyetim-laptop NetworkManager[1180]: <info> VPN connection 'VPN connection 1' (Connect) reply received.
Aug 16 08:20:53 yyetim-laptop pppd[3310]: Warning: can't open options file /root/.ppprc: Permission denied
Aug 16 08:20:53 yyetim-laptop pppd[3310]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
Aug 16 08:20:53 yyetim-laptop pppd[3310]: pppd 2.4.5 started by root, uid 0
Aug 16 08:20:53 yyetim-laptop pppd[3310]: Using interface ppp0
Aug 16 08:20:53 yyetim-laptop pppd[3310]: Connect: ppp0 <--> /dev/pts/1
Aug 16 08:20:53 yyetim-laptop pptp[3312]: nm-pptp-service-3308 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 1 'Start-Control-Connection-Request'
Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:754]: Received Start Control Connection Reply
Aug 16 08:20:53 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:788]: Client connection established.
Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 7 'Outgoing-Call-Request'
Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:873]: Received Outgoing Call Reply.
Aug 16 08:20:54 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_disp:pptp_ctrl.c:912]: Outgoing call established (call ID 0, peer's call ID 15620).
Aug 16 08:21:24 yyetim-laptop pppd[3310]: LCP: timeout sending Config-Requests
Aug 16 08:21:24 yyetim-laptop pppd[3310]: Connection terminated.
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1
Aug 16 08:21:24 yyetim-laptop pppd[3310]: Modem hangup
Aug 16 08:21:24 yyetim-laptop pptp[3312]: nm-pptp-service-3308 warn[decaps_hdlc:pptp_gre.c:204]: short read (-1): Input/output error
Aug 16 08:21:24 yyetim-laptop pptp[3312]: nm-pptp-service-3308 warn[decaps_hdlc:pptp_gre.c:216]: pppd may have shutdown, see pppd log
Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[callmgr_main:pptp_callmgr.c:235]: Closing connection (unhandled)
Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[ctrlp_rep:pptp_ctrl.c:254]: Sent control packet type is 12 'Call-Clear-Request'
Aug 16 08:21:24 yyetim-laptop pptp[3318]: nm-pptp-service-3308 log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1
Aug 16 08:21:24 yyetim-laptop pppd[3310]: Exit.
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> VPN plugin failed: 1
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state changed: 6
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> VPN plugin state change reason: 0
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <warn> error disconnecting VPN: Could not process the request because no VPN connection was active.
Aug 16 08:21:24 yyetim-laptop NetworkManager[1180]: <info> Policy set 'System eth0' (eth0) as default for IPv4 routing and DNS.
Comment 3 yyetim 2010-08-16 08:23:41 EDT
Nothing has changed since it last worked. But I think Fedora 13 updated the pptp package, that might be the problem.
Comment 4 Paul Howarth 2010-08-16 08:57:59 EDT
If you revert to an older version of pptp, does it work?

You might try "yum downgrade pptp", or if that doesn't help, you can find older versions of pptp here:

http://koji.fedoraproject.org/koji/packageinfo?packageID=3515
Comment 5 yyetim 2010-08-16 18:34:22 EDT
I tried downgrading. It still doesn't work. I updated it again, and tried the manual debug commands as explained on the ptppclient sourceforge page but it doesn't give me any additional information. It keeps sending LCP requests, then gives up. Below is the output (changed personal stuff to my_...):

pppd options in effect:
debug		# (from command line)
nodetach		# (from command line)
logfd 2		# (from command line)
dump		# (from command line)
noauth		# (from /etc/ppp/options.pptp)
refuse-pap		# (from /etc/ppp/options.pptp)
refuse-chap		# (from /etc/ppp/options.pptp)
refuse-mschap		# (from /etc/ppp/options.pptp)
refuse-eap		# (from /etc/ppp/options.pptp)
name There\\my_username		# (from /etc/ppp/peers/there)
remotename PPTP		# (from /etc/ppp/peers/there)
		# (from /etc/ppp/options.pptp)
pty pptp my_server --nolaunchpppd		# (from /etc/ppp/peers/there)
ipparam there		# (from /etc/ppp/peers/there)
nobsdcomp		# (from /etc/ppp/options.pptp)
nodeflate		# (from /etc/ppp/options.pptp)
require-mppe-128		# (from /etc/ppp/peers/there)
using channel 9
Using interface ppp0
Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d71991c> <pcomp> <accomp>]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
Waiting for 1 child processes...
  script pptp my_server --nolaunchpppd, pid 2852
Script pptp my_server --nolaunchpppd finished (pid 2852), status = 0x0
Comment 6 yyetim 2010-08-16 18:47:36 EDT
    vpn2.Princeton.EDU > ool-457ea4a2.dyn.optonline.net: GREv1, Flags [key present, sequence# present, ack present], call 0, seq 2, ack 1, length 26
	LCP, Conf-Reject (0x04), id 1, length 8
	encoded length 6 (=Option(s) length 2)
	0x0000:  c021 0401 0006
	  ACFC Option (0x08), length 2: 
18:46:44.189072 IP (tos 0x0, ttl 64, id 16407, offset 0, flags [DF], proto GRE (47), length 56)




This is the tcpdump package
Comment 7 yyetim 2010-08-16 21:43:44 EDT
I found the problem. When I create a wireless connection using "Create New Wireless Network" in the network manager, PPTP stops working. If I remove the connection I created and reboot, PPTP starts working again.
Comment 8 Paul Howarth 2010-08-17 09:49:01 EDT
It's probably a routing problem then. See what your routes look like before/after creating your wireless connection:

$ netstat -rn

It's possible that the wireless connection is replacing the route that you use to communicate with the PPTP server.
Comment 9 yyetim 2010-08-19 17:46:28 EDT
Here are some steps and outputs:

1) Connect to existing wireless network -- Successful 
2) Connect to PPTP server -- Successful
3) Disconnect from the PPTP server -- Successful
4) Create "New Wireless Connection" from Network manager -- Successful
5) Remove "New Wireless Connection" from Network Manager -- Successful
Output of `netstat -rn`:
[yyetim@yyetim-laptop ~]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
6) Connect to existing wireless network -- Successful
Output of `netstat -rn`:
[yyetim@yyetim-laptop ~]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
140.180.0.0     0.0.0.0         255.255.192.0   U         0 0          0 wlan0
0.0.0.0         140.180.0.1     0.0.0.0         UG        0 0          0 wlan0
7) Connect to PPTP server -- UNSUCCESSFUL
Output of `netstat -rn`:
[yyetim@yyetim-laptop ~]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  140.180.0.1     255.255.255.255 UGH       0 0          0 wlan0
140.180.0.0     0.0.0.0         255.255.192.0   U         0 0          0 wlan0
0.0.0.0         140.180.0.1     0.0.0.0         UG        0 0          0 wlan0


Even if I connect to the internet using ethernet, it still fails at the same step. What can be the remnants of a deleted "New Wireless Connection"??
Comment 10 Paul Howarth 2010-08-20 02:37:52 EDT
(In reply to comment #9)
> Here are some steps and outputs:
> 
> 1) Connect to existing wireless network -- Successful 

What did "netstat -rn" look like at this point?

> 2) Connect to PPTP server -- Successful

What did "netstat -rn" look like at this point?

> 3) Disconnect from the PPTP server -- Successful

What did "netstat -rn" look like at this point?

> 4) Create "New Wireless Connection" from Network manager -- Successful

What did "netstat -rn" look like at this point?

> 5) Remove "New Wireless Connection" from Network Manager -- Successful
> Output of `netstat -rn`:
> [yyetim@yyetim-laptop ~]$ netstat -rn
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 6) Connect to existing wireless network -- Successful
> Output of `netstat -rn`:
> [yyetim@yyetim-laptop ~]$ netstat -rn
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 140.180.0.0     0.0.0.0         255.255.192.0   U         0 0          0 wlan0
> 0.0.0.0         140.180.0.1     0.0.0.0         UG        0 0          0 wlan0

Can you ping 128.112.64.210 at this point?

> 7) Connect to PPTP server -- UNSUCCESSFUL
> Output of `netstat -rn`:
> [yyetim@yyetim-laptop ~]$ netstat -rn
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  140.180.0.1     255.255.255.255 UGH       0 0          0 wlan0
> 140.180.0.0     0.0.0.0         255.255.192.0   U         0 0          0 wlan0
> 0.0.0.0         140.180.0.1     0.0.0.0         UG        0 0          0 wlan0

Can you ping 128.112.64.210 at this point?

> Even if I connect to the internet using ethernet, it still fails at the same
> step. What can be the remnants of a deleted "New Wireless Connection"??

There is still a host route to the PPTP server set up at this point (the additional line in the netstat output). You might try deleting it and seeing if that helps (need to be root for that):

# ip route del 128.112.64.210/32 via 140.180.0.1 dev wlan0
Comment 11 yyetim 2010-08-20 18:38:00 EDT
;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.
1) Connected to eth0:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
2) Connected to PPTP:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
128.112.64.210  0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
3) Disconnected from PPTP
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
4) Reconnected/disconnected to/from PPTP (same as 2 and 3)
5) Created New Wireless Network:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
10.42.43.0      0.0.0.0         255.255.255.0   U         0 0          0 wlan0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
6) Disconnected from New Wireless Network
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
7) Tried to connect to PTPP -- UNSUCCESSFUL:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
8) Executed ip route del 128.112.64.210/32 via 69.126.164.1 dev eth0:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
9) Tried to connect to PPTP -- UNSUCCESSFUL:
128.112.64.56   69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0
Comment 12 Paul Howarth 2010-08-23 09:49:04 EDT
(In reply to comment #11)
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> ;; If you want to create a file, visit that file with C-x C-f,
> ;; then enter the text in that file's own buffer.
> 1) Connected to eth0:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

OK, standard set up with default route via 69.126.164.1 on eth0.

> 2) Connected to PPTP:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 128.112.64.210  0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0

As before, but with host route to PPTP server 128.112.64.210 (via eth0) added twice and default route switched to the tunnel. pptp will have added one of these host routes (new in 1.7.2) and NetworkManager-pptp probably added the other.

> 3) Disconnected from PPTP
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

Back to original state, except that one of the host routes has remained. This will be the one that pptp added.

> 4) Reconnected/disconnected to/from PPTP (same as 2 and 3)
> 5) Created New Wireless Network:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 10.42.43.0      0.0.0.0         255.255.255.0   U         0 0          0 wlan0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

No difference here except that you've added a new route to 10.42.43.0/24 via  wlan0.

> 6) Disconnected from New Wireless Network
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

Back to same state as (3).

> 7) Tried to connect to PTPP -- UNSUCCESSFUL:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 128.112.64.210  69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

No change.

> 8) Executed ip route del 128.112.64.210/32 via 69.126.164.1 dev eth0:
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

Back to same state as (1).

> 9) Tried to connect to PPTP -- UNSUCCESSFUL:
> 128.112.64.56   69.126.164.1    255.255.255.255 UGH       0 0          0 eth0
> 69.126.164.0    0.0.0.0         255.255.252.0   U         0 0          0 eth0
> 0.0.0.0         69.126.164.1    0.0.0.0         UG        0 0          0 eth0

Hmm, doesn't look like a routing problem then. Perhaps a firewall issue? If you disable the firewall ("service ipstables stop") prior to trying to connect, does that help?
Comment 13 yyetim 2010-08-23 11:12:03 EDT
I'll try that too but I don't think that's the problem. Why would the vpn server be sending me LCP-Reject packages if the problem is the iptables?
Comment 14 Paul Howarth 2010-08-23 11:24:47 EDT
Ah yes, I missed that in comment #6 although I'd have expected to see it in comment #5 too.

I was trying to think of something that might have been changed as a result of adding/removing a connection in NM...
Comment 15 Bug Zapper 2011-06-01 08:14:24 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 16 Bug Zapper 2011-06-29 08:37:57 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.