WiFi detects networks but will not connect properly (Wifi Link 5300)

[Mikademus]

I have a Intel WiFi Link 5300 [8086:4236] on my HP EliteBook 8530.

It correctly scans and locates my AP (wireless router), but connecting to it takes some time, and I get a dialogue asking for the network passkey.

Regardless of the correct key being filled in, the dialogue will repeat and eventually the connection will fail.

The network itself works, and I have tried the WiFi card and computer with other Linuxen (f.i. Mandriva 2009.1 MLO) where it works as expected.

What can be the problem in Fedora, and how do I fix it?

Regards


PS. Related questions and topics might be
http://www.linux-noob.com/forums/ind...showtopic=3500
http://www.linuxtent.com/?p=118
http://www.linux-noob.com/forums/ind...showtopic=2001

[scottro]

I'm afraid I can't help with the problem, but I've given it a title that makes it more likely that someone who *can* help will see it.

(Especially on weekends, when people tend to just scan the forums in a hurry, it's quite likely that with a vague title like "wirelesss" a post will be completely ignored.)


Take a look at the guidelines and advice about specific thread titles. Trust me, it adds to the likelihood that someone will see it who can help.

[M4rc0]

Hi there,

I can't connect to wifi either.

There are many wifi topics out there (including this one) so I don't want to create yet another topic about this issue..

Also I can't understand if i should leave NetworkManager controling my interface or not. And what is wpa_supplicant and if i should keep the service running.

Here's what I'm doing:

iwlist wlan1 scan
iwconfig wlan1 essid <public_essid_here>
dhclient wlan1

After a long wait for dhclient, the internet is not up. I tried stopping NetworkManager before doing this as well.

Also tried adding the access point mac address and the channel with iwconfig, no luck.

Mikademus, what gui do you use for this? is it a gnome wifi window?

[bbfuller]

This is a sort of general purpose reply before we possibly talk about specifics.

Firstly, NetworkManager is the default method of controlling network devices in Fedora 11. It will actively interfere with any other method of controlling an interface.

NetworkManager in both Gnome and KDE is located in the system tray area of the Panel just to the left of the clock. If wireless is working, left clicking on it should show a list of available wireless access points, left clicking on one of those etc............

If that fails then there are a couple of things to try. I accept that Mikademus's card works in Mandriva, but I suppose that different kernels, different implementations of the wireless driver could cause these symptoms.

Try checking that your access point is not broadcasting on channels 12 or 13. Thos channels are not available in some parts of the world and some drivers don't seem to work with them.

Similarly, not all Linux drivers work well with the "draft n" capability built into some wireless access points. It may be worth checking for that or references similar to "channel bonding" or "channel widening" and turning them off at least for test purposes.

If that doesn't help, you may want to post back the results of:

/sbin/lspci

just where it relates to your wireless card.

Or, if you know the name of the wireless driver that is controlling your card even better, post that back.

Once we know that the are a couple of diagnostic tests that can be run that "may" trap any error messages that are being generated when you try to connect.

[Anniedog]

For what it is worth I have had trouble with network manager on wifi on a i386 F11 box. In the end it turned out to be a mode problem. Once I switched the mode from auto to managed/infrastructure it was fine. Seems that my card just did not like Network managers default and this mucked up the card recognition. Network manager just failed to identify that I had a wireless card installed.

Just a little bit more, I have in the past had problems on wireless that was more to do with my router. I do tend to use IP Lan reservation and use the wireless access list features on my netgear. This can easily cause a problem with a new install, especially if you use a new name for the machine or manually configure the IP address. So check that your router will allow the new F11 to connect it is also worth if your dchp is handled by the router making sure that you put the router address in the settings.

[Mikademus]

I'm afraid I can't help with the problem, but I've given it a title that makes it more likely that someone who *can* help will see it.

Thank you! When asking questions about unfamiliar things it can be difficult even figuring out how to name one's question.

After a long wait for dhclient, the internet is not up. I tried stopping NetworkManager before doing this as well.

Also tried adding the access point mac address and the channel with iwconfig, no luck.

Mikademus, what gui do you use for this? is it a gnome wifi window?

M4rc0, I use KDE4, with it's plasma network manager and the KDE4 Network Manager Control Module. It can scan and identify all surrounding networks (including mine), and save all details etc. Networks are also listed in the plasma list, and are selectable for connection.

The problem is while connecting, it takes some time and then a dialogue appears, and asks for the passkey. Regardless of passkey entered it then spends more time trying to connect, asking again a few times for the passkey, whereafter giving up and reporting failure.

...set connection mode to infrastructure...

Good and simple advice! My connections mode is already set at infrastructure, so unfortunately that wasn't the issue here, but hopefully it will help others with similar problems!

If that fails then there are a couple of things to try. I accept that Mikademus's card works in Mandriva, but I suppose that different kernels, different implementations of the wireless driver could cause these symptoms.

Try checking that your access point is not broadcasting on channels 12 or 13. Thos channels are not available in some parts of the world and some drivers don't seem to work with them.

Similarly, not all Linux drivers work well with the "draft n" capability built into some wireless access points. It may be worth checking for that or references similar to "channel bonding" or "channel widening" and turning them off at least for test purposes.

Thank you for your help! My router is a D-Link DIR-655, which is generally considered and reviewed as an stable and recommendable high-end wireless router for home use. It transmits on channel 6, at the 2.4 GHz band. The laptop is a HP EliteBook 8530, which I carefully selected for high standard equipment and Linux compatibility.

My laptop and the router both supports the N protocol, but I have also tested both G and B standards, with no success under Fedora11. And as reported, the wifi worked out of the box with a KDE4 LiveCD of Mandriva 2009.1, so I am relatively confident the problem isn't with the hardware itself. Therefore I hope if we can sort this out it might result in a solution to submit into Rawhide?

If that doesn't help, you may want to post back the results of /sbin/lspci

Relevant output is

00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)         
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5300

lspci -vvnn reports the kernel driver in use to be iwlagn

Thank you for all your replies and assistance!

[scottro]

I have a page that goes through taking NetworkManager out of the equation. This way, we can be sure it's not a NM problem.

http://home.roadrunner.com/~computer.../wireless.html

Please run the stuff there, and let us know the result. NM is getting better with each iteration, but it can still sometimes be the culprit.

[bbfuller]

Hello Mikademus

Given all the above information, if that were my setup I'd want to try connecting to my - or another - access point with no encryption at all to try and narrow down the point of failure.

I'd also run the commands:

dmesg | grep iwlagn

and

dmesg | grep <identity of network interface>

to see if we can trap any comprehensible error messages from the software as it tries to connect.

By the way, if that first dmesg command lists the iwl5000-firmware have you got the most recent. There is an update of that from 21st May in the repositories?

[Mikademus]

Scottro, that's a good and comprehensive walk-through you've written! I followed it until the "iwconfig wlan0 essid mynetwork" line, which doesn't work on (my) Fedora11. However, the gist of it, that wlan0 is "UP" was established.

Given all the above information, if that were my setup I'd want to try connecting to my - or another - access point with no encryption at all to try and narrow down the point of failure.

I tried removing the security and was able to establish a connection. Thus, we seem to have narrowed it the fail point down to security recognition, handshaking, or thereabouts.

I'd also run the commands:

dmesg | grep iwlagn

and

dmesg | grep <identity of network interface>

to see if we can trap any comprehensible error messages from the software as it tries to connect.

By the way, if that first dmesg command lists the iwl5000-firmware have you got the most recent. There is an update of that from 21st May in the repositories?

dmesg | grep iwlagn returns

iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, 1.3.27kds
iwlagn: Copyright(c) 2003-2008 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn: Detected Intel Wireless WiFi Link 5300AGN REV=0x24
iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels
iwlagn 0000:03:00.0: irq 31 for MSI/MSI-X
wmaster0 (iwlagn): not using net_device_ops yet
wlan0 (iwlagn): not using net_device_ops yet
iwlagn 0000:03:00.0: firmware: requesting iwlwifi-5000-1.ucode
iwlagn loaded firmware version 5.4.1.16
iwlagn: Radio disabled by HW RF Kill switch
iwlagn: Radio Frequency Kill Switch is On:
iwlagn: Radio Frequency Kill Switch is On:
iwlagn: Radio Frequency Kill Switch is On:

and dmesg | grep wlan0 returns a rather hugeish deluge, but I'm pasting the last hundred lines or so (which seems representative and includes the successful connection to the unprotected AP):

ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready                     
wlan0: disassociating by local choice (reason=3)                       
wlan0: deauthenticated (Reason: 1)                                     
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: deauthenticating by local choice (reason=3)                     
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: authenticated                                                   
wlan0: associate with AP 06:24:01:32:ad:b5                             
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated                                                      
wlan0: deauthenticating by local choice (reason=3)                     
wlan0: No STA entry for own AP 00:00:00:00:00:00                       
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: authenticated                                                   
wlan0: associate with AP 06:24:01:32:ad:b5                             
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated                                                      
wlan0: disassociating by local choice (reason=3)                       
wlan0: deauthenticated (Reason: 1)                                     
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: authenticated                                                   
wlan0: associate with AP 06:24:01:32:ad:b5                             
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated                                                      
wlan0: disassociating by local choice (reason=3)                       
wlan0: deauthenticated (Reason: 1)                                     
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: deauthenticating by local choice (reason=3)                     
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: authenticated                                                   
wlan0: associate with AP 06:24:01:32:ad:b5                             
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated                                                      
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready                     
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
wlan0: authenticated                                                   
wlan0: associate with AP 06:24:01:32:ad:b5                             
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated                                                      
wlan0: deauthenticating by local choice (reason=3)                     
wlan0: No STA entry for own AP 00:00:00:00:00:00                       
wlan0: authenticate with AP 06:24:01:32:ad:b5                          
ADDRCONF(NETDEV_UP): wlan0: link is not ready                          
wlan0: direct probe to AP 06:24:01:32:ad:b5 try 1                      
wlan0 direct probe responded                                           
wlan0: authenticate with AP 06:24:01:32:ad:b5
wlan0: authenticated
wlan0: associate with AP 06:24:01:32:ad:b5
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: disassociating by local choice (reason=3)
wlan0: no IPv6 routers present
wlan0: direct probe to AP 06:24:01:32:ad:b5 try 1
wlan0 direct probe responded
wlan0: authenticate with AP 06:24:01:32:ad:b5
wlan0: authenticated
wlan0: associate with AP 06:24:01:32:ad:b5
wlan0: RX AssocResp from 06:24:01:32:ad:b5 (capab=0x421 status=0 aid=1)
wlan0: associated
wlan0: No ProbeResp from current AP 06:24:01:32:ad:b5 - assume out of range
wlan0: direct probe to AP 06:24:01:32:ad:b5 try 1
wlan0: direct probe to AP 06:24:01:32:ad:b5 try 2
wlan0: direct probe to AP 06:24:01:32:ad:b5 try 3
wlan0: direct probe to AP 06:24:01:32:ad:b5 timed out

Thanks for the very speedy replies!

[bbfuller]

Hello Mikademus

Without being able to give you an answer, I would suggest that this output is at the root of your trouble:

wlan0: deauthenticating by local choice (reason=3)

Searching the internet on that message I came up with quite a few responses in connection with your other questionable output:

Radio Frequency Kill Switch is On:

From the little reading I did it implies that the "Radio Kill Switch" must be off for wireless to work.

See thread here:

http://www.gossamer-threads.com/list...8241?page=last

I saw several other sites with information. You might care to do the search and see if you come up with any sensible fixes. I confess in the short time I looked I didn't see any.

[Mikademus]

Have done further research, and this seems to be a widespread and common issue, even been referred to as a "plague" in some bug report threads.

RedHat reports that this problem is due to hardware encryption acceleration in Intel WiFi drivers. Their suggested fix is:

Due to outstanding driver issues with hardware encryption acceleration, users of Intel WiFi Link 4965, 5100, 5150, 5300, and 5350 wireless cards are advised to disable hardware accelerated encryption via module parameters. Failure to do so may result in the inability to connect to WEP (Wired Equivalent Privacy) protected wireless networks after connecting to WPA (WiFi Protected Access) protected wireless networks. To do so, add the following options to /etc/modprobe.conf:

alias wlan0 iwlagn 
options iwlagn swcrypto50=1 swcrypto=1

(where wlan0 is the default interface name of the first Intel WiFi Link device; replace or amend as appropriate for local hardware configuration)

However, etc/modprobe.conf apparently doesn't exist in Fc11. I'd be happy to test this suggested fix, but I simply don't know which file to edit.

Further, this issue seems to have been a known bug in Mandriva 2008 and 2009, where iwlagn too is mentioned, and fixed for 2009.1. I think that bug contains most, perhaps all, information needed to figure out what is wrong, but to be utterly honest, it is way above my Linux-fu to grok it -- though I do my best to learn, I am green and somewhat helpless

Anyway, they seem to agree that the problem is a compound of wca_supplicant, sometimes incorrect usage of leases (rf the dhclient.wlan0.leases sometimes helps) and bugs in dhclient, there were several recommendations to use dhcpcd and net_applet instead of dhclient and wca_supplicant if I understood correctly. However, some also suggest the problem is with the net applet itself, and that manually using aca_cli is the only way to consistent success. The Fedora11 version of dhclient is 4.1.0, but apparently the more recent version 4.1.0-5 contains fixes for some of these problems. The problematic behaviour of dhclient seems to have been known (and fixed?) in Debian since 2005.

Gustavo de Narding seems to confirm that this is in fact a bug, and that it has been fixed in Mandriva 2009.1:

"Found this RH bug:
<https://bugzilla.redhat.com/show_bug.cgi?id=468967>, where they dealed with
the problem too. Patch jwltest-mac80211-deauth-on-down.patch from
<http://people.redhat.com/linville/kernels/rhel5/> fixes the related bug in
older kernels.

While investigating this with Herton, we found that bug is solved in the kernel
2.6.29 already in Cooker, but that still isn't enough. Herton came up with one
more fix to mac80211, which solved the problem after all! He'll study the code
a bit more to be sure and we should have a proper fix soon. :] "

Since the WiFi works on Mandriva, perhaps Adam Williamson can be reached? He might know if there's a driver difference or something between Fedora and Mandriva, and I think he was involved in fixing this bug for Mandriva in late 2008.

[scottro]

You can create /etc/modprobe.conf. Take any text editor, make the file, and put the required lines in it.
Let us know how that works. Good googling by the way.

[Mikademus]

You can create /etc/modprobe.conf. Take any text editor, make the file, and put the required lines in it.

Should it be under /etc/ or under /etc/modeprobe.d/ ?

Let us know how that works. Good googling by the way.

The post took me several hours to make... O.o

[Mikademus]

I created modprobe.conf under etc/modprobe.d and added the RedHad lines in it; then rebooted.

Nothing.

[edit]

After asking around in IRC I was told to name the file "iwlagn.conf" and place it under etc/modprobe.d/, which I tried. Still nothing.

[bbfuller]

Hello Mikademus

Interesting, so far I haven't had any trouble with my Intel 4965 but I now know what to watch out for.

The modprobe.conf file should be directly off "/etc"

You'll probably see messages about it being deprecated. It's due to be replaced with some other configuration in the future but should be able to be read there for now.