A school that survived the first week of September for the first time
900 pupils arriving on the same Monday with two devices each. The Wi-Fi had failed in the first week for three consecutive years. The fix was mostly not about Wi-Fi.
What was wrong
The school's wireless network worked adequately for most of the year and failed reliably in the first week of September. This had happened three years running, and had been escalated to the governors.
The pattern was specific: the first Monday of term, from around 08:40, devices would associate and then fail to obtain an address or authenticate. By Wednesday things improved. By the second week the network was fine.
Three previous rounds of investigation had concluded that more access points were required.
What was actually happening
Three separate problems arriving at the same moment.
DHCP pool exhaustion. The pupil VLAN had a /22 — around 1,000 usable addresses — with a 24-hour lease. Nine hundred pupils arriving with two devices each, plus staff, plus every device that had been off for six weeks requesting a fresh address, exceeded it before first break. The pool then stayed exhausted because leases were not expiring.
RADIUS saturation. The authentication server was a single virtual machine sized several years earlier. Two thousand simultaneous 802.1X authentications at 08:40 produced a queue, timeouts, and clients retrying — which increased the load further.
Genuine capacity problems in two spaces. The main hall and the sixth form centre were genuinely under-provisioned, and these were the only places where the diagnosis "we need more access points" was correct.
Two of the three problems were not wireless problems at all. They simply presented as "the Wi-Fi does not work", because that is what a pupil sees.
What we did
The unglamorous fixes first
- DHCP pool widened to a /21 and the lease time reduced to 4 hours during term start, returning to 12 hours thereafter. This single change removed the largest failure mode.
- RADIUS scaled out to two instances behind a load balancer, with the authentication timeout raised and the client retry interval tuned so that a slow response did not produce a retry storm.
- Certificate-based EAP-TLS for school-managed devices, replacing PEAP-MSCHAPv2. This removed password-related failures and the associated helpdesk load entirely for that device class.
- Per-device PSK for the pupil BYOD estate, which cannot take a certificate. Each pupil device gets a key tied to their record and landing on the pupil VLAN.
The wireless work
- 16 additional access points, 11 of them in the main hall and sixth form centre where capacity was genuinely short.
- Main hall reconfigured from a ceiling grid to a front-and-side directional layout for assembly use, with 20 MHz channels during whole-school events.
- Channel widths reduced to 20 MHz across teaching spaces, and 40 MHz retained only in low-density areas.
- Minimum basic rate raised to 12 Mbps, and 2.4 GHz disabled on roughly 60 percent of access points.
- Two listed buildings handled with surface-mounted trunking and access points in heritage-approved locations, which constrained placement and required two additional units to compensate.
The rehearsal
The change everyone found most useful was not technical. Two weeks before term, IT ran a load rehearsal: 40 staff devices plus a script generating synthetic authentication load, in the main hall, at scale.
It found a misconfigured RADIUS attribute that would have failed every pupil device on day one.
Kit deployed
- UniFi U7 Pro
- UniFi U6+
- UniFi Pro Max 48 PoE
What changed
First week of term: 22 helpdesk tickets against 287 the previous year. No DHCP exhaustion. Peak authentication failures fell from 410 per day to 11.
Channel utilisation in the main hall during whole-school assembly fell from 84 percent to 38 percent.
The school's own measure was that the network was not discussed at the first governors' meeting of the year, which had not happened before.
The honest accounting
Of the four changes that mattered most, three were not wireless changes. The DHCP pool, the RADIUS scaling and the authentication method between them accounted for the majority of the improvement.
The previous three years of investigation had focused on the access layer because the symptom appeared there. This is the most common diagnostic error in wireless, and a school in September is the environment most likely to expose it.
“Three years of being told we needed more access points, and it turned out most of it was a DHCP scope and an undersized RADIUS server. We did need some more access points. We needed sixteen, not sixty.”Head of IT
Transferable lessons
- When everyone fails at once, it is usually not the radio. Check DHCP, DNS and RADIUS before touching the wireless configuration.
- Size the DHCP pool for peak arrivals with short leases, not for average occupancy.
- RADIUS capacity is a wireless dependency. Two thousand simultaneous authentications is a load test, and it happens on a known date every year.
- Rehearse the peak before it arrives. A synthetic load test two weeks out found a fault that would have failed every device on day one.
- Per-device PSK is the right answer for a BYOD estate that cannot take certificates.
- Listed buildings cost access points. Budget for the placement constraints rather than discovering them during installation.
Signal, not noise.
One email a fortnight: new case studies, spectrum-policy changes, and the gear worth your budget.