On 2013-02-19 08:31 -0800, Adrian Chadd wrote Georgiewskiy Yuriy:
AC>Well, ANI does adjust some of its parameters based on the beacon
AC>signal level. It uses that as an estimate for how "strong" the signal
AC>is likely to be and tunes the baseband to either be highly sensitive
AC>or slightly on the deafer side.
AC>
AC>If you have many sources of beacons (read: ibss, mesh, TDMA in my
AC>case) then that particular feature of ANI can't be used and it should
AC>be disabled. The code should be special casing it.
AC>
AC>I suggest someone writes a bunch of test functions:
AC>
AC>* whether we see no beacons (ie, AP mode)
AC>* whether we see one set of beacons (ie, STA mode)
AC>* whether we see multiple sets of beacons (ie ,everything else)
AC>
AC>.. and then modify the ANI code to work with the above.
I think you are right, but there i think a number of another bugs outside
of ani code - scan somehow triggers ani which adjust levels randomly,
it's triggers it even if ani disabled completely, question - why? random
levels after inserting module and bring up interface, its very annoing on
real network, reboot node - and a number of client will unreacheble, reboot
again - reachble, or part of him, scan on node - same result, this is why
i first disable ani at all, but this no much help me, then start digging
what is wrong. and after this changes i se no difference between AP and
802.11 modes, i think bugs with scan and initialisation steel present,
but ani will work and nivelate this bugs, don't known about other modes,
i just compare with ap.
C уважением With Best Regards
Георгиевский Юрий. Georgiewskiy Yuriy
+7 4872 711666 +7 4872 711666
факс +7 4872 711143 fax +7 4872 711143
Компания ООО "Ай Ти Сервис" IT Service Ltd
http://nkoort.ru http://nkoort.ru
JID: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
