After searching the forums and doing a bit of googling, I found a few hits from people having similar problems. Sadly, none really matched mine. A few were having driver problems. This seems unlikely in my case since I can connect to insecure networks using wireless tools using the same wireless card and driver. Also, I can detect the secure wireless network with 'iwlist wlan0 scan'. One forum thread suggested:

You may be missing Cryptographic API modules, preventing secure connections.

Also, I use a different centrino model with iwlwifi and according to that wiki the microcode is required to really make full use of the cards.
To do so you will probably need to compile it as a module, not built-in, so the firmware can be applied to the module. This is also covered
in the wiki article. I don't know how to build firmware into the kernel itself, if that is even an issue.

I've never used WPA-Enterprise to know if your wpa_supplicant.conf is properly configured.
I do use '-D nl80211' for my centrino card.

In short, and in lieu of a more knowledgeable answer..

Switch iwlwifi to a module
Ensure mac80211 and Crypto API modules (or built-in may be ok here?) are selected and then

Quote:

emerge -av net-wireless/iwl6000-ucode

**Edit: I forgot in my 'shortened' version to add
Device Drivers
--->Generic Driver Options
------>[*] Userspace firmware loading support
Is needed in the kernel, to allow the microcode to be applied.

Odward, I think the iwlwifi is outdated, which is really a shame because it's quite thorough. If I'm not mistaken, the functionality of the iwlagn driver has been folded into the iwlwifi driver, which it seems doesn't suffer from the same problem with needing to be loaded as a module. But, I tried an experiment and recompiled with iwlwifi as a module; the system couldn't see wlan0 at all, which is kind of weird.

khayyam, I took your advice and set ca_cert="/etc/ssl/certs/AddTrust_External_Root.pem". The first time I ran wpa_supplicant after that, it seemed like it was working. I didn't capture the exact messages (sadly!), but it seemed to indicate that it was connecting. But, I couldn't ping any url from another terminal, so something still wasn't right. I thought perhaps that I should run it in the background with -B , so I killed wpa_supplicant with ctrl+c and ran the command again with -B. It wouldn't connect, and I haven't been able to recreat that instance since.

khayyam, I took your advice and set ca_cert="/etc/ssl/certs/AddTrust_External_Root.pem". The first time I ran wpa_supplicant after that, it seemed like it was working. I didn't capture the exact messages (sadly!), but it seemed to indicate that it was connecting. But, I couldn't ping any url from another terminal, so something still wasn't right. I thought perhaps that I should run it in the background with -B , so I killed wpa_supplicant with ctrl+c and ran the command again with -B. It wouldn't connect, and I haven't been able to recreat that instance since.

jyoung ... wpa_supplicant only negociates the connection, you will need to configure the interface for an IP, route, DNS, etc ... eg, using dhcp (net-misc/dhcpcd)

khayyam, I put the code you indicated in /etc/conf.d/net. Did you mean net.lo? /etc/conf.d/net didn't exist until I created it and put the code there.

In any case, /etc/init.d/net.wlan0 start returns 'WARNING: net.wlan0 has started, but is inactive'. Trying to start wpa_supplicant by hand still doesn't recreate the instance I mentioned above, where it seemd to connect. I wonder what happened that time - I don't think I did anything differently. In every case I've been sure to run 'dhcpcd -k' and 'ifconfig wlan0 up' first.

Okay, it seems like I'll need to post the logs - where can I find those?

khayyam, I put the code you indicated in /etc/conf.d/net. Did you mean net.lo? /etc/conf.d/net didn't exist until I created it and put the code there.

jyoung ... no, I ment /etc/conf.d/net

jyoung wrote:

In any case, /etc/init.d/net.wlan0 start returns 'WARNING: net.wlan0 has started, but is inactive'.

That is quite normal ... its a warning, not an error ... its simply informing you the service has started but its not waiting to be sure the connection is established. All being well it should negociate with the AP, run dhcp, and provide you with and IP, route, DNS, etc.

jyoung wrote:

Trying to start wpa_supplicant by hand still doesn't recreate the instance I mentioned above, where it seemd to connect. I wonder what happened that time - I don't think I did anything differently. In every case I've been sure to run 'dhcpcd -k' and 'ifconfig wlan0 up' first.

Why are you running dhcpcd/ifconfig? The configuration/command above should be all thats needed (assuming your wpa_supplicant.conf is correct).

jyoung wrote:

Okay, it seems like I'll need to post the logs - where can I find those?

Thanks! I went back and tried '/etc/init.d/net.wlan0 start' again. It issued the same warning, but 'ping www.google.com' returned 'unknown host www.google.com' (this is how I've been testing for connectivity). I tried ping again in a few minutes, still no luck. Then, a few hours later, I pinged google again, and this time I got a hit. I opened a web browser, and sure enough I had a connection.

This is a huge step forward for me, but I'm not out of the woods yet. The connection died after about five minutes. It's been on an off all day, though more often off than on. So, two questions: First, after I launch net.wlan0, is there any way to get a status report from it? More than just the warning? Second, any ideas why the connection is so unpredictable?

This simply looks like the driver/firmware isn't initalised correctly ... did you follow Odward's advice above? You should probably check the iwlwifi wiki page ... and you should probably be using ''-Dnl80211' rather than 'Dwext', and as it has a firmware to load you should probably make sure the driver is compiled as a module, not directly into the kernel.

Which seems odd to begin with, since it's compiled with 'm'. Also, ifconfig doesn't detect wlan0, which tells me that sometime is wrong:

ifconfig wlan0 up
wlan0: ERROR while getting interface flags: No such device

In my previous configuration, the one with the driver in the kernel, I also had the firmware in the kernel:

CONFIG_FIRMWARE_IN_KERNEL=y

So, I thought perhaps that having the firmware in the kernel but the driver as a module might screw things up, so I changed that with menuconfig, and recompiled. But, the wlan0 still wasn't detected. I confirmed that the firmware is installed:

qlist -Iv | grep ucode
net-wireless/iwl6000-ucode-9.221.4.1

Also, changed from -Dwext to -Dnl80211 before I did any of this, without effect. I've also checked my confirguration against the wiki - I did find one mistake, I'd forgotten to select 'Common routines for IEEE802.11 drivers'. I also made that change before I recompiled the driver as a module.

Yes, I did a double take as well, thinking I'd forgotten to copy it over. I should have mentioned that in my last post; I'm definitely running the new kernel. To check, I just ran make && make modules_install in /usr/src/linux, and then differenced the newly compiled kernel with the one in the boot partition; they're the same.

Yes, I did a double take as well, thinking I'd forgotten to copy it over. I should have mentioned that in my last post; I'm definitely running the new kernel. To check, I just ran make && make modules_install in /usr/src/linux, and then differenced the newly compiled kernel with the one in the boot partition; they're the same.

jyoung ... sorry that sounded in the realm of the too obvious, but users forgetting to copy, or copying when /boot isn't mounted, happens often enough that its the most common cause of such an error. In future though 'uname -a' will output the number of times the kernel has been compiled in the 5th column.

So, this not being the case I'm stumped as to why the modprobe doesn't work and a quick search doesn't reveal anything, sorry.

I'm still looking into reasons why my 'iwlwifi as a module' setup didn't work out. I hope to report back on that in the near future, but for now I thought of a different test I could do. So far I've been trying to connect to a secure network, but I also sometimes use an insecure one at a different location. I normally connect to this with wireless tools, but it would be interesting to test wpa_supplicant on it. Basically, it would tell me if there's something wrong with my configuration or something funky with the secure network. If it is a problem with my driver, then I should get the same results as on the secure network (right?).

But, I'm stuck. What does the wpa_supplicant.conf configuration for an insecure network look like? After reading the man pages and a few sites I converged on this:

network={
ssid="<network name>"
scan_ssid=1
key_mgmt=WPA-PSK
}

But, that didn't work out. As with the secure network, '/etc/initi.d/net.wlan0 start' started but was inactive. However, I was never able to get a connection with 'ping', even after waiting an hour. Any ideas for the above configuration?

would be more appropriate. Is this a clean wpa_supplicant.conf you're working with? Or are you
appending those rules to your existing wpa_supplicant.conf? If it's the latter, you might want to
temporarily add

Code:

priority=10

So it will try to connect to the unsecure network before any other settings (assuming they don't have
a priority set with a Higher number).

I checked out my configuration, and CONFIG_SUSPEND=y, so it seems that the iwlwifi bug doesn't apply to my case. I've also done the experiment of reverting to the default /usr/src/linux/.config file, and enabling the iwlwifi driver as a module from there. This .config file is a copy I made of the .config file generated by menuconfig without modifications after I emerged the 3.4.4 kernel. The idea was that if some changes I'd made were conflicting with iwlwifi or somehow demanding that it be compiled into the kernel despite the '=m', this would circumvent those issues. But, no luck. I got the same message, that iwlwifi was already in the kernel.

Here's a question: Is there any way to confirm that a module is actually in the kernel? Beyond checking .config?

I plan to try the insecure network today; I'll report back on how that goes. Thanks, Odward, for all the help on that.

The only method I'm aware of to determine details about the running kernel, requires that you have enabled

Code:

General Setup --->
<*> Kernel .config support

This will let you use tools like zgrep or zcat to see what is in the file /proc/config.gz
Which is a .config for the Running kernel. If you currently have /proc/config.gz then the running kernel was
compiled with that option.

My experiment with the insecure network had interesting results. I was able to connect to it, and remain connected indefinitely. This worked with either the -Dwext or -Dnl80211 options. To me, that suggests that the issue isn't with the driver, but with the wireless configuration or with the secured network. Another experiment would be to connect to a different secure network and see if I have the same issues. What do you folks think?

On the driver side of my investigation, recompiling with <*> Kernel .config support allowed me to check /proc/config.gz - indeed, CONFIG_IWLWIFI=m, even though when I try to load the module I get the message that it's already in the kernel.

On the driver side of my investigation, recompiling with <*> Kernel .config support allowed me to check /proc/config.gz - indeed, CONFIG_IWLWIFI=m, even though when I try to load the module I get the message that it's already in the kernel.

jyoung ... I wonder if this isn't perhaps a case where the firmware is in kernel, and so once the module is loaded (no doubt at boot) then the two are fused. Have you tried to unload the module?

As for encrypted/unencrypted networks, this may be due to missing cryptograpic cyphers, or CRC functions,check that CRYPTO_AES, CRC32 and ARC4 are enabled.

Hey Folks, I followed up on khayyam's idea that the in-kernel firmware might be pulling the driver in. I recompiled the kernel with

# CONFIG_FIRMWARE_IN_KERNEL is not set

But, no luck - iwlwifi was still reported as already being in the kernel.

On the secure vs. insecure network issues, I already had the following:

CONFIG_CRYPTO_AES=y
CONFIG_CRC32=y
CONFIG_CRYPTO_ARC4=y

but I also had:

CONFIG_CRYPTO_CRC32C is not set
CONFIG_CRYPTO_CRC32C_INTEL is not set

so I changed those:

CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y

But, after trying the connection all day yesterday I must report that it is the same as before - connects sometimes after many hours of wait, and breaks the connection within minutes. There are some other references to CRC32:

CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
CONFIG_CRC32_SLICEBY4 is not set
CONFIG_CRC32_SARWATE is not set
CONFIG_CRC32_BIT is not set
CONFIG_LIBCRC32C is not set

Do you think any of these matter? I may have a chance to try a different secured network next weekend; perhaps that will shed some light on this matter.

Do any of you know if there's a log file for wpa_supplicant? Something where it would report the reason for disconnection? I'm thinking that if I can learn why the connection is failing, it might be easier to diagnose the problem.

Since I last posted, khayyam, I took your suggestion and recompiled wpa_supplicant with the debug flag and directed its output to a log file. Today I cleared the log, connected to the secured network, and waited for it to drop me. After I was disconnected, I made a copy of the log file. As you might expect, there were a lot of messages; I'd be happy to post as much of it as you folks want, but to my eyes these lines seems to bracket the problem:

I'm particularly interested in the line 'wpa_driver_wext_disassociate' - that seems to back up our ealier theory that it's a driver problem. Sadly, I haven't made any progress on getting the driver to work outside the kernel. Any new ideas on that front? Or, does this snippet of the log file suggest other lines of attack?

On a different front, I've tried to connect to two other secured networks so that I'd have points of comparison with the network that I'm having trouble with. Unfortunately, my machine wouldn't connect to either of those two networks at all (this is VERY different symptomatically from the problems I'm having with the regulars secure network, to which my computer will eventually connect for a short period of time and then loose a connection after 5-30 minutes). I suspect the problem is with the fact that I've used basically the same configuration to try to connect to these two networks as I do the regular, when in reality they might need something different. Here's what I'm putting in my /etc/conf.d/net file to try to connect to them:

How should I set this up? For one thing, I don't have a username on these networks. Also, is there a way to tell from iwlist or something like that what the other parameters should be? I captured the output from iwlist on both of these networks, but I'm not sure how to interpret it.

jyoung ... this is not suitable for /etc/conf.d/net ... this is an entry for /etc/wpa_supplicant/wpa_supplicant.conf.

jyoung wrote:

How should I set this up? For one thing, I don't have a username on these networks. Also, is there a way to tell from iwlist or something like that what the other parameters should be? I captured the output from iwlist on both of these networks, but I'm not sure how to interpret it.

If you have no username then you are not using EAP (wpa-enterprise) ... I suspect these networks are PSK (wpa-personal). So, a basic wpa_supplicant.conf entry for WPA2 would look something like the following: