The first time the campus network WiFi was online, the real test was in daily traffic. This article is a compilation of recurring problems and coping experiences during the operation, not theoretical, but merely the rules found in the exercise.
First pit: Portal page does not bomb or repeats
This is the highest problem with the news. Students say that they are not connected to WiFi, but actually have no access to the authentication page. The check path is usually: first checking whether a gateway works (CPU and memory occupancy), then seeing if the terminal's DNS resolution is correctly hijacked to the gateway address, and then confirming whether the iptables recalibration rule on the gateway level is in effect.
The problem is that the system-level end-to-end testing uses HTTPS sites (e.g. apple captive.apple.com), but the campus WiFi billing system only reoriented HTTP. The solution is to upgrade the gateway fixture or the campus network WiFi billing system version, which supports the HTTPS's Captive Portal test response. This problem occurs in a centralized fashion during the school year ' s new startup season because of the use of brand and system versions of mobile phones.
Second pit: no sensory authentication lapses
The equipment that was tied suddenly needed re-certification for Portal. Students complained."I've already tied it.". The three common reasons are: the MAC address binding form of the WiFi system on campus network was cleared (usually not correctly restored after the system restarted), the terminal changed a web card or opened a MAC address randomly, and the AP switch triggered a security strategy as DHCP OP 82 information changes were made.
The randomization of the MAC address is an emerging issue in recent years. IOS and Android have defaulted on a private WiFi address function, which can be used by terminals to connect WiFi each time.
Third pit: operator exit jump
Students choose a telecommunications package but the actual flow runs off to export, resulting in overcharges. This problem occurs occasionally in multi-operator environments, often because the strategic route sheets of the gateway level are not properly updated at the time AP switch or chain failure switch, leading to loss of export tags for user sessions.
The screening is done by checking the logs of sessions and gateways of the WiFi system on campus, confirming that each online session has an export tag. A precautionary measure is to set up an export verification mechanism in the WiFi system on campus: check regularly whether the traffic of the sessions is on the right export chain and automatically alert or correct if a deviation is detected.
Fourth pit: incorrect billing
The students complain that the traffic is offline, or that the month of the package expires at an incorrect time. Common reasons for this are: the start of the fee cycle on the campus WiFi system does not match the student’s contribution time; there are omissions in cross-operator flow statistics (part of the traffic has gone unincluded by default exports); and the system clocks do not synchronize to lead to long-term calculation deviations.
The proposal to establish a monthly billing mechanism: the details of the billing from the WiFi system on campus network are cross-referenced with traffic statistics provided by operators, and the reasons for discrepancies are identified in a timely manner. This exercise, while cumbersome, will maintain students’ confidence in the costs charged on campus networks.
Fifth pit: logs full
If the logs are not pre-planned, either cover old data (not six months of retention requirements) or the system stops writing (influent on normal billing).
The recommended log management strategy is to keep the heat data for the last three months and store them on SSD or high-speed disks for real time search; archive cold data after compressed to low cost storage, which meets six months of compliance retention; and automatically clean up or archive more than six months of data to offline storage. At the time of configuration, at least 30% of the redundancy space is reserved for the logs because logs may be two to three times higher in average during examination season or start-up season.
Sixth pit: peak performance bottlenecks
At 9 to 11 p.m., the campus network is at its peak and all dormitories are online. If the campus network WiFi is systematically underpaid, there will be slow certification responses, a gateway CPU of 100%, and some students are kicked offline.
It is recommended that pressure tests be performed when the models are selected: simulation of 80% of the expected co-mingling, 24 hours of continuous operation, observation of indicators such as authentication response time, gateway CPU and memory occupancy, and delay in database queries. If the manufacturer does not want to cooperate with the pressure testing, this is a dangerous signal in itself.
Seventh pit: centralized opening of the freshman season
Thousands of new students need to complete the opening of accounts, WiFi connections and first-time certification in a short time.
The preparatory work includes: the production of a list of new recruits from the schoolwork system, data compilation in the format required by the campus network WiFi billing system, pre-production of small batch import tests to confirm that the form is correct, and preparation for regular problems FAQ to be sent to the freshman.
Recommendations for the transport of a tool
Tools that are useful in routine transports include Zabbix or Prometheus alerts for monitoring gateway status, Elasticsearch + Logstash + Kibana or light Grafana Loki for log analysis, SSH tunnel tool for remote drainage, and Radtest command line tool for simulation certification tests. Key indicators of the WiFi system (online number of users, authentication success rates, export utilization rate by operators, log storage usage) can be detected and resolved before problems become complaints.