To analyze Chrome device debug logs, you need to understand HTTP requests. When a device finds and connects to a Wi‑Fi network, it sends an HTTP request whenever it needs to go to a new page or file. The request (when successful) allows a user to get to whatever they need on the web. Most devices work through an HTTP request in the same way.
These articles highlight each step in the HTTP request process. You can also see example logs of a successful HTTP request with each step. You can use them when you’re trying to analyze a Chrome device log for your organization.
To see more information than standard logs, you can turn on verbose logging. Use the ff_debug and wpa_debug commands to see the additional lines that contain
VERBOSE in the example logs.
Example assumptions for each step
Initially, on the device, Wi-Fi is turned off. Browsing history, cache, and Dynamic Host Configuration Protocol (DHCP) information is cleared.
- Two networks are specified that managed devices connect to, Network1 and Network2. Network1 is configured so that devices automatically connect to it when it's available.
- There are 3 additional networks in range—Network3, Network4, and Network5.
- Some lines have been removed from the logs to make them more readable.
- Lines with bold text are useful when troubleshooting.
- You might see some logs with reason or status codes. Deauthentication reason codes and association status codes are explained here.
Turn on verbose logging
ff refers to FlimFlam, the connection manager that shill is derived from. Shill is the connectivity manager daemon that runs on ChromeOS and it performs a number of network connectivity roles.
- On a Chrome device, press Ctrl + Alt + T to open crosh terminal.
- Run the following commands:
ff_debug --level -2
The wpa_debug command sets the debug level of wpa_supplicant. wpa_supplicant handles 802.11 wireless connectivity, including scanning, roaming, and security protocols.
On a Chrome device, press Ctrl + Alt + T to open crosh terminal.
Run the command: