WPA_supplicant trouble connecting client to AP
Francisco Cuesta
ndarkness
Tue May 21 03:11:06 PDT 2013
2013/5/16 Dan Williams <dcbw at redhat.com>:
> 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
>
I have tried to leave out that parameter but without success, which
according to openWRT people, this value is set when the client fix the
channel to work in.
On the other hand, has wpa_supplicant a way of selecting a default
frequency in case some error occurs?? I mean, for instance if you try
to set a wrong frequency or channel, wpa can change it for a default
one like for instance the channel 34??
I tell this because, I'm experiencing a weird behaviour, my AP is on
4915MHz, as you can see below
Completing interface initialization
1315508363.989115: Mode: IEEE 802.11a Channel: 183 Frequency: 4915 MHz
1315508363.989470: nl80211: Set freq 4915 (ht_enabled=0 sec_channel_offset=0)
However, in the client, I get a complete different frequency of the BSS
lan1: State: SCANNING -> AUTHENTICATING
1315509514.527299: nl80211: Authenticate (ifindex=13)
1315509514.527333: * bssid=xx:xx:xx:xx:xx:xx
1315509514.527376: * freq=5180
1315509514.527401: * SSID - hexdump_ascii(len=18):
What is this due to???
Thanks in advance!
More information about the Hostap
mailing list