I have a simple setup.
One router running OpenWRT.
4 dumb Access Points are attached.
The APs are TP-Link home routers (archer C60) with vendor firmware, configured in dumb AP mode (DHCP disabled). It doesn't have "user limit" option.
Is there a way connecting users can be evenly distributed?
Right now I see some of the APs completely idle.
Any other options apart from below?
Try to configure wireless channels the way that provides the best signal level in a specific area.
Clients should tend to connect to the AP with the best signal. Try to reduce the signal from each AP (smaller antenna, lower power, ...), and spread the APs.
None of these are very deterministic.
Is there a way the router can keep count on DHCP clients served through each AP?
Client association under 802.11 is at the clients’ whim. Nothing is either deterministic or reliably controlled by the AP under the standards.
That won't work. If a client can't DHCP, it would keep retrying the same AP and never connect to anything. Android might also eventually block out the whole SSID presuming that the network is broken.
I can't understand why the OP wants to have clients evenly distributed over multiple APs.
If the APs are on the same channel, they will interfere and performance will be much worse than having all clients on one AP
If all APs are on different channels but in the same physical location, then performance will be only slightly better than all clients on a single AP
The only real reason to run a multi-AP setup is to increase coverage, and in this case, you do NOT want clients evenly distributed - you always want them on the AP with the strongest signal.
The only other use case I can think of is if you have so many SSIDs that you have more than a single AP can support (Cisco APs have a limit of 8 for example) - but at this point, you really need to be asking yourself, "Can I get rid of/consolidate some of these SSIDs?"
Each AP has limited wireless (1350 Mbps) and wired (100 Mbps) bandwidth.
Now if there are 60 users in total, it makes sense to distribute them across 4 APs.
Why aren't you using gigabit backhaul?
I don't think this is true, if you have 60 users in a room, and two APs in that room on different channels, then if they are all on one AP there will be no airtime, but if they split more evenly there is much lower contention
There is no way you're going to have 60 users that close to each other to the point where you wouldn't be better served by having APs in different parts of the room.
Even if they're in different parts of the room, let's say it's a lecture hall. Sure you'd expect everyone to connect more or less evenly based on whether they're nearer to the left side or the right side... but in my experience many android phones are "sticky" and if everyone comes through the one entrance on the right side, then they'll initially glom onto the right side AP and even if they move to the left side of the room, they will stay glommed on, unless you either boot them off due to received signal strength (which is not yet available in OpenWrt but is in the mainline hostapd if I understand correctly) or you turn down the AP power low enough that by the time you get to the left side of the room the client can't maintain a connection to the right side... and that's questionable if you'll get a reliable solution that way, people in the middle of the room will have no connection to either side...
This is exactly the problem I am facing.
I am not seeing any solution here.
So why not set different SSID and ask users to connect based on their location?
Any downsides?
If "mobility" of the users is not a big requirement.
Can you turn down the power on the one near the door?
Whoa, like finally? I've done some experiments in that area and found it very effective in a crowded situation, even when there is only one AP.
I really don't recommend cutting AP txpower as the way to encourage or force clients to drop and find another AP. The clients who are not extremely close to the AP (but still should stay on this AP) will have to receive at reduced MCS which bogs down the whole thing. Obviously you don't use so much power so that someone standing underneath an adjacent AP still has full bars from the one on the other side of the room, but you want enough power that all users of an AP have a good signal.
That is probably the best thing to do given your constraint of stock firmware in the APs. There is still a problem that once someone has more than one of the SSIDs loaded into their phone, they are likely to cling to the wrong AP.
indeed, I suspect this will make it worse, because there is going to be an even stronger affinity to the one they first connect to. Android will roam eventually, but it won't leave an SSID until it literally can't send packets anymore.
turning down the power, and eliminating any and all low speed modulations (absolutely turn off 802.11b, but even for n mode speeds eliminate say 6 and 12 Mbps) Of course you will need support from the firmware.
Yes, this is the best bet, combined with eliminating low speed rates.
Yes support for 11b should be something that requires an opt-in in the configuration, if it is offered at all. g is about the same way. Should you want to use my high speed wifi, bring suitable equipment made in the last 10 years. Don't go to drive a Model T on the autobahn, it's just going to get in the way of everyone else.
Another feature I would love to see is sending beacon packets at some moderately high MCS (right now they are usually sent at 1 Mbps with 11b). If the beacons are at high MCS, a client too far from the AP won't be able to decode them, so to them that AP no longer exists and they drop the connection.
My understanding is they are sent at the lowest supported rate, so if you have something like:
option basic_rate '6000 12000 18000 24000 36000 48000 54000'
option supported_rates '6000 12000 18000 24000 36000 48000 54000'
it will use the 6000 rate. if you turn off 6000 and 12000 it will use the 18000, but I'm not 100% sure.
BTW it seems like by default OpenWrt supports b rate, and you have to go into luci under the wireless SSID and select advanced tab and unclick suporting b rates, which causes it to put that above code in place.
Enable DHCP on the APs (well, routers) and set limit for the pool.
to do that they must be on separate network segments, and then you need separate SSIDs. it could work though to keep people from associating to the AP near the entrance