Re: HEADSUP: new ath+hal

Michal Mertl wrote:
> Yamamoto Shigeru wrote:
>>>>>>> "Sam" == Sam Leffler <sam_at_errno.com> writes:
>>>> Does anyone know how to solve this trouble?
>>>> #Should I hack wpa_supplicant? or ath hal and driver?
>> Sam> There have been many changes to ath and the net80211 layer.  Please try
>> Sam> to isolate what change affected you.  Past that you must provide the
>> Sam> mac+phy revs for your card.  Otherwise you have not indicated anything
>> Sam> about your configuration (open auth, wep, wpa, etc).  You haven't
>> Sam> provided any logs.
>>
>> Excuse me.
>> I write my environment.
>>
>> - IBM ThinkPad X31
>> - kernel and user land is current at 2006/02/16
>> - ath_hal: 0.9.16.16 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>> - ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3
>> - Access Point is 'I/O DATA WN-APG/A" (http://www.iodata.jp/prod/network/wnlan/2004/wn-apga/index.htm)
>> -- 'bssid 00:a0:b0:5e:73:b1' for 11b
>> -- 'bssid 00:a0:b0:5e:73:b2' for 11a
>> -- accept WPA-PSK only (not accept WEP)
> 
> Just a small observation - when I recently tried WPA-PSK and had both
> wpa_supplicant and hostapd running in the foreground with debugging
> enabled the station didn't associate. It worked without changing the
> configuration when I run both without debugging. I didn't have time to
> analyze it.
> 
> I remember that Sam once mentioned that Windows stations are unable to
> associate with FreeBSD AP when hostapd is run in debug mode, because
> debug made the AP's timing less precise or something. Maybe the last
> changes make the FreeBSD station also less tolerant?

This would likely be due to missing timing constraints because the debug 
msgs slow things down.  Windows has very tight timing constraints and 
can easily missing them.

	Sam