Исправление продления IP после приостановки работы ноутбука

У меня Macbook Pro 5.5 с Ubuntu 10.04, и я заметил, что с некоторыми сетями Wi-Fi, но не со всеми, я не могу восстановить соединение после выхода из режима ожидания. Я пробовал и демоны управления Network Manager и Wicd, и оба прошли проверку, но зациклились на "Получение IP-адреса ...". Единственное решение, которое я нашел, это перезагрузить компьютер, после чего он очень быстро получает IP-адрес.

Что является основной проблемой здесь? Что может быть более эффективным способом решения проблемы?

РЕДАКТИРОВАТЬ: я заметил, что если я открою Wicd и вручную нажимаю «Connect», он не сможет получить IP. Однако, если я ничего не делаю и позволяю ему автоматически пытаться подключиться, он получает IP и подключается очень хорошо ...

РЕДАКТИРОВАТЬ: обратите внимание, эта проблема зависит от беспроводного маршрутизатора, к которому я пытаюсь подключиться. У меня нет проблем с базовым Wi-Fi-маршрутизатором Linksys или беспроводным маршрутизатором, имитируемым приложением беспроводной привязки Android. Однако старые дрянные беспроводные маршрутизаторы Cisco / Comcast / Verizon дома всегда вызывают головную боль при подключении только после приостановки. Если я перезагружаюсь, я могу подключиться к ним немедленно.

РЕДАКТИРОВАТЬ: я попытался отрегулировать настройки клиента DHCP в Wicd.

Первоначально, он использовал dhclient, и неудачная попытка подключения создала бы журнал вроде:

2011/07/28 20:55:35 :: Listening on LPF/eth2/00:26:bb:1b:90:cc
2011/07/28 20:55:35 :: Sending on   LPF/eth2/00:26:bb:1b:90:cc
2011/07/28 20:55:35 :: Sending on   Socket/fallback
2011/07/28 20:55:35 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 5
2011/07/28 20:55:40 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 10
2011/07/28 20:55:50 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 11
2011/07/28 20:56:01 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 18
2011/07/28 20:56:19 :: DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 17
2011/07/28 20:56:36 :: No DHCPOFFERS received.
2011/07/28 20:56:36 :: No working leases in persistent database - sleeping.
2011/07/28 20:56:45 :: DHCP connection failed
2011/07/28 20:56:45 :: exiting connection thread
2011/07/28 20:56:45 :: Sending connection attempt result dhcp_failed
2011/07/28 20:56:45 :: attempting to set hostname with dhclient
2011/07/28 20:56:45 :: using dhcpcd or another supported client may work better
2011/07/28 20:56:45 :: attempting to set hostname with dhclient
2011/07/28 20:56:45 :: using dhcpcd or another supported client may work better

Отмечая рекомендацию попробовать dhcpcd вместо этого, я установил, перезапустил службу wicd и установил ее на используйте dhcpcd. К сожалению, проблема остается с еще менее полезным журналом:

2011/08/01 19:44:56 :: Connecting to wireless network CrappyCiscoRouter
2011/08/01 19:44:56 :: Putting interface down
2011/08/01 19:44:56 :: Releasing DHCP leases...
2011/08/01 19:44:56 :: Setting false IP...
2011/08/01 19:44:56 :: Stopping wpa_supplicant
2011/08/01 19:44:56 :: Flushing the routing table...
2011/08/01 19:44:56 :: Putting interface up...
2011/08/01 19:44:58 :: Attempting to authenticate...
2011/08/01 19:45:02 :: Running DHCP with hostname localhost
2011/08/01 19:45:22 :: err, eth2: timed out
2011/08/01 19:45:22 :: 
2011/08/01 19:45:22 :: DHCP connection failed
2011/08/01 19:45:22 :: exiting connection thread
2011/08/01 19:45:22 :: Sending connection attempt result dhcp_failed

РЕДАКТИРОВАТЬ: я на 99% убежден, что это своего рода ошибка с проприетарным драйвером Broadcom STA и как он обрабатывает управление питанием (т.е. Приостановка), так как перезагрузка исправляет всю мою систему, и я никогда не сталкивался с проблемой на устройствах Linux с беспроводными драйверами не Broadcom. Что разочаровывает ... потому что это не оставляет у меня особых возможностей, так как я не могу найти альтернативу с открытым исходным кодом дрянного драйвера Broadcom.