WiFiProfiler: Cooperative
Diagnosis in Wireless LANs
Ranveer Chandra, Venkat Padmanabhan, Ming Zhang
Microsoft Research
Wireless Woes
• Users often wonder why:
– “My machine says: wireless connection unavailable”
– “I get poor performance on wireless”
– “My wireless card keeps trying to authenticate”
– “Is it just me?”
2
Wireless Woes
• Users often wonder why:
– “My machine says: wireless connection unavailable”
– “I get poor performance on wireless”
– “My wireless card keeps trying to authenticate”
– “Is it just me?”
• Many places have no/minimal network admin
– Hotspots: cafes, airports
– Transient networks: conferences, IETF meetings
3
Prior Work: Operator View
• Infrastructure-based monitoring (Aruba, DAIR)
– Focuses on operator perspective (e.g., rogue APs)
• Monitoring at clients (e.g., [Adya 2004])
– Fault diagnosis using infrastructure support
– Also focuses on operator perspective
• Correlate client observations at AP (MOJO)
– Detect PHY level anomalies
4
WiFiProfiler Goal: User View
Enable clients to diagnose network failures
without requiring admin/infrastructure support:
– Reduce user frustration
– Reduce load on admin, when there is one
Help users help themselves
5
State of the Art: Local Diagnosis
Wireless Connection Manager, WZC
• Reasonable detection, Poor diagnosis
Bad NIC
MAC
Filtering
Bad AP
Bad WEP
Key
Cannot Associate
6
WiFiProfiler
• Based on two key observations:
– Clients form Information Plane with peers
• Even when client cannot connect to AP
– Extent of problem indicates cause
Diagnose faults by correlating peers’ health
7
WiFiProfiler Overview
Healthy Client
Dissatisfied Machine
Access Point
Create Information
Plane
Healthy Client
(Cannot connect to
WEP-enabled AP)
Diagnose Problem:
Same WEP key?
Diagnose range of problems across layers!
8
Faults and Some Causes
No AP Detected
Location
H/w or s/w
No Association
Security
DHCP Server
No IP Address
Firewall/proxy
End-to-End Failure
WAN Disconnect
WAN congestion
Poor Performance
Wireless problem
9
Outline
• Introduction
• WiFiProfiler Overview
• WiFiProfiler Design
• Evaluation
• Summary
10
WiFiProfiler Design Goals
• Transparency:
– Minimal user impact/involvement
• Deployability:
– Work with off-the-shelf cards and unmodified drivers
• Scalability:
– Work with a large number of clients
• Security:
– Prevent compromise of clients and AP
11
WiFiProfiler Architecture
• Sensing: What is monitored?
• Communication: How is it shared?
• Diagnosis: How are faults diagnosed?
12
Sensing
• Monitor health of client’s connectivity
– Static info (e.g., NIC type)
– Dynamic info (e.g., assoc. success/failure)
Fault
No Association
Some Causes
H/w or s/w
Security
Sensed Info
NIC Model, Make,
Driver version
Auth/Encryption
setting, key info
13
Sensed Information
• User-level service (daemon) polls various layers
– Wireless: NIC, BSSID, RSSI, Beacon Loss, 1-way
hash of key, Interface Queue
– IP: IP Address, DHCP, DNS
– Transport: Failed connections, Server Ports
– Application: Web proxy settings
• Snapshot obtained once every second
– Summarized information < 1200 bytes
14
Communication
H
Req. Health
D
Sensed Info
Establishing the Information Plane
802.11 NICs can connect to only one network at a time
Challenges:
– Discovery: How does H know that D needs help?
– Parallelism: How does H send packets to D?
15
Discovery
• D initiates ad hoc network with distinct SSID
– Special SSID format denotes request for help
– H receives beacon even when associated to AP
SSID:
Help:169.254.10.125:5000
D
169.254.10.125
Port: 5000
H
16
Parallelism using VirtualWiFi
Details: Infocom ’04
Approach: Virtualize card, buffer packets, switch b/w networks
Application Layer
User-level
Kernel-level
TCP/IP, Network Stack
Virtual Interface 1
Virtual Interface 2
Virtual Interface 3
VirtualWiFi Layer
Wireless Card
17
Communication Protocol
• WiFiProfiler uses 2 (virtual) adapters:
– Primary adapter activated in normal use
– Helper adapter dedicated for WiFiProfiler
• Activated only when needed
SSID:
Help:169.254.10.125:5000
D
Primary VNIC
169.254.10.125
Port: 5000
H
Helper VNIC
18
Scalability and Security discussions in paper
Diagnosis
• Initiated by user
• Correlate peers’ info and infer likely cause
– Rule-based techniques instead of black-box
• Suggest steps for problem resolution
– Change configuration settings
• e.g. local DNS server, web proxy, WEP key
– Change location, contact admin
• Diagnose faults across layers of network stack
19
Diagnosing Association Failure
If another peer has successfully associated with the AP:
Is Sec.
config
Same?
NO
Bad Sec. setting
(Fix it)
YES
Is BLR
much
higher?
YES
Bad signal
(change location)
NO
Similar card
Associated?
NO
YES
MAC Filtering
(contact admin)
S/w or H/w config
(change NIC or
update driver)
20
Diagnosis Features
• Inherent uncertainty in some cases
– Need info from AP to confirm MAC filtering
• Conflicting info from peers
– Used to eliminate branches in diagnosis procedure,
e.g. NIC type
• Vulnerability to bogus info from attackers
– Use information from large number of peers
– Susceptible to Sybil attack
21
Outline
• Introduction
• WiFiProfiler Architecture
– Sensing
– Communication
– Diagnosis
• Evaluation
• Summary
22
Evaluation
• Sensing: Low overhead
– (used < 1% CPU on 1.33 GHz laptop)
• Communication using VirtualWiFi:
– Healthy clients spend < 2 sec sending info
– Sick clients get information within 30 seconds
• Much of the delay in discovery (scanning delays)
23
Little Impact on Healthy Clients
25
Time (in seconds)
Download while Helping
20
Download when not Helping
15
Extra 0.5 to 3 seconds!
10
5
0
10K
100K
1M
Download Size (in bytes)
24
Effectiveness of WiFiProfiler
Too far from AP
MAC Filtering
Port blocked
Access Point
Port blocked
Port blocked
Relevant diagnosis at all clients within 30 seconds!
25
WiFiProfiler Summary
• Enables cooperative diagnosis in WLANs
– Without infrastructure support, low overhead
• Working system on Windows XP
• Future work:
– Security: Privacy, Sybil Attacks, Passive Mode
– Long-term Profiling
26