WiFi drops when you walk around the building?

Which fault is this really?

Start here. If one of these is you, the page you actually want is linked in the line — go there, it will save you an hour.

The ordered diagnosis: walk it, then read it

1. Pick one fixed route and write it down. Same start, same finish, same doors, same walking pace. Number eight to twelve stopping points along it — the desk, the corridor, the top of the stairs, the aisle head, the packing bench. Everything below is worthless without a route you can repeat exactly, because you are going to walk it again after every change.
2. Take two test devices, not one. A current laptop or phone, and one example of the oldest kit that actually has the problem: a handheld scanner, a VoIP handset, a legacy tablet. They will behave completely differently, and that difference is the diagnosis. A route walked with only a new laptop will tell you the estate is fine.
3. Record which access point each device is associated with at every numbered point. Your controller shows this in the client list — the access point name and the signal it is hearing from that client. Write it down point by point, for both devices. This single table is the whole test.
4. Mark where handover actually happened against where it should have happened. If the device is still on access point 1 while you are standing directly underneath access point 4, you have your answer and it is not a coverage problem. Note the signal level at the moment it finally let go — that number is the client’s own threshold, revealed.
5. Check transmit power across the estate, before anything else. This is one of the most common self-inflicted roaming faults in a managed network. If every radio is turned up near maximum, every access point is audible from everywhere, so no client ever reaches the point where its current link feels bad enough to leave. An estate that shouts has no cell edges — and roaming needs cell edges to happen at.
6. Check the minimum and basic data rates. If the lowest legacy rates are still enabled, a client can hang on at a barely usable rate from a very long way away, which is exactly the behaviour you are trying to stop. Raising the minimum rate turns the edge of each cell into a real edge. Raise it in steps, and watch the oldest kit at every step, because the oldest kit is what those low rates were left on for.
7. Check band steering — whether it is on, and how hard it pushes. Moving a dual-band client to 5GHz is usually right. But steering aggressively onto a band with shorter reach can leave a device hanging on the edge of a 5GHz cell in a spot where the 2.4GHz radio would have served it perfectly well. Look for devices that are on 5GHz at a signal level you would not accept.
8. Check 802.11k, 802.11v and 802.11r: supported, enabled, and on which SSIDs. 802.11k gives a client a neighbour list so it does not have to scan blindly. 802.11v lets the network suggest a better access point — a suggestion the client may simply ignore. 802.11r speeds up the reconnection once the client has decided to move, which is what matters for voice. None of the three takes the decision away from the client. They make the client’s decision better informed and quicker to act on, which is not the same thing and is worth saying out loud before you promise anyone a fix.
9. Work out which clients stick. Sort the complaints by device model rather than by location. It is usually the oldest and cheapest radios: handheld scanners, older Android tablets, budget laptops with basic wireless cards. Many enterprise handhelds carry their own roaming thresholds in the device or MDM configuration, documented in the manufacturer’s admin guide. That one setting often matters more than anything you can change on the controller.
10. Only now change something — one thing, in one area. Then walk the same route again, with the same two devices, and compare it against the table you already have. If you change three settings across the whole estate in one evening, you will never know which one mattered, or which one you will have to undo on a trading day.

Warehouses, workshops and multi-floor buildings

An open-plan office is the easy version of this problem. Roaming faults get their real character from buildings full of metal, stock and floors.

Racking reflects rather than blocks. Steel racking, roller shutters, mesh cages and stacked metal stock bounce signal around instead of politely absorbing it. Signal travels down an aisle far better than it travels across one, so a device three aisles away can hear an access point more clearly than a device two racks away. The client picks whatever it hears best, which in a warehouse is regularly not the nearest thing. Coverage maps drawn on a floor plan do not describe this well.

The building changes every week. A full warehouse and an empty warehouse are two different radio environments. Pallets of liquid absorb, pallets of metal reflect, and an aisle that was clear in January is a wall in November. A survey done against empty racking describes a building that will not exist when you are busy. If your roaming complaints rise and fall with stock levels, that is not coincidence — and it is not something you fix once and forget.

The scanners are stuck on the worst band. A great deal of handheld scanning kit still in daily use is 2.4GHz only. Greater reach sounds like an advantage and is the opposite here: bigger cells overlap more, boundaries blur, and a scanner can hold a distant access point from halfway across a building. It is also the congested band, sharing three non-overlapping channels with everything else in the postcode. So the devices with the least capable radios end up on the band with the most noise and the loosest edges.

And floors leak, badly. A ceiling-mounted access point radiates upwards and downwards as well as outwards. To a client standing on the ground floor, the unit on the first floor can look like a perfectly reasonable option — sometimes the best one, if it is closer in a straight line through the slab than anything on its own floor. Between-floor drops are often a device that roamed upstairs at the bottom of the stairwell and then walked away from what it had chosen. Stairwells, lift lobbies and mezzanines are where this shows up, and the fault is rarely where the user says it happened.

How to prove a change actually worked

Roaming is an easy fault to convince yourself you have fixed, because the evidence is a walking human being with an opinion. Two people can walk the same corridor an hour apart and come back with opposite verdicts, both honestly reported.

So make the test boring and repeatable:

• Same route, same numbered points, same order. The one you wrote down before you changed anything.
• Same two devices — the modern one and the awkward old one. Swapping the test device invalidates the comparison completely.
• Same time of day, and note the stock level. In a warehouse, a full aisle and an empty aisle are different buildings. Record which you had.
• One change between walks. If you must batch changes because you only get one evening, at least write the batch down in order, so you can unpick it.
• Give it a full working day before you believe it. Roaming faults hide behind quiet periods. A Tuesday morning proves very little.
• Ask the same people. Not “is the WiFi better?”, which gets you a mood. Ask whether the specific thing that broke — the call between the office and the bay, the scan at the far rack — happened again today.

Keep the previous configuration written down somewhere that is not the controller you are editing. The change you make at seven in the evening is the change you will want to reverse at half past eight the next morning, and by then nobody remembers what the power level used to be.