Latest kernel makes wireless connection to WPA2 router fail

[Sam Varshavchik]

Henrik Frisk writes:

> « HTML content follows »
> 
> 
> 
> On Sun, Aug 30, 2009 at 9:22 PM, Sam Varshavchik 
> <<URL:mailto:mrsam at courier-mta.com>mrsam at courier-mta.com> wrote:
> 
>    
>    Henrik Frisk writes:
>    
>      Hi,
>      
>      I'm running FC11 on a MacBook Pro. After the latest kernel updates 
>      (to 2.6.29.6-217.2.16.fc11.x86_64) I cannot connect to my wireless 
>      router anymore. If I boot up in the previous kernel it works fine. 
>      Any ideas on how I can fix this? The wireless interface on this 
>      laptop is a Broadcom Corporation BCM4322.
>    
>    No problems on this laptop with BCM4311 and the latest kernel.
>    
>    Generally, a blanket statement that something doesn't work offers very 
>    little usable information to work with. At the very least, you should 
>    gather some preliminary information yourself, such as:
> 
> 
> Right, sorry about that.
>  
> 
>    
>    1) the output of lsmod, to determine whether the b43 kernel module is 
>    loaded.'
> 
>  
> It wasn't but it didn't change anything to add it. Here's the output of 
> 'lsmod | grep b43'
> b43                   127352  0 
> ssb                    39572  1 b43
> mac80211              199632  1 b43
> cfg80211               37088  2 b43,mac80211
> input_polldev           3952  2 b43,applesmc
> 
> 
>    
>    2) various bits of information from /var/log/messages. kernel messages 
>    from early in the boot process would report whether or not the kernel 
>    module was loaded, and if not why not. Or may be you have some error 
>    messages from NetworkManager, or wpa_supplicant, that point towards a 
>    clue.
> 
> 
> Here's the output of 'cat messages | grep Network':
> 
> Aug 30 22:34:34 localhost NetworkManager: <info>  Activation 
> (eth1/wireless) Stage 2 of 5 (Device Configure) successful.  Connected to 
> wireless network 'dinergy'.
> Aug 30 22:34:34 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 3 of 5 (IP Configure Start) scheduled.
> Aug 30 22:34:34 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 3 of 5 (IP Configure Start) started...
> Aug 30 22:34:34 localhost NetworkManager: <info>  (eth1): device state 
> change: 5 -> 7 (reason 0)
> Aug 30 22:34:34 localhost NetworkManager: <info>  Activation (eth1) 
> Beginning DHCP transaction.
> Aug 30 22:34:34 localhost NetworkManager: <info>  dhclient started with 
> pid 9060
> Aug 30 22:34:34 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 3 of 5 (IP Configure Start) complete.
> Aug 30 22:34:34 localhost NetworkManager: <info>  DHCP: device eth1 state 
> changed normal exit -> preinit
> Aug 30 22:35:20 localhost NetworkManager: <info>  Device 'eth1' DHCP 
> transaction took too long (>45s), stopping it.
> Aug 30 22:35:20 localhost NetworkManager: <info>  eth1: canceled DHCP 
> transaction, dhcp client pid 9060
> Aug 30 22:35:20 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 4 of 5 (IP Configure Timeout) scheduled...
> Aug 30 22:35:20 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 4 of 5 (IP Configure Timeout) started...
> Aug 30 22:35:20 localhost NetworkManager: <info>  (eth1): device state 
> change: 7 -> 9 (reason 5)
> Aug 30 22:35:20 localhost NetworkManager: <info>  Activation (eth1) failed 
> for access point (dinergy)
> Aug 30 22:35:20 localhost NetworkManager: <info>  Marking connection 'Auto 
> dinergy' invalid.
> Aug 30 22:35:20 localhost NetworkManager: <info>  Activation (eth1) failed.
> Aug 30 22:35:20 localhost NetworkManager: <info>  Activation (eth1) Stage 
> 4 of 5 (IP Configure Timeout) complete.
> Aug 30 22:35:20 localhost NetworkManager: <info>  (eth1): device state 
> change: 9 -> 3 (reason 0)
> Aug 30 22:35:20 localhost NetworkManager: <info>  (eth1): deactivating 
> device (reason: 0).
> 
> It finds the access point but fails at connecting..
> 
> thanks for any help,

The best thing for you to do is to open a Bugzilla bug for the kernel 
component, noting that this is a regression, and including both the above 
output, as well as the output of the "lspci -vv" and "lspci -n" command, 
then, until this gets resolved, continue using the previous kernel.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20090830/8c16614c/attachment-0001.sig>