On 16/01/12 09:47, Sebastian Reitenbach wrote: > this is a followup on the misc@ "problem with ral in hopstap mode on > -current" thread.
Thank you! I wasn't subscribed to that list but I mentioned this on bugs@ on 2011-12-10, "rum: multiple issues". > tcpdump -n -i ral0 -y IEEE802_11_RADIO -vvv > ... > 17:24:49.225241 802.11: probe request, <radiotap v0, tsf 366153760136, 1Mbit/s, chan 1, 11g, antenna 1, signal 65dB> > 17:24:49.225311 802.11: deauthentication, authentication expired, <radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1> > 17:24:49.225347 802.11: deauthentication, authentication expired, <radiotap v0, 1Mbit/s, chan 1, 11g, antenna 1> Same thing I was seeing! I think the flood of deauths from your AP implies the node cache is full, and for some reason it tries but fails to flush anything. At that point no station can (re)associate. > So adding this rc=1 on Friday evening, now over the whole weekend, up to this > morning, my wireless is working stable now, > as it was before with the 4.2. I don't understand how setting 'rc = 1' for beacons/proberesps helped (non-zero means "yes, needs an rxnode"); I would have expected that to fill the node cache more quickly, and so trigger the bug more often. Figuring this out might be key to understanding some underlying problem... > This should prevent entries of the form: > nwid "" chan 3 bssid 00:01:02:03:04:05 0dB 54M > in "ifconfig if0 scan" output, like reported by Rivo Nurges. Have you seen anything like that yourself yet? I found that raising IEEE80211_CACHE_SIZE from its default of 100 in ieee80211_node.h reduces how often the problem occurs, but is not in any way a sensible fix. When debugging the issue it would probably help to lower that value drastically so it is easier to trigger it. Regards, -- Steven Chamberlain [email protected]
