On 22 February 2013 13:26, PseudoCylon <moonlightak...@yahoo.ca> wrote:
>>> The OP problem is that we're not advertising the right capabilities >>> when we associate, right? >> >> Correct. > > I didn't patch it right, but all of us agree on sta isn't sending > correct param at association. With current code, sta sends back > whatever it has received in probe resp packet. Right, but Bernhard points out the original code did return its own configuration, and this causes some APs to reject stations. Hence why it's doing this. >>> Why aren't we just advertising the VAP ampdumax and ampdudensity no >>> matter what the operating mode? Why are we capping those parameters to >>> the learnt-from-AP parameters? >> >> Because the AP would otherwise deny the association request. > > Should ap only allow node which caps match ap's to associate? (By the > way, can anyone point me to the code does denial? I couldn't find it.) I don't think so. The whole point here is to _support_ nodes whose density/ampdusize is less than what we have configured. The only reason we'd want to reject them is if we have some concept of "minimum acceptable density/ampdurx" (like "minimum basic rates"), rather than "what is it we support." Adrian _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
