[Solved] wpa_supplicant unable to connect to ap

[TotallyNotTom]

Hi all,
for a background story: I've recently migrated from archlinux to gentoo, following both the official guide
as well as sakaki's guide about dualbooting gentoo and windows.
At the end of the day I had a working setup with i3-wm and wireless connection via dhcpcd and wpa_supplicant as proposed in the wiki.
However since then I have done (possible bad) things to my kernel config and I crashed once, where I had to hard reset the laptop.
After said crash my wireless interface wasn't able to establish any connection.
Things I tried already, which did not work or lead to any additional clues:

• Revert to an old kernel, where iirc the wireless connection was working.
  
• Re-emerge both wpa_supplicant and dhcpcd.
  
• Look for possible blocks of the interface with rfkill, there were none.
  
• Check if the interface in general was operating, scanning for nearby APs works and displays correct results.
  

I followed the advice in https://wiki.gentoo.org/wiki/Wpa_supplicant#Troubleshooting however I have no clue about what
most of the things in the log mean, a full cycle of the stdout is located over at this pastebin because its too large for a code field here.

All I can read from it is that it apperantly fails at something called 4-way handshake. However I am afraid I have too little understanding to quickly get the grasp of what that means.
It looks like its even able to establish a connection to my AP but then fails because of some ?protocol mismatch?
Oddly enough this sounds to me like it could be related to kernel configuration again, however I don't know where to look for the error.

When searching for this error I get only found some forum posts where the error magically disappears or something related to other things like soft blocked devices etc.

In case it has anything of value in it, here is the lspci:

[Ant P.]

90% of the time that error just means a password typo.

[TotallyNotTom]

Oh I am pretty sure its not a typo, ive tried to connect to various different networks using plain PSKs and hashed ones from wpa_passphrase none worked

And a typo wouldn't just sneak itself into a config that worked before, I think, or hope.

Nevertheless, yet another try, here I come!

[TotallyNotTom]

Alright, I don't know why this didn't occur to me before, but I just tried connecting to an unprotected AP
and it established a working connection like it should

However trying it with a WPA2 PSK setup on the same AP, I wasn't able to connect
and I just used some generic test password to eliminate all possible typos with that one.

[Ant P.]

Just noticed this:

[mir3x]

Check this maybe :
https://bbs.archlinux.org/viewtopic.php?id=170656
_________________
Sent from Windows

[Logicien]

According to Linux WiFi: Deauthenticated Reason Codes Reason=1 is an unknown reason.

Your running kernel and your wpa_supplicant.conf configuration files are needed to help. Of course the iwlwifi need firmware files who must be always present in the root file system (/lib/firmware/iwlwifi*) and in the initramfs if you put iwlwifi module in it or the kernel image if you put the Intel support in the kernel image. iwlwifi need those firmware files when it probe the device, otherwise it may fail to do it.

The best in my opinion is to compile Intel wireless iwlwifi in module and not include it in an initramfs.

iwlwifi have a parameter 11n_disable that ever solve me a problem of connecting in the past. So, you can try to disable 80211 n support. Be sure that this file do not already exist and the option 11n_disable is not set to something else than 1 in a file in /etc/modprobe.d/.

[TotallyNotTom]

Hurray, it's solved I can connect again.

It actually was me being derpy or not looking closely enough at what sakaki did with his buildkernel script.
Somewhere in the config an option was enabled to include all modules into the initramfs. As my initramfs is on an external flashdrive that was kinda dumb