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: GHhost@xxxxxxxxxx JID: GHhost@xxxxxxxxxx YG129-RIPE YG129-RIPE
