WPA_supplicant trouble connecting client to AP
Dan Williams
dcbw
Thu May 16 08:06:44 PDT 2013
On Thu, 2013-05-16 at 10:41 +0200, Francisco Cuesta wrote:
> 2013/5/15 Dan Williams <dcbw at redhat.com>:
> > On Wed, 2013-05-15 at 16:44 +0200, Francisco Cuesta wrote:
> >> 2013/5/15 Dan Williams <dcbw at redhat.com>:
> >> > On Wed, 2013-05-15 at 16:17 +0200, Francisco Cuesta wrote:
> >> >> 2013/5/15 Dan Williams <dcbw at redhat.com>:
> >> >> > On Wed, 2013-05-15 at 14:01 +0200, Francisco Cuesta wrote:
> >> >> >> Hi Jouni,
> >> >> >>
> >> >> >> >Which wpa_supplicant are you using?
> >> >> >>
> >> >> >> I'm currently using wpa_supplicant v2.0-devel
> >> >> >>
> >> >> >> >What is this fixed_freq parameter? It sounds like this wpa_supplicant
> >> >> >> >version has some changes that do not exist in hostap.git and as such, it
> >> >> >> >is unclear how it behaves.
> >> >> >>
> >> >> >> This parameters I think represent that the frequency of the AP is
> >> >> >> already fixed. This wpa_supplicant configuration file is parsed from a
> >> >> >> generic wpa_supplicant configuration, this is done in this way in
> >> >> >> OpenWRT; they launches hostapd which parses this generic file and
> >> >> >> calls wpa_supplicant with it.
> >> >> >
> >> >> > His point is that fixed_freq is *not* an option in the official
> >> >> > hostap/wpa_supplicant sources, so whatever you're running, it's been
> >> >> > modified by whoever you got it from.
> >> >> >
> >> >>
> >> >>
> >> >> >> >How do you know what it does after this? The -B option on the command
> >> >> >> >line requests wpa_supplicant to move into the background and that stops
> >> >> >> >the debug log to stdout. If you want to see after this, you would need
> >> >> >> >to either direct the log to a file or syslog or remove the -B option.
> >> >> >>
> >> >> >> I've followed your advice, and I have disabled the -B option and now I
> >> >> >> get more output once I launch wpa_supplicant, which is this one
> >> >> >>
> >> >> >> wlan1: State: DISCONNECTED -> SCANNING
> >> >> >> Scan SSID - hexdump_ascii(len=18):
> >> >> >> 69 72 74 2d 61 68 2d 69 6e 72 69 61 2d 73 69 65 X-X-X-X
> >> >> >> 62 65 -X
> >> >> >> wlan1: Starting AP scan for wildcard SSID
> >> >> >> nl80211: Scan SSID - hexdump_ascii(len=18):
> >> >> >> 69 72 74 2d 61 68 2d 69 6e 72 69 61 2d 73 69 65 X-X-X-X
> >> >> >> 62 65 -X
> >> >> >> nl80211: Scan SSID - hexdump_ascii(len=0): [NULL]
> >> >> >> Scan requested (ret=0) - scan timeout 30 seconds
> >> >> >> nl80211: Event message available
> >> >> >> nl80211: Scan trigger
> >> >> >> RTM_NEWLINK: operstate=0 ifi_flags=0x1003 ([UP])
> >> >> >> netlink: Operstate: linkmode=-1, operstate=6
> >> >> >> The num-Xr of sent bytes in netlink_send_oper_ifla are 37
> >> >> >> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan1' added
> >> >> >> nl80211: if_removed already cleared - ignore event
> >> >> >> nl80211: Event message available
> >> >> >> nl80211: New scan results available
> >> >> >> wlan1: Event SCAN_RESULTS (3) received
> >> >> >> nl80211: Received scan results (1 BSSes)
> >> >> >> wlan1: BSS: Start scan result update 6
> >> >> >> BSS: last_scan_res_used=1/32 last_scan_full=0
> >> >> >> wlan1: New scan results available
> >> >> >> wlan1: Selecting BSS from priority group 0
> >> >> >> wlan1: 0: 64:70:02:3e:a7:82 ssid='X-X-X-X-X' wpa_ie_len=0 rsn_ie_len=0
> >> >> >> caps=0x1 level=-70
> >> >> >> A BSSID in blacklist is this: 4896660
> >> >> >> The BSSID of blacklist selected is this: 4896660
> >> >> >
> >> >> > These messages are also not part of official hostap/wpa_supplicant, so
> >> >> > your version has been patched by somebody, and that may be introducing
> >> >> > new bugs.
> >> >> >
> >> >>
> >> >> What messages do you refer to? The X-X-X... which appears there, I
> >> >> have set it by myself, as well I have put some extra printf in the
> >> >> code to see the running sequence
> >> >
> >> > I mean the "A BSSID in the blacklist" messages. Are those your local
> >> > modifications?
> >> >
> >>
> >> Yes they're, I added a prinrf on the code.
> >>
> >> >> >> wlan1: skip - blacklisted (count=1 limit=0)
> >> >> >> wlan1: No APs found - clear blacklist and try again
> >> >> >> Removed BSSID 64:70:02:3e:a7:82 from blacklist (clear)
> >> >> >> wlan1: Selecting BSS from priority group 0
> >> >> >> wlan1: 0: 64:70:02:3e:a7:82 ssid='X-X-X-X-X' wpa_ie_len=0 rsn_ie_len=0
> >> >> >> caps=0x1 level=-70
> >> >> >> wlan1: allow in non-WPA/WPA2
> >> >> >> The channel that wpa_s struct has got is 36
> >> >> >> The frequency that wpa_s struct has got is 5180 MHz
> >> >> >> The set channel on rate_match function is 2364476
> >> >> >> The set frequency on rate_match function is 5180 MHz
> >> >> >> The set frequency on rate_match function is 5180 MHz
> >> >> >> The comparison freq == bss->freq is true
> >> >> >> wlan1: selected BSS 64:70:02:3e:a7:82 ssid='X-X-X-X-X'
> >> >> >> wlan1: Request association: reassociate: 0 selected:
> >> >> >> 64:70:02:3e:a7:82 bssid: 00:00:00:00:00:00 pending:
> >> >> >> 00:00:00:00:00:00 wpa_state: SCANNING
> >> >> >> wlan1: Automatic auth_alg selection: 0x1
> >> >> >> wlan1: WPA: clearing AP WPA IE
> >> >> >> wlan1: WPA: clearing AP RSN IE
> >> >> >> wlan1: WPA: clearing own WPA/RSN IE
> >> >> >> wlan1: Cancelling scan request
> >> >> >> wlan1: SME: Trying to authenticate with 64:70:02:3e:a7:82
> >> >> >> (SSID='X-X-X-X-X' freq=5180 MHz)
> >> >> >> wlan1: No keys have -Xen configured - skip key clearing
> >> >> >> wlan1: State: SCANNING -> AUTHENTICATING
> >> >> >> nl80211: Authenticate (ifindex=33)
> >> >> >> * bssid=64:70:02:3e:a7:82
> >> >> >> * freq=5180
> >> >> >> * SSID - hexdump_ascii(len=18):
> >> >> >> 69 72 74 2d 61 68 2d 69 6e 72 69 61 2d 73 69 65 X-X-X-X
> >> >> >> 62 65 -X
> >> >> >> * IEs - hexdump(len=0): [NULL]
> >> >> >> * Auth Type 0
> >> >> >> nl80211: Authentication request send successfully
> >> >> >> wlan1: Checking for other virtual interfaces sharing same radio (phy1)
> >> >> >> in event_scan_results
> >> >> >> nl80211: Event message available
> >> >> >> nl80211: New station 64:70:02:3e:a7:82
> >> >> >> nl80211: Event message available
> >> >> >> nl80211: Delete station 64:70:02:3e:a7:82
> >> >> >> nl80211: Event message available
> >> >> >> nl80211: MLME event 37; timeout with 64:70:02:3e:a7:82
> >> >> >> wlan1: Event AUTH_TIMED_OUT (14) received
> >> >> >> wlan1: SME: Authentication timed out
> >> >> >
> >> >> > This indicates that the kernel driver has not been able to authenticate
> >> >> > with the AP, so the problem may be due to kernel driver issues. Which
> >> >> > kernel are you using and which wifi driver?
> >> >> >
> >> >>
> >> >> I'm using a linux kernel which is 3.3.8. The wifi devices are an
> >> >> atheros AR9341 (integrated
> >> >> 2.4ghz) + AR9580 (5ghz) (onboard), both devices are managed with ath9k
> >> >> driver plus compat wireless drivers called compat-wireless-2012-09-07.
> >> >
> >> > That kernel version is pretty old; are you able to try a newer one like
> >> > 3.8.x or 3.9.x? Plus you might want to update your compat-wireless as
> >> > well; a lot happens in 8 months. In any case, I'm not as familiar with
> >> > the ath9k drivers as Jouni or others are so I'll let them answer about
> >> > the state of compat-wireless from Sept 2012 and the 3.3.8 kernel.
> >> >
> >> I see, I'm afraid not, because that is the kernel that the latest
> >> version of openwrt has, and I don't now how it might be updated.
> >> Thanks for your replies, I'll wait for their replies in such a
> >> matters.
> >>
> >>
> >> >> Could you tell me where in the kernel driver are defined the channels
> >> >> that might be authenticated with the AP?
> >> >
> >> > It's a state machine, so there aren't any channels. The kernel driver
> >> > and the kernel mac80211 stack do quite a few operations during the
> >> > association process so if you're able to turn on kernel debugging, or if
> >> > you have any kernel log messages from 'dmesg' that would be helpful.
> >> >
> >> I have issued the dmesg command getting this
> >>
> >> wlan1: authentication with 64:70:02:3e:a7:82 timed out
> >> [ 191.470000] wlan1: authenticate with 64:70:02:3e:a7:82
> >> [ 191.480000] wlan1: send auth to 64:70:02:3e:a7:82 (try 1/3)
> >> [ 191.700000] wlan1: send auth to 64:70:02:3e:a7:82 (try 2/3)
> >> [ 191.910000] wlan1: send auth to 64:70:02:3e:a7:82 (try 3/3)
> >> [ 192.120000] wlan1: authentication with 64:70:02:3e:a7:82 timed out
> >> [ 195.590000] wlan1: authenticate with 64:70:02:3e:a7:82
> >> [ 195.600000] wlan1: send auth to 64:70:02:3e:a7:82 (try 1/3)
> >> [ 195.820000] wlan1: send auth to 64:70:02:3e:a7:82 (try 2/3)
> >> [ 196.030000] wlan1: send auth to 64:70:02:3e:a7:82 (try 3/3)
> >
> > Yeah, this says that the driver doesn't see any response from the AP.
> > The next thing you get to do is to sniff frames using a different
> > machine to see if the AP actually does reply, which would indicate that
> > the driver is busted. But again, a driver/stack from Sept 2012 is
> > pretty old, and if there was a bug, it may well have been fixed long
> > since.
> >
>
> I see , another question, can this error be also due to the client
> frequency is different from the AP one? I say this, because I've seen
> on the wpa supplicant debug
>
> nl80211: Authenticate (ifindex=17)
> * bssid=64:70:02:3e:a7:82
> * freq=5180 <----------------------------------------THIS
The frequency should be found from the scan results; what results do you
get when you run the supplicant with "-dddt"? It should print out the
frequency then.
But also, do you still have the "fixed_freq=1" parameter? No idea what
that is, it's not part of the official hostap, so you might as well
remove it. It appears to be have been a proposed patch that was
rejected, plus that patch was only meant for IBSS mode, not STA mode:
http://lists.shmoo.com/pipermail/hostap/2012-June/026056.html
Dan
> But such a frequency is not the one in which the AP is working
> in...I've read that wpa_supplicant wpa_ssid->frequency always starts
> in the initial channel of the working band, so I guess that as the
> possible reason for the above frequency, but I'm not sure since that
> frequency is set in the driver (nl80211), isn't it?
>
> Thanks
>
> > Dan
> >
> >> ... and so on
> >>
> >> but I think that is not enough, so I'll need a way of enabling debug
> >> mode on my system.
> >>
> >>
> >>
> >> > Dan
> >> >
> >> >> Ps: sorry for the triple post, but I didn't reply well to all the
> >> >> members of the mail.
> >> >>
> >> >> > Dan
> >> >> >
> >> >> >> Added BSSID 64:70:02:3e:a7:82 into blacklist
> >> >> >> wlan1: Setting scan request: 0 sec 100000 usec
> >> >> >> wlan1: State: AUTHENTICATING -> DISCONNECTED
> >> >> >> wpa_driver_nl80211_set_operstate: operstate 0->0 (DORMANT)
> >> >> >> The linkmode=-1 is set on wpa_driver_nl80211_set_operstate
> >> >> >> netlink: Operstate: linkmode=-1, operstate=5
> >> >> >> The num-Xr of sent bytes in netlink_send_oper_ifla are 37
> >> >> >> wlan1: State: DISCONNECTED -> SCANNING
> >> >> >> _______________________________________________
> >> >> >> HostAP mailing list
> >> >> >> HostAP at lists.shmoo.com
> >> >> >> http://lists.shmoo.com/mailman/listinfo/hostap
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
More information about the Hostap
mailing list