# wpa_supplicant won't connect [SOLVED]

## jyoung

Hi Folks,

I'm having trouble connecting wpa_supplicant to a secured network.  When I connect with:

wpa_supplicant -D wext -i wlan0 -c /etc/wpa_supplicant.conf

I get:

```

wlan0: Trying to associate with d8:c7:c8:17:56:3a (SSID='psu' freq=5220 MHz)

wlan0: Associated with d8:c7:c8:17:56:3a

wlan0: Authentication with d8:c7:c8:17:56:3a timed out.

wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=0

```

or, sometimes:

```

wlan0: Trying to associate with d8:c7:c8:17:56:32 (SSID='psu' freq=2412 MHz)

wlan0: Associated with d8:c7:c8:17:56:32

wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK

wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21

wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected

TLS: Certificate verification failed, error 20 (unable to get local issuer certificate) depth 1 for '/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA'

wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=1 subject='/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA' err='unable to get local issuer certificate'

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA

OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

wlan0: Authentication with d8:c7:c8:17:56:32 timed out.

wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=0

```

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:

wpa_supplicant -D nl80211 -i wlan0 -c /etc/wpa_supplicant.conf

which gave me.

```

wlan0: Trying to associate with d8:c7:c8:17:53:82 (SSID='psu' freq=2437 MHz)

wlan0: Associated with d8:c7:c8:17:53:82

wlan0: Authentication with d8:c7:c8:17:53:82 timed out.

wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=3

```

My wireless card is an intel centrino 6300 (Ultimate-N), and the driver I'm using is iwlwifi, compiled into the kernel.  My wpa_supplicant.conf file is below.  What do you folks think?

wpa_supplicant.conf:

```

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

ap_scan=1

network={

     ssid="psu"

     identity=<username>

     password=<password>

     key_mgmt=WPA-EAP

     eap=TTLS

     phase2="auth=PAP"

     scan_ssid=1

     ca_cert="/etc/ssl/certs/Thawte_Premium_Server_CA.pem"

}

```

Last edited by jyoung on Fri Nov 02, 2012 7:15 pm; edited 1 time in total

----------

## Odward

I may be of little help, but I'll try anyway!

My knowledge is really just from the gentoo wiki for iwlwifi here.

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.

----------

## khayyam

 *jyoung wrote:*   

> TLS: Certificate verification failed, error 20 (unable to get local issuer certificate) depth 1 for '/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA'
> 
> wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=1 subject='/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA' err='unable to get local issuer certificate'
> 
> SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA

 

jyoung ... this is openssl saying: "I can't follow the certificate chain to a trusted root". So the CA does not match the CA your providing.

Now, this suggests the issuer for InCommon is AddTrust, and this PEM in included with openssl.

```
# openssl x509 -in /etc/ssl/certs/AddTrust_External_Root.pem -noout -text | grep Issuer

Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
```

So ... please try the following:

```
ca_cert="/etc/ssl/certs/AddTrust_External_Root.pem"
```

HTH & best ... khay

----------

## jyoung

Thanks both for the speedy reply!

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.

Any ideas?

----------

## khayyam

 *jyoung wrote:*   

> 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)

/etc/conf.d/net

```
modules_wlan0="!plug wpa_supplicant dhcpcd"

wpa_supplicant_wlan0="-Dwext"

wpa_timeout_wlan0="15"

config_wlan0="dhcp"

dhcpcd_wlan0="-t 10"
```

```
# ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0

# /etc/init.d/net.wlan0 start
```

You should check that dhcpcd (or whatever dhcp client you use) and wpa_supplicant, are not running prior to starting net.wlan0.

If this fails you will need to post logs, etc.

Also, FYI, you can't ping a "URL", only hosts. 

best ... khay

----------

## jyoung

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

 *jyoung wrote:*   

> 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?

 

Normally ... /var/log/messages.

best ... khay

----------

## jyoung

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?

I found the log file you mentioned.  I've copied below the output of ' grep wlan0 /var/log/messages  | grep "Aug 17" '

Aug 17 13:03:29 murbella kernel: [   25.492769] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Aug 17 14:27:47 murbella kernel: [ 5083.478466] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Aug 17 14:41:56 murbella kernel: [ 5932.330073] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Aug 17 14:42:00 murbella kernel: [ 5937.180469] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Aug 17 14:42:42 murbella kernel: [ 5978.709203] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Aug 17 14:47:11 murbella kernel: [ 6247.511146] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Aug 17 14:47:15 murbella kernel: [ 6251.393704] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

Aug 17 16:54:32 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 17:11:35 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 17:11:35 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 18:21:05 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 18:21:05 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 18:24:27 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 18:24:27 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 18:30:25 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 18:30:25 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 18:39:06 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 18:39:06 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 18:44:49 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 18:44:49 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 18:55:37 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 18:55:37 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 18:59:32 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 18:59:32 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 19:04:30 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 19:04:30 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 19:05:06 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 19:05:06 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 19:12:27 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 19:12:27 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 19:15:03 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 19:15:03 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 19:20:42 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 19:20:42 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 19:21:02 murbella wpa_cli: interface wlan0 CONNECTED

Aug 17 19:21:02 murbella wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed

Aug 17 19:42:21 murbella wpa_cli: interface wlan0 DISCONNECTED

Aug 17 19:42:21 murbella wpa_cli: executing 'false /etc/init.d/net.wlan0 --quiet stop' failed

Aug 17 19:52:14 murbella kernel: [24550.660090] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Aug 17 19:52:46 murbella kernel: [24583.136785] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

----------

## khayyam

jyoung ... your welcome ...

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.

best ... khay

----------

## jyoung

Hmm, I'm having trouble setting the driver up as a module.  When I set

CONFIG_IWLWIFI=m

with menuconfig and recompile the kernel, the module is created

/lib/modules/3.4.4-gentoo/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko

but isn't loaded at boot:

lsmod

Module                  Size  Used by

nvidia              10827892  38 

When I try to load it manually,

modprobe --first-time iwlwifi

I get

ERROR: could not insert 'iwlwifi': Module already in 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.

----------

## khayyam

 *jyoung wrote:*   

> ERROR: could not insert 'iwlwifi': Module already in kernel

 

jyoung ... this just sounds as though you've installed the module, but not copied the kernel from that compile to /boot (or /boot wasn't mounted when you did, one or other).

best ... khay

----------

## jyoung

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.

----------

## khayyam

 *jyoung wrote:*   

> 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.

best ... khay

----------

## jyoung

Hey Folks,

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?

----------

## Odward

I haven't tried to configure for an unsecured network, but I believe

```
key_mgmt=NONE
```

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

```
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).

So

```
network={

ssid="<network name>"

scan_ssid=1

key_mgmt=NONE

priority=10

} 
```

Relating to some of the general troubles, after learning of a bug with iwlwifi would you mind checking: 

If your kernel supports this

```
zgrep CONFIG_SUSPEND /proc/config.gz
```

otherwise

```
grep CONFIG_SUSPEND /usr/src/linux/.config
```

If that is not set let us know, if it is '=y' then disregard

----------

## jyoung

Hi Folks,

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.

----------

## Odward

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

```
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.

What is returned by

```
uname -a
```

----------

## wrc1944

Since wlan0 doesn't seem to be detected by ifconfig -a, do you have the net.wlan0 symlink to net.lo in etc/init.d/?

----------

## jyoung

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.

Odward, uname -a returns:

Linux murbella 3.4.4-gentoo #17 SMP Tue Sep 11 15:28:18 EST 2012 x86_64 Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz GenuineIntel GNU/Linux

wrc1944, /etc/init.d/net.wlan0 is a symlink to /etc/init.d/net.lo

----------

## khayyam

 *jyoung wrote:*   

> 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.

best ... khay

----------

## jyoung

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.

----------

## jyoung

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.

----------

## khayyam

 *jyoung wrote:*   

> Do any of you know if there's a log file for wpa_supplicant?

 

jyoung ... for logging above that provided in dmesg you need to enable the debug useflag. You would then edit /etc/conf.d/net and add the following to wpa_supplicant_wlan0

```
wpa_supplicant_wlan0="-Dnl80211 -f /var/log/wpa_supplicant.log -dd"
```

with '-dd' being the debug level (-d debug, -dd more debug), and -qq for less (so that you can quiet debugging once you're satisfied).

best ... khay

----------

## jyoung

Hi Folks,

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:

EAPOL: SUPP_PAE entering state CONNECTING

EAPOL: txStart

TX EAPOL: dst=d8:c7:c8:17:56:32

TX EAPOL - hexdump(len=4): 01 01 00 00

wlan0: Authentication with d8:c7:c8:17:56:32 timed out.

CTRL_IFACE monitor send - hexdump(len=21): 2f 74 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 32 32 39 33 2d 31 00

Added BSSID d8:c7:c8:17:56:32 into blacklist

wpa_driver_wext_disassociate

wlan0: No keys have been configured - skip key clearing

wlan0: State: ASSOCIATED -> DISCONNECTED

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:

network={

     ssid=<network name>

     identity=<my user name>

     password=<password>

     key_mgmt=WPA-EAP

     eap=TTLS

     phase2="auth=PAP"

     scan_ssid=1

     ca_cert="/etc/ssl/certs/AddTrust_External_Root.pem"

}

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.

----------

## khayyam

 *jyoung wrote:*   

> Here's what I'm putting in my /etc/conf.d/net file to try to connect to them:
> 
> ```
> network={
> 
> ...

 

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:

```
network={

    ssid="my_essid"

    proto=WPA2

    key_mgmt=WPA-PSK

    group=CCMP TKIP

    pairwise=CCMP TKIP

    psk=        <= password here

}
```

I'm a little rushed at the moment and so can't comment further, however can you pastebin your kernel config

best ... khay

----------

## jyoung

Sorry, I meant to say that it's in wpa_supplicant.conf !

Thanks for the configuration tips; I'll give those a try tomorrow or Friday; hopefully that will establish a point of comparison.

Which kernel config do you want?  I've got the one for the kernel that I primarily use with the iwlwifi driver compiled into the kernel, and the other experimental one that's the same except the iwlwifi driver is a module.  I'd be happy to post either (or both).

----------

## khayyam

 *jyoung wrote:*   

> Which kernel config do you want?  I've got the one for the kernel that I primarily use with the iwlwifi driver compiled into the kernel, and the other experimental one that's the same except the iwlwifi driver is a module.  I'd be happy to post either (or both).

 

jyoung ... well, for the sake of being able to debug this I would suggest you use just one. Now, wasn't there some issue with the kernel module not being able to load due to it being already compiled in kernel? This should never happen, and I think you should decide if the driver and firmware are to be in kernel or not as I'm inclined to think this issue is due to mistake on your part (possibly not running make && make modules, or not copying the kernel to boot, or your bootloader pointing to a previously compiled kernel ... something of that nature).

Without our understanding that the driver/module/firmware is working/loaded correctly its difficult to debug things in userland, so this needs to be straightened out first. I'd suggest recompiling the kernel from a clean slate (at least a 'make clean')

```
# cp .config ~/dot-config

# make clean

# cp ~/dot-config .config

# make oldconfig

# make menuconfig  # make sure the driver =m

# make && make modules_install

# mount /boot

# cp arch/x86/boot/bzImage /boot/vmlinuz-{version}
```

You would then check the bootloader has an entry for this specific kernel, and is the default kernel at boottime (or selected at bootime). You should then check to see if the driver is loaded (via dmesg) or modpobe'd (without error). This would then be the kernel config to pastbin, and the kernel that all future information is in sync with.

best ... khay

----------

## jyoung

Okay, I've booted off the clean-slate kernel (created as above), and the problem persists.  I've posted the config file here:  http://pastebin.com/KfhkTqMt

khayyam, I do kind of agree that it sounds like I've missed a step (forgotten to copy over the kernel, booted off the wrong kernel, setup grub.conf to boot off the wrong kernel, etc.), and that was my reaction when I started getting this error.  But, I've gone through the steps, and I'm not missing one that I'm aware of.  That said, I'd be happy to post a line-by-line breakdown of what I'm doing when I recompile my kernel, as well as grub.conf

When I posted back on Sept. 7, I mentioned an even more zealous experiment that I tried, going back to the original config file and making only one change - setting iwlwifi to be compiled as a module - and even then the problem was present.  It seems really weird that a fresh setup would have this problem.

----------

## wrc1944

You guys seem to have covered everything I can think of, so I'm grasping at straws here.

What about possibly conflicting net services starting at a run level?  Did you run any other network manager like wicd or networkmanager previous to trying pure wpa_supplicant?

Maybe there is something left over at boot or default run level.  In all my working wpa_supplicant systems, as far as network related items I only have: 

```
net.lo     |   boot                                          

net.wlan0  |   default                                  

netmount   |   default

local          |      default nonetwork 
```

 showing up with rc-update show.

When I went to wpa_supplicant after having problems almost every time a kernel or wicd/networkmanager version changed, I uninstalled wicd and/or networkmanager, and also manually removed ALL related config files I could find that emerge -C seemed to miss.  Then I removed them from all run levels.

Since then, about 6 months ago, I've never had a single connection problem that wasn't directly due to my router or cable modem location (just too many walls and appliances between it and my computer, and lousy cox cable connection).  This is with three Gentoo installs, and various other distros like Arch, Mint, Ubuntu, Pclos, Mageia, Kubuntu, and a few others.  

One other thing I'd try- If you have a usb wireless adapter with a different make chip, give that a try.  You could get one cheap (under $20, $30 tops) at newegg.  I've had really vexing trouble with wireless drivers before, mainly because when versions change, it breaks something with some kernels.   I'd really suspect that a iwlwifi driver and/or kernel version mismatch is the problem if you've eliminated everything else.

----------

## wrc1944

Here's a iwlwifi driver related quote from this thread, from Gentoo dev chithanh: https://forums.gentoo.org/viewtopic-t-938722.html

 *Quote:*   

> It sees your wireless, just iwconfig needs the legacy wireless extensions which are disabled by default for any modern nl80211 based driver.
> 
> Use iw instead of iwconfig, or if you depend on wireless-tools for whatever reason enable CONFIG_CFG80211_WEXT in your kernel. wpa_supplicant should be passed the -Dnl80211 parameter.

   Looking at this thread is worth it, as it's full of iwlwifi details discussed by long time users, and one Gentoo dev.

I re-read your thread and didn't see any CONFIG_CFG80211_WEXT reference (maybe I missed it), but since apparently iwlwifi needs CONFIG_CFG80211_WEXT enabled but it's disabled by default, maybe you missed it?   Whether or not it would help in your case is another question, but if it's disabled it might be worth a shot.

Have you considered trying wicd (used to be my own long-time favorite)? That finally solved it for wichtounet in the other thread I mentioned.

----------

## khayyam

jyoung ...

Sorry, I've been a bit slow in responding, I haven't had much time to go over the .config.

There seems to be two issues here, the first is the driver loading as a module and the second is the disassoc (which I think may, as wrc1944 suggests, have some relation to CONFIG_CFG80211_WEXT).

Having taken a close look at the above .config I think perhaps the reason the module is seen to be loaded when calling modprobe is as I first suggested some posts back. The debug options for iwlwifi are enabled (CONFIG_IWLWIFI_DEBUG=y, CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE=y, and CONFIG_IWLWIFI_DEVICE_TRACING=y), the 'ucode' option "enables the use of experimental ucode for testing and debugging", CONFIG_FIRMWARE_IN_KERNEL=y and CONFIG_EXTRA_FIRMWARE="iwlwifi-6000-4.ucode" are also enabled, so the ucode is in kernel, and I assume that this then treats the module as (partially) builtin. So, the solution seem to be to disable the DEBUG options, and not include the firmware in kernel. The firmware should then be loaded when the module is loaded.

As to the second problem: CONFIG_CFG80211_WEXT=y but the card uses -Dnl80211, so the use of WEXT may be unnecessary here (the posts wrc1944 links to explain better the possible issues ITR). Issues of disassoc are in my expereince often related to powersaving, and in that regard you have CONFIG_PM_RUNTIME=n (which allows I/O devices to be put into energy-saving states) and CONFIG_CFG80211_DEFAULT_PS=y (which enables powersave for 80211). My guess is that both of these should either be enabled or disabled.

best ... khay

EDIT: seeing that the card is a iwlwifi you might also want to check this thread

----------

## jyoung

Hi Folks,

The last few posts have been great - a lot of ideas, and the two threads seem like that could be a real help with the wpa_supplicant issues.  Unfortunately, I'm starting to think I have a more serious problem.

After trying a few things based on the recent posts, I decided to try compiling with .  My thinking was that, perhaps, compling this into the kernel was somehow pulling iwlwifi in.  At least it couldn't hurt to try.  But, the newly compiled kernel didn't load the cfg80211 module at boot, and when I tried to load it manually, it said that it was already in the kernel - just like iwlwifi.

So, I tried two experiments:  First, I switched CONFIG_TUN=y to =m.  I've been using the tun universal tun driver for a while compiled into the kernel, but I wanted to see if it would produce the same results as iwlwifi and cfg80211 when compiled as a module.  It did; the kernel couldn't load it because it was already in the kernel.  Then, I switch CONFIG_B43=m.   This is a driver for a broadcom wireless card; I don't have such a card anymore, but I used to, so I'm familiar with the driver.  It hasn't been in the kernel or as a module in a while, but because I knew about it I decided to do the same test on it.  This time, 'modprobe b43 --first-time' produced 'FATAL: Module b43 not found.'  I checked, and that is the right name for the module.  In fact, the module was compiled and lives in a subdirectory of /lib/modules/, the kernel just couldn't detect it.

I repeated this several times, making sure that I was compiling the right kernel.  I confirmed that the parameters were set in .config after I ran menuconfig.  I ran 'make clean' before running 'make && make modules_install'.  And, I was certain to copy the new kernel each time over to /boot and that I was booting off the new kernel when I did these tests.

It's starting to look like I've done something horribly wrong that's preventing my operating system from correctly identifying which modules exist and are loaded.  I think that I need to resolve this issue before I move forward with the wpa_supplicant situation; any ideas?  I could see if there's a new kernel available and emerge gentoo-sources and start from scratch; maybe that would wipe out whatever's causing this issue.

----------

## BillWho

jyoung,

It sounds like a mismatch with the modules   :Confused: 

Can you past back:

```
grep CONFIG_MODULES /usr/src/linux/.config

grep CONFIG_CFG80211 /usr/src/linux/.config

grep b43 /lib/modules/$(uname -r)/modules.dep

modinfo cfg80211

ls -lh /boot

```

----------

## jyoung

Okay, here's what I get:

grep CONFIG_MODULES /usr/src/linux/.config

CONFIG_MODULES=y

grep CONFIG_CFG80211 /usr/src/linux/.config

CONFIG_CFG80211=m

# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set

# CONFIG_CFG80211_REG_DEBUG is not set

# CONFIG_CFG80211_DEFAULT_PS is not set

# CONFIG_CFG80211_DEBUGFS is not set

# CONFIG_CFG80211_INTERNAL_REGDB is not set

# CONFIG_CFG80211_WEXT is not set

modinfo cfg80211

Error: Module cfg80211 not found.

grep b43 /lib/modules/3.4.4-gentoo/modules.dep

<no output returned>

ls -1h /boot/

boot

grub

iface

kernel-3.4.4-gentoo

kernel-3.4.4-gentoo.backup

kernel-3.4.4-gentoo.experimental

lost+found

memtest86

----------

## BillWho

The results of these is very strange   :Confused: 

 *Quote:*   

> modinfo cfg80211
> 
> Error: Module cfg80211 not found.
> 
> grep b43 /lib/modules/3.4.4-gentoo/modules.dep
> ...

 

What's the content of ls -l /lib/modules/$(uname -r)

Does find /lib/modules/$(uname -r) -iname '*ko' |wc -l show any count 

Also are any modules loaded - lsmod|wc -l

----------

## khayyam

 *jyoung wrote:*   

> It's starting to look like I've done something horribly wrong that's preventing my operating system from correctly identifying which modules exist and are loaded.  I think that I need to resolve this issue before I move forward with the wpa_supplicant situation; any ideas?  I could see if there's a new kernel available and emerge gentoo-sources and start from scratch; maybe that would wipe out whatever's causing this issue.

 

jyoung ... yes, as I've said this is definitely not the normal. When running 'make modules_install', 'depmod' is called, and this should create a list of module dependencies (modules.dep). Why this would be subseqently missing information about available modules, and why then the kernel would think they are 'in kernel', I really can't say, but something is amiss.

Can you provide the installed package versions of the following: module-init-tools (or kmod if your using this inplace of module-init-tools), gcc, binutils, and glibc. Also, if you run 'revdep-rebuild -pv' does it show anything (specificly, zlib or modules-init-tools) that is broken? I'm clutching at straws as I'm not sure where else to start looking.

best ... khay

----------

## jyoung

BillWho, here's what I get:

```

ls -l /lib/modules/$(uname -r) 

total 72

lrwxrwxrwx 1 root root    27 Jul 26 15:59 build -> /usr/src/linux-3.4.4-gentoo

drwxr-xr-x 6 root root  4096 Oct  9 19:52 kernel

-rw-r--r-- 1 root root   514 Aug  1 21:15 modules.alias

-rw-r--r-- 1 root root  1052 Aug  1 21:15 modules.alias.bin

-rw-r--r-- 1 root root  9265 Oct  9 19:52 modules.builtin

-rw-r--r-- 1 root root 12744 Aug  1 21:15 modules.builtin.bin

-rw-r--r-- 1 root root   231 Aug  1 21:15 modules.dep

-rw-r--r-- 1 root root   564 Aug  1 21:15 modules.dep.bin

-rw-r--r-- 1 root root    52 Aug  1 21:15 modules.devname

-rw-r--r-- 1 root root  1189 Oct  9 19:52 modules.order

-rw-r--r-- 1 root root   131 Aug  1 21:15 modules.softdep

-rw-r--r-- 1 root root   269 Aug  1 21:15 modules.symbols

-rw-r--r-- 1 root root   225 Aug  1 21:15 modules.symbols.bin

lrwxrwxrwx 1 root root    27 Oct  9 19:52 source -> /usr/src/linux-3.4.4-gentoo

drwxr-xr-x 2 root root  4096 Aug  1 21:15 video

```

It seems that there are 37 modules in total:

```

find /lib/modules/$(uname -r) -iname '*ko' |wc -l 

38

```

(since the first line is just the output header).  But, only one loaded:

```

lsmod|wc -l

2

```

The module that's loaded is the nvidia graphics card driver, which seems to load as a module regardless of what I do to the other drivers.  This could be an important clue - I haven't messed with that one in over a year, so it seems likely that whatever happened to scramble the kernel's list of modules is more recent than that.

One experiment I could try would be to switch nvidia to be compiled into the kernel, and then see if I can switch it back.  But, I dare not do this since a failure would cripple my ability to launch X.

----------

## jyoung

khayyam, the versions of those packages are:

kmod-9-r2

gcc-4.6.3

binutils-2.22-r1

glibc-2.15-r2

When I run revdep-rebuild -pv I get an error early on:

```

 * Environment mismatch from previous run, deleting temporary files...

```

That, to me, sound suspicious.  Later, I get the following:

```

 * Checking dynamic linking consistency

[ 53% ] grep: write error: Broken pipe

[ 96% ]  *   broken /usr/libexec/geoclue-localnet (requires libnm-glib.so.4

libnm-util.so.2)

 *   broken /usr/libexec/geoclue-master (requires libnm-glib.so.4

libnm-util.so.2)

[ 100% ]                 

 * Generated new 3_broken.rr

 * Assigning files to packages

 *   /usr/libexec/geoclue-localnet -> app-misc/geoclue

 *   /usr/libexec/geoclue-master -> app-misc/geoclue

 * Generated new 4_raw.rr and 4_owners.rr

```

I'd be happy to post the rest of it, but those were the only portions that were flagged (yellow).

----------

## khayyam

 *jyoung wrote:*   

> kmod-9-r2

 

jyoung ... and the Changelog for kmod-9-r2.ebuild (17 Jul 2012) states "remove broken version". So, this package has been out of tree for some time, probably this is the cause as the other packages (bar gcc which is ~arch), and the output of revdep-rebuild, are fairly sane (though you should probably revdep-rebuild and fix geoclue).

So, emerge --sync, edit /etc/portage/package.accept_keywords if your keywording on that particular version, and emerge --update --oneshot kmod.

best ... khay

----------

## jyoung

khayyam, I'm happy to make those changes, but if kmod is not longer in the tree then maybe I should switch to something else - you mentioned module-init-tools?  I'm not actually aware of what the merits of either one are; I'll look them up today when I get to work.

----------

## BillWho

jyoung,

The output of ls -l /lib/modules/$(uname -r)  is quite revealing. These files should all have the same date yet module.dep is dated Aug  1 21:15 along with several others with an August time stamp. This indicates that these August files were not updated when you compiled the kernel and would explain the problem with loading modules. 

I see khayyam has already advised on a course of action so we'll leave it at that for now and see what happens   :Wink: 

----------

## khayyam

 *jyoung wrote:*   

> I'm happy to make those changes, but if kmod is not longer in the tree then maybe I should switch to something else - you mentioned module-init-tools?  I'm not actually aware of what the merits of either one are; I'll look them up today when I get to work.

 

jyoung ... no, I said that particular package-version was removed, kmod is still in tree with kmod-10 being the current version (note kmod isn't stablised, so these packages are keyworded ~arch). I made it clear that the package could be updated when I wrote "edit /etc/portage/package.accept_keywords if your keywording on that particular version, and emerge --update --oneshot kmod" ... I suspect you have '=sys-apps/kmod=9-r2' in package.accept_keywords which would explain why you still have the broken package and why it wasn't updated after it was removed.

best ... khay

----------

## jyoung

Hey, thanks folks for the fix!  With the update to kmod I recompiled my kernel and, after rebooting, iwlwifi loaded just fine as a module.

With that more serious problem out of the way, I'm interested in the wpa_supplicant issue.  With iwlwifi as a module, I was able to use the '-Dnl80211' option instead of '-Dwext'.  Unfortunately, that doesn't seem to have affected my connectivity.  I'm still getting a spotty connection that drops after a few minutes on the secured network (at work).  With the modifications to wpa_supplicant.conf that khayyam suggested last week (thanks), I did the experiment of connecting to other secured networks.  Surprisingly, that worked just fine.  It seems like it's just this one network (or kind of network) that's giving me trouble.

There's a couple of ideas that some of you posted about on October 7th.  I'm planning on exploring those this afternoon, and I'll post back when I have results.

----------

## khayyam

 *jyoung wrote:*   

> Hey, thanks folks for the fix!  With the update to kmod I recompiled my kernel and, after rebooting, iwlwifi loaded just fine as a module.

 

jyoung ... ok, good.

 *jyoung wrote:*   

> With that more serious problem out of the way, I'm interested in the wpa_supplicant issue.  With iwlwifi as a module, I was able to use the '-Dnl80211' option instead of '-Dwext'.  Unfortunately, that doesn't seem to have affected my connectivity.  I'm still getting a spotty connection that drops after a few minutes on the secured network (at work).  With the modifications to wpa_supplicant.conf that khayyam suggested last week (thanks), I did the experiment of connecting to other secured networks.  Surprisingly, that worked just fine.  It seems like it's just this one network (or kind of network) that's giving me trouble.

 

This suggests that the issue isn't with powersave, this would effect all connections and not simply one network. Is the problem AP's ESSID hidden, or are there multiple AP's with the same ESSID (some sort of WDS setup)? If so try adding "ap_scan=2" to wpa_supplicant.conf. Also, what sort of network is this (A,G,N ... A,G ... N only), some AP's have issues with N clients. You can disable N by passing "11n_disable=1"

/etc/modprobe.d/iwlwifi.conf

```
options iwlwifi 11n_disable=1
```

or via modprobe ...

```
# modprobe -r iwlwifi && modprobe iwlwifi 11n_disable=1
```

 *jyoung wrote:*   

> There's a couple of ideas that some of you posted about on October 7th.  I'm planning on exploring those this afternoon, and I'll post back when I have results.

 

If you are talking about kernel options re powersave then this is looking less likely. I'm inclined to think the issue is something specific to the AP.

best ... khay

----------

## jyoung

I agree; yesterday and today I tried first disabling CONFIG_CFG80211_DEFAULT_PS and then disabling CONFIG_CFG80211_WEXT.  There might be a *slight* improvement, but with spotty connections, it's hard to say.  I'd have to collect data for a few days on how long I remain connected before I get dropped, but in any case the connectivity isn't great and it certainly isn't much of an inprovement over what it was before.

I'm in a situation where there are multiple AP with the same ESSID.  What is the functional meaning of 'ap_scan=2'?

I'm actually not sure what kind of network it is - can I tell from iwlist?  I found the thread from the October 7 post really interesting.  It would be too bad if I couldn't take advantage of N speed, but at this point I'm more interested in having a reliable connection.

----------

## khayyam

 *jyoung wrote:*   

> I agree; yesterday and today I tried first disabling CONFIG_CFG80211_DEFAULT_PS and then disabling CONFIG_CFG80211_WEXT.  There might be a *slight* improvement, but with spotty connections, it's hard to say.  I'd have to collect data for a few days on how long I remain connected before I get dropped, but in any case the connectivity isn't great and it certainly isn't much of an inprovement over what it was before.

 

jyoung ... in my case (ath5k) with CFG80211_DEFAULT_PS the card isn't put into powesave mode automatically:

```
# iw dev wlan0 get power_save

Power save: off
```

... this may not be the case with iwlwifi, but the point is there is a common symptom of disassoc with powersave. Again, I don't think this is the reason your connection to that one AP drops, as the symptom would be seen with other AP's. 

 *jyoung wrote:*   

> I'm in a situation where there are multiple AP with the same ESSID.  What is the functional meaning of 'ap_scan=2'?

 

OK, I'm fairly certain this is whats causing the disassoc. 0 = no scanning, 1 = wpa_supplicant requests scan and uses the results to select the AP, 2 = wpa_supplicant does not scan but just requests to associate. When the AP doesn't broadcast its ESSID or there are multiple BSSID's for the same ESSID, then scanning either isn't going to provide any usefull information (as in the case of a hidden ESSID), or in the case of WDS the BSSID will not allow wpa_supplicant to disambiguate the network. I'm not altogether sure what happens but I believe that with ap_scan=2 wpa_supplicant will be less likely to get confused when the BSSID doesn't match the ESSID. Its actually an area I need to do more research on.

 *jyoung wrote:*   

> I'm actually not sure what kind of network it is - can I tell from iwlist?  I found the thread from the October 7 post really interesting.  It would be too bad if I couldn't take advantage of N speed, but at this point I'm more interested in having a reliable connection.

 

You mean if the AP is set for N only or mixed A,G,N? Well, I imagine you would see "HT40" for 802.11n and "HT20/HT40" for mixed, in the output of 'iw dev wlan0 scan'. Anyhow, you should really read a little about how 802.11n produces the high throughput, and the reality of the claims being made for it.

best ... khay

----------

## jyoung

Well folks, I think disabling N did it.  I tried it on Monday, and had success for most of the day.  At the end I lot and regained the connection many times in 10 minutes, right before I had to leave.  Because of this, I gave it another trial today, and had no issues.  I can report back in a few days to confirm and log this thread as solved, but it's looking good.  khayyam, good call (an interesting link).

I also tried 'ap_scan=2' on Monday.  Oddly enough, this prevented me from connecting at all.

Also, before we close this out, wrc1944 mentioned a while back having issues with wicd or networkmanager configuration files around. I should probably ask, has anyone had issues with high-level packages depending on networkmanager?  During my last world update, networkmanager kept getting pulled in because things like banshee depend on it.  This kind of baffles me, and it's rather annoying since I don't really like networkmanager.  Nothing against it, but it can't run without X (last time I checked), and I have had issues involving it interfering with other software (iwconfig, in that case).

----------

## khayyam

 *jyoung wrote:*   

> I think disabling N did it.

 

jyoung ... ok, well, hopefully that is the case.

 *jyoung wrote:*   

> I also tried 'ap_scan=2' on Monday.  Oddly enough, this prevented me from connecting at all.

 

I see, I should have perhaps also mentioned providing 'scan_ssid=1' in the 'network={}' block. This should make wpa_supplicant omit the broadcast, and skip straight to associate (note if doing this you need to provide 'key-mgmt=', 'group=', 'pairwise=', and 'proto=' for that network). As I said, this is an area I need to research more, but the above should work (at least it has for me), though I tend to keep only one network 'enabled' (meaning, the AP I intend to connect to is 'disabled=0' and the others are 'disabled=1' which may play some role in the matter). 

 *jyoung wrote:*   

> Also, before we close this out, wrc1944 mentioned a while back having issues with wicd or networkmanager configuration files around. I should probably ask, has anyone had issues with high-level packages depending on networkmanager?  During my last world update, networkmanager kept getting pulled in because things like banshee depend on it.  This kind of baffles me, and it's rather annoying since I don't really like networkmanager.  Nothing against it, but it can't run without X (last time I checked), and I have had issues involving it interfering with other software (iwconfig, in that case).

 

No idea, I don't have anything installed that uses NetworkManager, *kit, dbus, etc, etc.

best ... khay

----------

## DONAHUE

@jyoung is networkmanager in your USE flags? if so any package that has it as option ..

some packages may have a builtin non-fatal conditional/preferential dependency at runtime to call networkmanager

----------

## jyoung

Hey Folks,

It's been over two weeks, and my connection is still solid.  I'm going to list this thread as solved.  Thanks for all the help!

DONAHUE, I did find networkmanager in my USE flags, thanks!

To sum up for any future readers of this thread, the instabilities in the wireless connection were resolved by forcing the driver to not connect at N speeds, even though the wireless card is an N-speed card.

----------

## solamour

I guess my case is a little bit different from the OP's issue, but here is something that worked just in case it affects others. I kept getting the following error message (I masked the MAC and SSID to protect the innocent).

```
% wpa_supplicant -iwlo1 -Dnl80211 -cwpa.conf

Successfully initialized wpa_supplicant

wlo1: SME: Trying to authenticate with --:--:--:--:--:-- (SSID='' freq=2412 MHz)

wlo1: Trying to associate with --:--:--:--:--:-- (SSID='' freq=2412 MHz)

wlo1: Associated with --:--:--:--:--:--

wlo1: CTRL-EVENT-DISCONNECTED bssid=--:--:--:--:--:-- reason=3 locally_generated=1

```

It turned out that "/etc/init.d/NetworkManager" was running, so once I turned it off, everything worked OK.

__

sol

----------

