I found the source of this issue. There were several kernel components related to encryption that were were missing. The main one was CONFIG_CRYPTO_AES, without which, the last step of the WPA 4-way handshake could not complete the encryption it needed as the cipher is requested from the kernel. The cipher is requested by name (&quot;aes&quot;) so the only manifests in real time. The highest level error message ( set_key failed; err=-2 )was actually partially misleading. The ENOENT code did trace all the way to the original source but it wasn&#39;t set_key, it was nl80211_new_key.<div>
<br></div><div>I now have a WPA encryption working on the WL1271L radio on the AM3517 Processor (Logic SOM) with the TI 05.05 SDK. Hopefully the patch can get added to the next TI PSP release.</div><div><br></div><div>Thanks to Dan for the push in the right direction.</div>
<div>.</div><div><br></div><div><br><div class="gmail_quote">On Mon, Oct 22, 2012 at 12:41 AM, Jemiah Aitch <span dir="ltr">&lt;<a href="mailto:jemiaha@gmail.com" target="_blank">jemiaha@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dan,<div>  Thanks for the advice. I did try looking at the nl80211_set_key function. I found every function in the netlink source that returned ENOENT but it was none of them. The odd thing is that, though the error message says &quot;set_key&quot; failed, the actually function call in the supplicant that failed was send_and_recv_msgs() in driver_nl80211.c.  It actually calls send_and_recv() and that&#39;s where the action gets hard to follow. Some asynchronous handlers are setup (error_handler, finish_handler, ack_handler) and the call that actually causes the error code is nl_recvmsgs even though it returns 0. It seems recvmsgs() in the NetLink library code calls the error handler (libnl2-0  lib/nl.c:641) because the kernel reported an error with a valid message. The error seems to come from net/netlink/af_netlink.c:netlink_ack in the kernel bu that could come from a few places. I&#39;m still pulling the stack trace apart to see WTH happened. I&#39;m betting it&#39;s some kind of library mismatch or missing library but it&#39;s not going quietly. I&#39;m still digging.<br>

<br>Thanks</div><div>.</div><div class="HOEnZb"><div class="h5"><div><br></div><div><br><div class="gmail_quote">On Thu, Oct 18, 2012 at 10:34 AM, Dan Williams <span dir="ltr">&lt;<a href="mailto:dcbw@redhat.com" target="_blank">dcbw@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Wed, 2012-10-17 at 13:42 -0500, Jemiah Aitch wrote:<br>
&gt; I have an issue using wpa_supplicant but I can&#39;t say for sure if it’s<br>
&gt; a configuration issue or a problem with the kernel it’s running on.<br>
&gt; I’m hoping someone on this might recognize the issue. I’m running<br>
&gt; version wpa_supplicant version 0.7.3 on linux 2.6.37 on the AM3517<br>
&gt; processor (TI SDK 05.05). The published SDK didn&#39;t include wireless<br>
&gt; support and I&#39;ve been adding it for the WL1271L radio. So far I have<br>
&gt; it working well enough that I can connect to an unsecured access point<br>
&gt; using wpa_supplicant but when I try to connect to a WPA secured access<br>
&gt; point there seems to be an error accessing something the supplicant<br>
&gt; needs to complete the connection. I added the -dd option to the<br>
&gt; arguments and ran it in the foreground to catch the following error:<br>
&gt;<br>
&gt; State: 4WAY_HANDSHAKE -&gt; 4WAY_HANDSHAKE<br>
&gt; WPA: RX message 3 of 4-Way Handshake from 98:fc:11:8c:8b:60 (ver=2)<br>
&gt; WPA: IE KeyData - hexdump(len=72): <a href="tel:30%2018%2001%2000%2000" value="+13018010000" target="_blank">30 18 01 00 00</a> 0f ac 02 02 00 00 0f<br>
&gt; ac 04 00 0f ac 02 01 00 00 0f ac 02 0c 00 dd 26 00 0f ac 01 01 00 9b<br>
&gt; 77 dc 4d c7 96 80<br>
&gt; WPA: RSN IE in EAPOL-Key - hexdump(len=26): <a href="tel:30%2018%2001%2000%2000" value="+13018010000" target="_blank">30 18 01 00 00</a> 0f ac 02 02<br>
&gt; 00 00 0f ac 04 00 0f ac 02 01 00 00 0f ac 02 0c 00<br>
&gt; WPA: GTK in EAPOL-Key - hexdump(len=40): [REMOVED]<br>
&gt; WPA: Sending EAPOL-Key 4/4<br>
&gt; WPA: TX EAPOL-Key - hexdump(len=99): …....... (I just chopped this<br>
&gt; off)<br>
&gt; WPA: Installing PTK to the driver.<br>
&gt; wpa_driver_nl80211_set_key: ifindex=5 alg=3 addr=0x65888 key_idx=0<br>
&gt; set_tx=1 seq_len=6 key_len=16<br>
&gt;   addr=98:fc:11:8c:8b:60<br>
&gt; nl80211: set_key failed; err=-2 No such file or directory)<br>
&gt; WPA: Failed to set PTK to the driver (alg=3 keylen=16<br>
&gt; bssid=98:fc:11:8c:8b:60)<br>
&gt; wpa_driver_nl80211_deauthenticate<br>
&gt; [  144.573486] cfg80211: Calling CRDA to update world regulatory<br>
&gt; domain<br>
&gt;<br>
&gt; Has anyone ever seen an error like this? It looks like something in<br>
&gt; Netlink (set_key) can’t find a file or resource of some kind. If<br>
&gt; anyone has any advice I&#39;d love to hear it.<br>
<br>
</div></div>-2 == ENOENT; which is just a generic POSIX error code.  Most of the<br>
kernel uses these types of error codes; see /usr/include/errno.h or with<br>
glibc, /usr/include/asm-generic/errno-base.h.  ENOENT just means &quot;the<br>
thing you wanted can&#39;t be found or doesn&#39;t exist&quot;.  It actually doesn&#39;t<br>
have much to do with files or directories.<br>
<br>
What you need to do is jump into cfg80211 and find out why set_key is<br>
failing.  See the kernel sources in net/wireless/nl80211.c where you&#39;ll<br>
find:<br>
<br>
        {<br>
                .cmd = NL80211_CMD_SET_KEY,<br>
                .doit = nl80211_set_key,<br>
                .policy = nl80211_policy,<br>
                .flags = GENL_ADMIN_PERM,<br>
                .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |<br>
                                  NL80211_FLAG_NEED_RTNL,<br>
        },<br>
<br>
so that means the set_key() call from the supplicant ends up in<br>
nl80211_set_key() in the kernel.  What you want to do is figure out what<br>
piece of that function returns ENOENT, and then trace that down and find<br>
out where the error is getting returned.  It might be returned from<br>
stuff in net/mac80211/ or even stuff in the TI driver.<br>
<span><font color="#888888"><br>
Dan<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>