Supplicant Can't Make a Connection to a WPA Secured Access Point.
Sun Oct 21 22:41:17 PDT 2012
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
"set_key" 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'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'm still pulling the stack
trace apart to see WTH happened. I'm betting it's some kind of library
mismatch or missing library but it's not going quietly. I'm still digging.
On Thu, Oct 18, 2012 at 10:34 AM, Dan Williams <dcbw at redhat.com> wrote:
> On Wed, 2012-10-17 at 13:42 -0500, Jemiah Aitch wrote:
> > I have an issue using wpa_supplicant but I can't say for sure if it?s
> > a configuration issue or a problem with the kernel it?s running on.
> > I?m hoping someone on this might recognize the issue. I?m running
> > version wpa_supplicant version 0.7.3 on linux 2.6.37 on the AM3517
> > processor (TI SDK 05.05). The published SDK didn't include wireless
> > support and I've been adding it for the WL1271L radio. So far I have
> > it working well enough that I can connect to an unsecured access point
> > using wpa_supplicant but when I try to connect to a WPA secured access
> > point there seems to be an error accessing something the supplicant
> > needs to complete the connection. I added the -dd option to the
> > arguments and ran it in the foreground to catch the following error:
> > State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE
> > WPA: RX message 3 of 4-Way Handshake from 98:fc:11:8c:8b:60 (ver=2)
> > WPA: IE KeyData - hexdump(len=72): 30 18 01 00 00 0f ac 02 02 00 00 0f
> > ac 04 00 0f ac 02 01 00 00 0f ac 02 0c 00 dd 26 00 0f ac 01 01 00 9b
> > 77 dc 4d c7 96 80
> > WPA: RSN IE in EAPOL-Key - hexdump(len=26): 30 18 01 00 00 0f ac 02 02
> > 00 00 0f ac 04 00 0f ac 02 01 00 00 0f ac 02 0c 00
> > WPA: GTK in EAPOL-Key - hexdump(len=40): [REMOVED]
> > WPA: Sending EAPOL-Key 4/4
> > WPA: TX EAPOL-Key - hexdump(len=99): ?....... (I just chopped this
> > off)
> > WPA: Installing PTK to the driver.
> > wpa_driver_nl80211_set_key: ifindex=5 alg=3 addr=0x65888 key_idx=0
> > set_tx=1 seq_len=6 key_len=16
> > addr=98:fc:11:8c:8b:60
> > nl80211: set_key failed; err=-2 No such file or directory)
> > WPA: Failed to set PTK to the driver (alg=3 keylen=16
> > bssid=98:fc:11:8c:8b:60)
> > wpa_driver_nl80211_deauthenticate
> > [ 144.573486] cfg80211: Calling CRDA to update world regulatory
> > domain
> > Has anyone ever seen an error like this? It looks like something in
> > Netlink (set_key) can?t find a file or resource of some kind. If
> > anyone has any advice I'd love to hear it.
> -2 == ENOENT; which is just a generic POSIX error code. Most of the
> kernel uses these types of error codes; see /usr/include/errno.h or with
> glibc, /usr/include/asm-generic/errno-base.h. ENOENT just means "the
> thing you wanted can't be found or doesn't exist". It actually doesn't
> have much to do with files or directories.
> What you need to do is jump into cfg80211 and find out why set_key is
> failing. See the kernel sources in net/wireless/nl80211.c where you'll
> .cmd = NL80211_CMD_SET_KEY,
> .doit = nl80211_set_key,
> .policy = nl80211_policy,
> .flags = GENL_ADMIN_PERM,
> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
> so that means the set_key() call from the supplicant ends up in
> nl80211_set_key() in the kernel. What you want to do is figure out what
> piece of that function returns ENOENT, and then trace that down and find
> out where the error is getting returned. It might be returned from
> stuff in net/mac80211/ or even stuff in the TI driver.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Hostap