(In reply to comment #0)
> mac80211-phy0: failed to remove key (0, 00:1e:2a:52:dc:d2) from hardware (-22)
> wlan0: deauthenticating from 00:1e:2a:52:dc:d2 by local choice (reason=3)    

These messages are clearly not enaught to tell where the problem is. I will prepare kernel which print more verbose debug messages.

Run this kernel and attach dmesg when network disconnects:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2346530

The output from dmesg after the wireless disconnected and I manually reconnected:

Monitor-Mwait will be used to enter C-2 state
Monitor-Mwait will be used to enter C-3 state
mac80211-phy0: failed to remove key (0, 00:1e:2a:52:dc:d2) from hardware (-22)
phy0: Removed STA 00:1e:2a:52:dc:d2
phy0: Destroyed STA 00:1e:2a:52:dc:d2
wlan0: deauthenticating from 00:1e:2a:52:dc:d2 by local choice (reason=3)
phy0: device now idle
phy0: device no longer idle - scanning
phy0: device now idle
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: US
cfg80211: Regulatory domain changed to country: US
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
    (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
phy0: device no longer idle - scanning
phy0: device now idle
phy0: device no longer idle - scanning
wlan0: deauthenticating from 00:1e:2a:52:dc:d2 by local choice (reason=3)
wlan0: authenticate with 00:1e:2a:52:dc:d2 (try 1)
wlan0: authenticated
phy0: device now idle
phy0: device no longer idle - working
wlan0: associate with 00:1e:2a:52:dc:d2 (try 1)
wlan0: RX AssocResp from 00:1e:2a:52:dc:d2 (capab=0x411 status=0 aid=1)
wlan0: associated
phy0: Allocated STA 00:1e:2a:52:dc:d2
phy0: Inserted STA 00:1e:2a:52:dc:d2

In the hours before the wireless disconnected, this output appears in dmesg:

wlan0: detected beacon loss from AP - sending probe request
wlan0: detected beacon loss from AP - sending probe request
wlan0: detected beacon loss from AP - sending probe request
wlan0: detected beacon loss from AP - sending probe request
wlan0: detected beacon loss from AP - sending probe request
wlan0: detected beacon loss from AP - sending probe request

To clarify, several hours elapsed between the last 'sending probe request' message and when the wireless disconnected.

Please provide full dmesg, not only fragments (preferred as attachment of MIME Type: text/plain).

Created attachment 434134 [details]
dmesg output

I think you are using some wireless authentication method with dynamic key generation. For some unknown reason driver is unable to remove old key from hardware, and because of that wpa_supplicant disconnects. If suppose is correct, disabling hardware cryptography offload should prevent problem. Please check if swcrypto50=1 option helps:

$ echo options iwlagn swcrypto50=1 >> /etc/modprobe.d/options
$ rmmod iwlagn
$ modprobe iwlagn

Created attachment 434689 [details]
dmesg output

After adding the swcrypto50=1 option, I had another disconnect and I had to manually reconnect. Attached is the latest dmesg output from before manually reconnecting.

As far as I can see  kernel/driver does not disconnect by itself, disconnect request comes for outside (NetworkManager or wpa_supplicant).

Please do:

* Disable network daemons
> [root@dhcp-27-172 ~]# /etc/init.d/NetworkManager stop
> Stopping NetworkManager daemon:                            [  OK  ]
> [root@dhcp-27-172 ~]# /etc/init.d/wpa_supplicant stop
> Stopping wpa_supplicant:                                   [  OK  ]

* Change below line in /etc/sysconfig/wpa_supplicant file to have verbose debug in "messages" file
> OTHER_ARGS="-u -f /var/log/messages -dd -P /var/run/wpa_supplicant.pid"

* Change below line in /etc/init.d/NetworkManager file to increase verbosity
> daemon --pidfile $pidfile --check $servicename $processname --pid-file=$pidfile --log-level=DEBUG

* Change below line in /etc/rsyslog.conf file to log all kernel messages to "/var/log/messages"
> kern.*;*.info;mail.none;authpriv.none;cron.none                /var/log/messages

* Restart syslog deamon
> [root@dhcp-27-172 ~]# /etc/init.d/rsyslog restart

* Save "messages" file (just for case you will need it) and clean it  
> [root@dhcp-27-172 ~]# cp /var/log/messages /var/log/messages.old 
> [root@dhcp-27-172 log]# echo > /var/log/messages

* Run network daemons again
> [root@dhcp-27-172 ~]# /etc/init.d/wpa_supplicant start
> Starting wpa_supplicant: /etc/wpa_supplicant/wpa_supplicant[  OK  ] 
> [root@dhcp-27-172 ~]# /etc/init.d/NetworkManager start
> Setting network parameters...                              [  OK  ]
> Starting NetworkManager daemon:                            [  OK  ]

When network disconnects, attach /var/log/messages file. If file will be big you can compress it, or cut it and attach only the latest (valuable) messages.

Created attachment 437589 [details]
/var/log/messages with debug info

> Aug  9 08:02:23 laptop dhclient[10138]: DHCPREQUEST on wlan0 to 192.168.1.1 port 67
> Aug  9 08:02:23 laptop dhclient[10138]: DHCPNAK from 192.168.1.1
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> (wlan0): DHCPv4 state changed reboot -> expire
> Aug  9 08:02:23 laptop NetworkManager[10134]: <debug> [1281355343.70085] [nm-device.c:1373] dhcp_state_changed(): (wlan0): new DHCPv4 client state 8
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> (wlan0): device state change: 8 -> 9 (reason 6)
> Aug  9 08:02:23 laptop NetworkManager[10134]: <warn> Activation (wlan0) failed for access point (4452lakeside)
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> Marking connection 'Auto 4452lakeside' invalid because IP configuration expired.
> Aug  9 08:02:23 laptop NetworkManager[10134]: <warn> Activation (wlan0) failed.
> Aug  9 08:02:23 laptop NetworkManager[10134]: <debug> [1281355343.72382] [nm-device.c:3600] failed_to_disconnected(): (wlan0): running failed->disconnected transition
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> (wlan0): device state change: 9 -> 3 (reason 0)
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> (wlan0): deactivating device (reason: 0).
> Aug  9 08:02:23 laptop NetworkManager[10134]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 10138
> Aug  9 08:02:23 laptop NetworkManager[10134]: <error> [1281355343.281808] [nm-system.c:1229] check_one_route(): (wlan0): error -34 returned from rtnl_route_del(): Netlink Error (errno = Numerical resul
> t out of range)
> Aug  9 08:02:23 laptop kernel: phy0: Removed STA 00:1e:2a:52:dc:d2
> Aug  9 08:02:23 laptop kernel: phy0: Destroyed STA 00:1e:2a:52:dc:d2
> Aug  9 08:02:23 laptop kernel: wlan0: deauthenticating from 00:1e:2a:52:dc:d2 by local choice (reason=3)
> Aug  9 08:02:23 laptop kernel: phy0: device now idle
> Aug  9 08:02:23 laptop kernel: phy0: device no longer idle - scanning

Looks DHCP lease (duration when IP address from DHCP server is valid) timed out. Then we get DHCPNAK from DHCP server. I think reason of NAK if that we send request with our old IP address, which for some reason DHCP serwer do not want reallocate to us again. Network manager in that case disconnect from AP completely. Whereas it should only reconfigure IP address for interface - DHCP client should send DHCPREQUEST with null CIADDR (Client IP Address) or start DHCP transaction from scratch by sending DHCPDISCOVER.

This is NetworkManager or dhcpclient problem, IMHO looks more like NM bug, reassigning to NM

This behavior was fixed on Jul 27 upstream and was included in the NM 0.8.1-4 update.

*** This bug has been marked as a duplicate of bug 590874 ***