Re: HEADSUP: new ath+hal

Yamamoto Shigeru wrote:
> Hi, sam,
> 
> I install 20060130 current to same note PC to compare 'current 20060130' and
> 'current 20060222'.
> After installing, I watch control message with
>  'tcpdump -n -i ath0 -y IEEE802_11'.
> 
> When using '20060130 current', I can watch "Probe request" from my note PC.
> But I can't watch "Probe request" when using '20060222 current'.
> 
> I add 'printf()' to codes and I check when 'IEEE80211_CHAN_PASSIVE' is set.
> I found ath_getchannels() at _at_src/sys/dev/ath/if_ath.c sets
> 'IEEE80211_CHAN_PASSIVE', because 'CHANNEL_PASSIVE' in channelFlags is set.
> 
> I think ath driver send "Probe request" if ignore 'CHANNEL_PASSIVE' in
> channelFlags.
> So I add a code to ignore 'CHANNEL_PASSIVE' and to unset
> 'IEEE80211_CHAN_PASSIVE'.
> I test this test code at "broadcast SSID in beacon", and my note PC can
> associate an AP.
> 
> It seems me current ath hal returns 'CHANNEL_PASSIVE' for all channels.
> In _at_src/sys/contrib/dev/ath/ah.h, comment for 'CHANNEL_PASSIVE' is "Only
> passive scan allowed in the channel".
> Does it mean my note PC can't send a probe message?

Thanks for digging.  When you hit a problem like this it's very helpful 
to know the regulatory domain and country code in your code; sysctl 
dev.ath.0 will show that.

When a channel is marked for passive scan a station cannot send frames 
unless it knows the channel is being used for 802.11 traffic.  What we 
need to do is listen first then if we see 802.11 traffic mark the 
channel as "ok to transmit on".  Then the next time we come to the 
channel we'll be able to send a probe request frame.  I've been meaning 
to get that code into cvs for a while; I'll see about making that happen.

In the meantime you may be able to specify the ap's bssid to associate 
(can't recall if the current scanning code requires an ssid match and 
bssid is just used to discriminate between multiple ap's with the same 
ssid).

	Sam