Overview
Network quality is one of the most critical and variable factors in mobile device testing. An application that works perfectly on a fast office Wi-Fi connection may fail completely in the field — on a weak signal, a local-only network, or an intentionally degraded connection. Testing across all three connection types is essential for any mobile product that relies on network connectivity.
From Experience: At Viasat, Wi-Fi and network testing was a core part of our IoT device validation. Devices had to maintain stable connections across Good, Local, and Bad network conditions — and the behaviour of the application under each had to be precisely characterised. The snippet intervals and unified error codes in this post are based on real test frameworks used in that environment.
The Three Wi-Fi Connection Types
For mobile and IoT device testing, Wi-Fi connections are classified into three types based on stability, latency, and internet access. Each type produces different application behaviour and is set up differently in a test environment.
Wi-Fi Connection Types — Quality Spectrum
Good Connection
A good Wi-Fi connection represents a stable, reliable wireless connection between the device and a Wi-Fi network with full internet access. This is the baseline test environment — all features should work correctly here.
- Characteristics: No packet loss, low latency, full internet reachability
- Snippet interval: A diagnostic snippet (log snapshot) is generated every 300 seconds (5 minutes)
- Test focus: Verify all core functionality works. Establish performance baselines for later comparison against degraded connections
# Verify connectivity on a Good Connection
adb shell ping 8.8.8.8 # Google DNS — checks internet reachability
adb shell ping google.com # Checks DNS resolution + internet
8.8.8.8 is Google's public DNS server. A successful ping confirms the device can reach the internet through the router.
Local Connection
A local Wi-Fi connection means the device is connected to a router that has no internet access — the router is powered on but its WAN port is unplugged. The device can communicate with other devices on the local network (LAN) but cannot reach the internet.
- Characteristics: LAN access only; all internet-dependent features fail gracefully
- Snippet interval: Generated every 100 seconds — more frequent due to the degraded connectivity
- Test focus: Does the application handle the absence of internet correctly? Are error messages user-friendly? Does local functionality (e.g., LAN discovery) still work?
# Test connectivity on a Local Connection
adb shell ping 192.168.1.1 # Should succeed — router is reachable
adb shell ping 8.8.8.8 # Should fail — no internet
Bad Connection
A bad Wi-Fi connection simulates an unstable, unreliable network — high latency, packet loss, intermittent dropouts. This is the hardest environment to test in and reveals resilience issues that never appear on a good connection.
- Characteristics: Unstable signal, packet loss, unpredictable latency, intermittent internet access
- Snippet interval: Generated every 180 seconds (3 minutes)
- Test focus: Does the app retry gracefully? Does it preserve data on disconnect? Does it notify the user appropriately? Does it recover automatically when connectivity improves?
Setup Guide — Creating Each Connection Type in the Lab
| Connection Type | Setup Instructions |
|---|---|
| Good Connection | Connect the router to the internet via an Ethernet cable plugged into the router's LAN port. Device connects to the router's Wi-Fi SSID. The Ethernet provides full internet access. |
| Local Connection | Turn the router on but leave the Ethernet cable disconnected (no internet feed). Device connects to the router's Wi-Fi SSID. Wi-Fi connection succeeds but internet is unreachable. |
| Bad Connection |
Use two routers (Router 1 and Router 2): 1. Connect Router 1 and Router 2 via Ethernet (Router 1 WAN → Router 2 WAN) 2. Enter Router 2's IP address into Router 1's DNS server settings 3. Block Router 2's IP address in Router 1's firewall rules 4. Device connects to Router 1's Wi-Fi The DNS block creates an unstable, degraded connection — the device is connected but internet access is intermittent and unreliable |
Unified Error Codes
Unified error codes are standardised connectivity status codes that appear in device logs. They indicate what the device is experiencing at a network level — each code maps to a specific connection event or failure reason.
# Command to read unified error codes from logcat
adb shell logcat -v time -b all | grep -i unified
| Metadata / Reason Code | Meaning | What to Check |
|---|---|---|
| Reason 1 | Connecting — device is attempting to establish a connection | Normal state during initial handshake; should resolve to Reason 7 quickly |
| Reason 2 | Bad password — authentication failed due to wrong Wi-Fi credentials | Verify the password entered is correct; check if the SSID requires a specific auth method |
| Reason 3 | Short disconnection — lost connection for approximately 10 minutes | Check for interference, signal strength, or brief AP outage; auto-reconnect should trigger |
| Reason 4 | Long disconnection — connection lost for more than 1 hour | Investigate sustained signal loss, DHCP lease expiry, or device power management cutting the radio |
| Reason 5 | Bad connection — unstable, degraded connection (high packet loss / latency) | Check signal quality, interference sources; matches Bad Connection test environment |
| Reason 6 | Very long disconnection — connection lost for more than 6 hours | Critical issue; investigate persistent network outage, device restart, or hardware failure |
| Reason 7 | Good connection — stable, reliable connection established successfully | Expected steady state; snippet interval 300 seconds; no action required |
Unified Error Code Flow — Device Connectivity Journey
R1
Connecting
Connecting
→
R2
Bad Password
Bad Password
or
R7
Good
Good
→ if drops →
R3
< 10 min
< 10 min
R4
> 1 hr
> 1 hr
R6
> 6 hr
> 6 hr
DFS vs Non-DFS Channels
Wi-Fi operates on different frequency bands, each subdivided into channels. Understanding DFS (Dynamic Frequency Selection) is critical for mobile device testing — especially on devices that operate in the 5 GHz band.
| Category | Frequency Band | Number of Channels | Characteristics |
|---|---|---|---|
| Non-DFS | 2.4 GHz | 9 channels | Greater range; more interference (microwaves, Bluetooth, neighbours); lower throughput; simpler to test — always available |
| DFS | 5 GHz | 16 channels | Less interference; higher throughput; DFS channels require radar detection — the device/AP must perform a 60-second CAC (Channel Availability Check) before use; some channels may be unavailable depending on the country's regulatory domain |
Why DFS testing matters: DFS channels are shared with radar systems (aviation, weather). If a device detects radar on a DFS channel, it must immediately switch channels. This is a real hardware compliance requirement. Testing that the device correctly performs CAC and handles radar events is mandatory for Wi-Fi certification in many markets.
Logcat Commands for Wi-Fi Diagnostics
The most powerful tool for Wi-Fi debugging on Android is logcat filtering. These commands extract Wi-Fi and connectivity-specific logs from the device in real time:
# Monitor all Wi-Fi diagnostic logs
adb shell logcat -v time -b all | grep -i wifidiags
# Monitor unified connectivity error codes
adb shell logcat -v time -b all | grep -i unified
# Monitor build and system info in logs
adb shell logcat -v time -b all | grep -i build
# Save full logcat to file for offline analysis
adb logcat -v time -b all > wifi_test_log.txt
Understanding Logcat Output
A typical Wi-Fi diagnostics log line looks like:
04-23 10:35:42.881 W WifiStateMachine: Unified reason code: 7 (GOOD_CONNECTION)
04-23 10:35:42.882 D WifiDiags: Snippet generated. Interval: 300s
The timestamp, log level (W = Warning, D = Debug, E = Error, I = Info), tag, and message help you trace exactly what the Wi-Fi stack was doing at any moment.
ADB Network Commands Reference
| Command | Purpose |
|---|---|
adb shell ping 8.8.8.8 | Test internet reachability via Google DNS — confirms routing and internet access |
adb shell ping google.com | Test DNS resolution + internet — confirms DNS is working AND internet is reachable |
adb shell svc wifi enable | Enable Wi-Fi on the device via ADB |
adb shell svc wifi disable | Disable Wi-Fi — simulates Wi-Fi off scenario for interruption testing |
adb shell wpa_cli | Connect to or manage wireless networks; access wpa_supplicant interface |
adb shell settings list global | List all global device settings — includes Wi-Fi and mobile data state |
adb shell settings get global mobile_data | Check if mobile data (cellular) is enabled (1) or disabled (0) |
adb shell svc bluetooth enable/disable | Enable or disable Bluetooth — useful for interference testing with 2.4 GHz Wi-Fi |
Network Testing Checklist for Mobile Apps
Before releasing a mobile app to production, every item on this checklist should be verified. Network-related defects are among the hardest to catch post-release because they depend on real-world conditions — variable signal strength, carrier throttling, and unexpected handoffs — that are difficult to reproduce in the field. Running this checklist in a controlled lab environment before every release prevents a large category of customer-facing bugs.
- App works on 2G, 3G, 4G, 5G, and Wi-Fi. Each network type has different throughput, latency, and packet loss characteristics. An app that works perfectly on 5G may timeout on 2G if API call timeouts are set too tight. Test each connection type explicitly, not just "a phone network."
- Graceful handling when no network is available. When the device goes completely offline, the app should either display a clear, user-friendly error message or transition into an offline mode. A blank white screen or a raw system error is not acceptable. Test by enabling Airplane Mode mid-session.
- Retry logic when requests fail due to timeout. Network timeouts happen in the real world. The app should automatically retry transient failures with an exponential back-off strategy, not simply surface a generic error to the user on the first failed attempt.
- No data loss when switching between Wi-Fi and cellular mid-session. A user actively filling in a form or completing a transaction should not lose their progress when the device switches from Wi-Fi to cellular as they walk away from the router. Verify that in-flight state is preserved across handoffs.
- Correct behaviour when switching between DFS and Non-DFS channels. Devices roaming between 2.4 GHz and 5 GHz bands may experience a brief disconnection during channel switching. The app should reconnect cleanly and resume any active sessions without requiring user intervention.
- SSL certificate validation does not fail on captive portal networks. Hotel Wi-Fi, airport Wi-Fi, and coffee shop networks often intercept HTTPS connections to redirect users to a login page. If the app treats this certificate substitution as a security error and crashes rather than handling it gracefully, it breaks in an enormous number of real-world environments.
- API timeouts configured correctly — not the 30-second default in production. Many HTTP client libraries default to a 30-second connection timeout. In a mobile context on a poor network, 30 seconds of an unresponsive spinner is an unacceptable user experience. Set aggressive but realistic timeouts (typically 10–15 seconds) and handle the timeout case explicitly.
- Background sync does not drain battery on metered connections. Apps that sync data in the background should respect whether the connection is metered (cellular) or unmetered (Wi-Fi). Heavy background operations should be deferred to Wi-Fi unless the sync is explicitly user-triggered. Use Android's WorkManager constraints for this.
- Large file downloads resume after a connectivity drop. Downloading a firmware update, a large media file, or a data export should not restart from zero if the network drops partway through. Verify that the download manager uses HTTP range requests and resumes correctly from the last confirmed byte.
- Push notifications deliver within acceptable SLA on all network types. Notifications that arrive minutes late on a 2G connection when the user expects near-real-time alerts are a product defect. Measure notification delivery latency across all supported network types and verify it meets the product's defined SLA.
- App does not cache stale data beyond its TTL. Cached API responses improve performance but become a reliability problem if they are served past their time-to-live. Test that the app respects cache expiry correctly — stale data shown to users who have a live network connection is a correctness bug.
- Network error messages are user-friendly — not raw error codes. "ERR_CONNECTION_TIMED_OUT" means nothing to an end user. "Unable to connect. Check your network and try again." does. Every network error state in the app should have a designed, human-readable message — not a stack trace or HTTP status code.
- Connection quality degrades gracefully. On a congested network, a video streaming app should reduce resolution rather than rebuffer endlessly. An image-heavy app should load lower-resolution thumbnails first. Graceful degradation preserves usability when the network cannot support the full experience.
- No crash on immediate network loss during a transaction. Yanking the network cable — or toggling Airplane Mode — while a financial transaction, a form submission, or a login request is in-flight is a real-world scenario. The app must handle the mid-request disconnect cleanly, without crashing, and ideally with a recoverable state.
- Logs correct network events for diagnostics. When a network-related defect is reported from the field, you need logs to diagnose it. Verify that the app logs meaningful network events — connection established, timeout, retry attempt, offline detected, reconnected — with timestamps, so that a logcat or app log export gives you a coherent picture of what the network stack was doing.
References
- Android Wi-Fi Framework Documentation — developer.android.com/guide/topics/connectivity/wifi
- IEEE 802.11 Standard — Wi-Fi Alliance Specifications
- FCC DFS Requirements — fcc.gov (Dynamic Frequency Selection regulatory requirements)
- Wi-Fi Alliance Test Plans — wi-fi.org/certification
- Android logcat Documentation — developer.android.com/tools/logcat
Back to Blog
From Experience — Viasat: Working with ARINC 429 data buses and IFC hardware at Viasat, Wireshark became an essential daily tool. During a Boeing integration test, we observed unexpected burst rate timing that didn't match the Interface Control Document. Capturing ARINC 429 frames in Wireshark and comparing against the ICD revealed a 12ms timing offset — within tolerance on its own, but enough to cause cumulative drift on long-haul flights. That finding prevented an on-wing integration failure. Linux CLI diagnostics alongside Wireshark are indispensable for this level of root cause analysis.