WiFi Troubleshooting Checklist (for Campus IT support)

A knowledge base article about WiFi Troubleshooting Checklist (for Campus IT support) provided by the UC Berkeley IT Service Hub - Knowledge Portal

Note that there three wireless networks provided to the Campus Community: eduroam, Berkeley-IoT, and Berkeley-Visitor. A description of each, and when to use them, can be found under the Campus Wi-Fi: Compare Options document.

This document is focused on assisting technical support staff to diagnose Wi-Fi client issues prior to escalation to the Network Services Team. It may not contain sufficient information for end users, who are encouraged to see assistance from their local IT Support staff.

IT Responsibilities Checklist, Information gathering/troubleshooting for eduroam:

Note: Personal Windows and macOS devices, as well as iOS, Android, and ChromeOS devices are better served through the eduroam passwordless login process. If a user has issues with their eduroam password, have them try the passwordless system.

  1. The user is specifying their WiFi ID for the username
    • The users WiFi user name is their CalNET ID with @berkeley.edu
    • Not
      • Email address (pat.t.smith@berkeley.edu)
      • CalNet ID alone (ptsmith99)
      • Active Directory ID (CAMPUS/ptsmith99 or ptsmith99@campus.berkeley.edu)
      • Local Computer Login
  2. The user is specifying their WiFi Key for the password (do not ask for their password)
    • The users WiFi Key is generated by the GetOnline Wi-Fi page
      • Example: M%4dA.d
    • Not
      • CalNet Passphrase
      • Active Directory Password
      • Windows Login
  3. The connection is set with the following parameters (some or all available/visible depending on platform)
    • Type: WPA2-Enterprise or WPA3-Enterprise
    • EAP Method: PEAP (preferred) or TTLS
    • Phase 2 Authentication: MSCHAPv2
    • CA Certificate: Do Not Validate or Use System Certificate
    • Online Certificate Status: Do Not Validate
    • Validate Certificate: Deselected or No
    • Domain: berkeley.edu
    • Anonymous Identity is blank
  4. Device manufacturer, make, model, and OS release
  5. Device setup, including verification of username and passphrase
  6. View other wireless networks in the area to determine possible conflicts
  7. For Windows, MacOS, and Linux devices, gather band (2.4/5/6ghz), channel (3, 160, etc), and signal strength information
  8. Physical location
  9. Determine if the situation should be escalated  to the network group or referred to be a Telecom Catalog Order (Trouble ticket vs Work Order)

IT Responsibilities Checklist, Information gathering/troubleshooting for Berkeley-IoT:

  1. The users device has wireless address hiding turned off for the wireless adapter or network
    • Apple/iOS: disable Private Wi-Fi Address
    • Android: select User Device MAC 
    • Windows: disable Random Hardware Address
  2. The user has created a Berkeley-IoT device account on Wi-Fi Keys
  3. The user is supplying the unique password for this device as generated by the Wi-Fi Keys, Wi-Fi Account Management System
      • Example: M%4dA.d
    • Not
      • eduroam Password
      • CalNet Passphrase
      • Active Directory Password
      • Windows Login
  4. The connection is set with the following parameters (some or all available/visible depending on platform)
    • Type: WPA2-Personal or WPA3-Personal
  5. Device manufacturer, make, model, and OS release
  6. Device setup, including verification of username and passphrase
  7. View other wireless networks in the area to determine possible conflicts
  8. For Windows, MacOS, and Linux devices, gather band (2.4/5/6ghz), channel (3, 160, etc), and signal strength information
  9. Physical location
  10. Determine if the situation should be escalated  to the network group or referred to be a Telecom Catalog Order (Trouble ticket vs Work Order)

IT Responsibilities Checklist, Information gathering/troubleshooting for Berkeley-Visitor:

  1. Should the user be connecting to Berkeley-Visitor?
    • Any UC Berkeley affiliates should have the ability to connect to eduroam or Berkeley-IoT, and both of those networks are superior to the Berkeley-Visitor service.
    • Berkeley-Visitor is targeted at short term and non-affiliate visitors to the campus.
  2. Berkeley-Visitor can not be joined from the login screen on most devices.
    • This is because most devices do not support pre-login pop-up windows, which are required to access Berkeley-Visitor.
    • If the user has not logged in yet, they must do that before connecting to Berkeley-Visitor.
  3. Not required for most users single-day users: the users device has wireless address hiding turned off for the wireless adapter or network
    • Apple/iOS: disable Private Wi-Fi Address
    • Android: select User Device MAC
    • Windows: disable Random Hardware Address
  4. When the user connects, if the device does not automatically prompt them to "Log in to" the network, they will need to use a web browser to access a site to trigger the log-in process.
  5. Some devices will not trust the certificates captiveportal-login or welcome.wifi.berkeley.edu - the user may need to trust these manually
  6. The window may not close automatically, but once it displays "You are connected" it can be closed without losing connection to the network.
  7. Determine if the situation should be escalated  to the network group or referred to be a Telecom Catalog Order (Trouble ticket vs Work Order)

Interfering Devices to check for

How do I properly escalate network requests or issues to the network group?