On 10/12/11 00:30, Steven Chamberlain wrote:
> Issue 5: ... I noticed a device stop
> responding to Association Requests; with hostapd still running
> Issue 6: deauthentication frames are constantly sent out to devices
> that haven't been in range for hours, to the same BSSIDs over and over;
> as if it is about to purge them from the node cache, but actually
> doesn't;
Hi,
I had some new thoughts on this; if nodes are really not being purged
out of the cache, that would explain why new Association Requests are
ignored. The fact I saw deauthentication frames being sent means the
cache was indeed full -- it doesn't garbage-collect until then:
> 1121: if (ic->ic_nnodes < ic->ic_max_nnodes)
> 1122: break;
(Before rev 1.63 / kettenis, nodes were never expired at all due to
broken logic here).
I wonder if it is right to send deauth and only call node_leave()... if
the client is no longer in range / responding, and doesn't respond to
confirm the deauth, would that be enough to really clear the node out of
the cache? Or should free_node() be called too (removing the 'else'
keyword)?
> 1130: /*
> 1131: * Send a deauthenticate frame.
> 1132: */
> 1133: #ifndef IEEE80211_STA_ONLY
> 1134: if (ic->ic_opmode == IEEE80211_M_HOSTAP) {
> 1135: splx(s);
> 1136: IEEE80211_SEND_MGMT(ic, ni,
> 1137: IEEE80211_FC0_SUBTYPE_DEAUTH,
> 1138: IEEE80211_REASON_AUTH_EXPIRE);
> 1139: s = splnet();
> 1140: ieee80211_node_leave(ic, ni);
> 1141: } else
> 1142: #endif
> 1143: ieee80211_free_node(ic, ni);
> 1144: ic->ic_stats.is_node_timeout++;
The box that exhibited this problem is one in a fairly 'public' place,
where people come and go carrying wireless devices that probe/associate
and then disappear. This box has been known to stop accepting
connections from legitimate clients several times a day, until it is
power-cycled.
Regards,
--
Steven Chamberlain
[email protected]
