On Sat, Sep 18, 2010 at 01:01:43PM +0100, Joe Martel wrote: > > If you do 'ifconfig ral0 down; ifconfig ral0 up' on the hostap > > box it might temporarily fix things > > Yes it does, thanks. > Have added a cron job to run this every 24hrs.
I have a similar problem against which ifconfig down; up isn't effective. My card is an RT2561, and when I turn on ifconfig debug on both the client and AP, I see that the AP responds to the association request and sends the first packet of the 4-way handshake. The client receives the association response, fails to receive the handshake initiation, and receives a deauth after timing out. AP side: ral0: received assoc_req from xx:xx:xx:xx:xx:xx rssi 105 mode 11g ral0: sending assoc_resp to xx:xx:xx:xx:xx:xx on channel 6 mode 11g ral0: sending msg 1/4 of the 4-way handshake to xx:xx:xx:xx:xx:xx last message repeated 2 times ral0: station xx:xx:xx:xx:xx:xx deauthenticate (reason 15) ral0: sending deauth to xx:xx:xx:xx:xx:xx on channel 6 mode 11g client side: athn0: sending auth to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received auth from yy:yy:yy:yy:yy:yy rssi 47 mode 11g athn0: sending assoc_req to yy:yy:yy:yy:yy:yy on channel 6 mode 11g athn0: received assoc_resp from yy:yy:yy:yy:yy:yy rssi 46 mode 11g athn0: associated with yy:yy:yy:yy:yy:yy (...) athn0: received deauth from yy:yy:yy:yy:yy:yy rssi 46 mode 11g Turning off WPA2 doesn't allow clients to use the network; it just fails differently, though I unfortunately don't have log captures of that at the moment. The only reliable way I've found to resurrect the AP is a cold power cycle. Is this also a known issue? Is there any more targeted tracing I could try compiling into my kernels besides RAL_DEBUG, ATHN_DEBUG, IEEE80211_DEBUG? I'm wondering if this has something to do with crypto parameters on the card not being reset in all cases, but I don't know enough about either the hardware or the 802.11 protocol to have any idea whether that makes sense.
