On Tue, 24 Mar 2015, [email protected] wrote:
After reading comments from all of you I thought of deploying additional devices just as wifi analyzers, as few of you suggested. I have used kismet before, but only as standalone wifi scanner, but there is also an option to deploy kismet-drones and monitor multiple endpoints from central kismet server. That could probably work if you can get alerts from kismet when some channel starts to have lots more traffic than it used to have and then take action if necessary to modify your node's channels. Any thoughts on this approach?
The devil is in the details. What does "too much traffic" mean? It could just be the crowd that you are intending to serve using the system, or one person doing a yum update.
Then there's the problem of deciding what to do. As I was trying to say in my last, long message, figuring out what channel each AP is on is not a science, it's part art because the system can't know everything (are these APs heavily loaded because this is the keynote and everyone's in one place, or because everyone is in the lobby waiting for the show floor to open in 10 min and will flood in to the area where the APs are idle, etc)
I've had cases where vendors on the show floor were demoing video streaming to mobile devices, using their own APs not coordinated with us (and after signing an agreement that they would not do so) where their activity not only clobbered three APs on the show floor, but 6 rooms of APs on the floor above. At some point there's not much you can actually do from a technical point of view other than identifying the problem.
Kismit and similar can be useful tools to gather facts, but turning facts into information and figuring out what actions you can take are far from simple.
David Lang _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
