WiFiProfiler: Cooperative Diagnosis in Wireless LANs Ranveer Chandra, Venkat Padmanabhan, Ming Zhang Microsoft Research

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?”

3 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

4 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

5 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

6 State of the Art: Local Diagnosis Wireless Connection Manager, WZC Reasonable detection, Poor diagnosis Cannot Associate MAC Filtering Bad AP Bad WEP Key Bad NIC

7 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

8 WiFiProfiler Overview Create Information Plane Dissatisfied Machine (Cannot connect to WEP-enabled AP) Req. Health Health Info. (WEP key info) Diagnose Problem: Same WEP key? Access Point Healthy Client Health Info. (WEP key info) Healthy Client Diagnose range of problems across layers!

9 Faults and Some Causes No IP Address Security H/w or s/w DHCP Server No Association No AP Detected Location WAN congestion Wireless problem Poor Performance End-to-End Failure Firewall/proxy WAN Disconnect

10 Outline Introduction WiFiProfiler Overview WiFiProfiler Design Evaluation Summary

11 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

12 WiFiProfiler Architecture Sensing: What is monitored? Communication: How is it shared? Diagnosis: How are faults diagnosed?

13 Sensing Monitor health of client’s connectivity –Static info (e.g., NIC type) –Dynamic info (e.g., assoc. success/failure) H/w or s/w No Association Fault Some Causes Sensed Info NIC Model, Make, Driver version Auth/Encryption setting, key info Security

14 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

15 Communication 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? Req. Health Sensed Info D H Establishing the Information Plane

16 Discovery D initiates ad hoc network with distinct SSID –Special SSID format denotes request for help –H receives beacon even when associated to AP D Port: 5000 SSID: Help: :5000 H

17 VirtualWiFi Layer Virtual Interface 3 TCP/IP, Network Stack Virtual Interface 2 Application Layer User-level Kernel-level Approach: Virtualize card, buffer packets, switch b/w networks Virtual Interface 1 Wireless Card Parallelism using VirtualWiFi Details: Infocom ’04

18 Communication Protocol WiFiProfiler uses 2 (virtual) adapters: –Primary adapter activated in normal use –Helper adapter dedicated for WiFiProfiler Activated only when needed D H Port: 5000 SSID: Help: :5000 Primary VNIC Helper VNIC Scalability and Security discussions in paper

19 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

20 NOYES Diagnosing Association Failure Is Sec. config Same? Bad Sec. setting (Fix it) NO Is BLR much higher? Bad signal (change location) Similar card Associated? YES If another peer has successfully associated with the AP: YES MAC Filtering (contact admin) NO S/w or H/w config (change NIC or update driver)

21 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

22 Outline Introduction WiFiProfiler Architecture –Sensing –Communication –Diagnosis Evaluation Summary

23 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)

24 Little Impact on Healthy Clients Extra 0.5 to 3 seconds!

25 Effectiveness of WiFiProfiler Relevant diagnosis at all clients within 30 seconds!

26 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