Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure NetworksWireless Network WoesEnterprise Wireless ProblemsExisting ProductsContributionsOutlineAssumptionsClient-Centric ArchitectureDiagnostic Architecture PropertiesClient ImplementationTalk OutlineCauses of DisconnectionCommunication via Nearby ClientsSolution: Client ConduitClient Conduit FeaturesClient Conduit PerformanceSlide 17Locating Disconnected ClientsSlide 19Rogue AP ProblemsRogue AP DetectionRogue AP Detection OverheadsSlide 23SummaryFuture Work1Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure NetworksAtul Adya, Victor Bahl, Ranveer Chandra, Lili QiuMicrosoft ResearchAuthors’ slides2Wireless Network Woes•How many times have you heard users say:–“My machine says: wireless connection unavailable”–“Why can’t my machine authenticate?”–“My performance on wireless really sucks”IT Dept: Several hundred complaints per month•You may have heard network admins say:–“I wonder if someone has sneakily installed an unauthorized access point”–“Do we have complete coverage in all the buildings?”3Enterprise Wireless ProblemsMain problems observed by IT department:–Connectivity: RF Holes–Authentication: 802.1x protocol issues–Performance: Unexplained delays–Security: Rogue APs4Existing Products•Provide management/diagnostic functions–E.g., AirWave, CA’s NSM, Air Defense, Air Magnet•Insufficient functionality:–No support for disconnected clients–Weak root-cause analysis (raw data, mostly)–Diagnosis only from the AP perspective–Sometimes need expensive sensor deployment5Contributions•Flexible client-based framework for detection and diagnosis of wireless faults •Client Conduit: communication for disconnected clients via nearby connected clients•Diagnostic mechanisms–Approximate location of disconnected clients–Rogue AP detection–Performance problem analysis6Outline•Diagnostics architecture and implementation•Client Conduit: diagnosing disconnected clients•Diagnostic mechanisms–Locating disconnected clients–Detecting unauthorized APs–Analyzing performance problems•Summary and Future Work7Assumptions•Can install diagnostic software on clients–APs are typically closed platforms–Can provide improved diagnosis with modified APs•Nearby clients available for fault diagnosis–At least 13 active clients on our floor (approx. 2500 sq. feet)•Network admins maintain AP Location Database8Diagnostic APModule (DAP)Client-Centric ArchitectureRADIUS KerberosLegacy APDisconnected ClientClientConduitAuthentication/User InfoDiagnostic ClientModule (DC)DiagnosticServer (DS)9Diagnostic Architecture Properties•Exploits client-view of network (not just APs)•Supports proactive and reactive mechanisms•Scalable•Secure10Client Implementation•Prototype system on Windows•Native WiFi: Extensibility framework for 802.11 [Microsoft Networking 2003]•Daemon: most of functionality and main control flow•IM driver: limited changes–Packet capture & monitoring11Talk Outline•Diagnostics architecture and implementation•Client Conduit: diagnosing disconnected clients•Diagnostic mechanisms–Locating disconnected clients–Detecting unauthorized APs–Analyzing performance problems•Summary and Future Work12Causes of Disconnection•Lack of coverage–In an RF Hole–Just outside AP range•Authentication issues, e.g., stale certificates•Protocol problems, e.g., no DHCP addressCan we communicate via nearby connected clients?13Communication via Nearby ClientsPossible (unsatisfactory) solutions:•Multiple radios: extra radio for diagnostics•MultiNet [InfoCom04]: Multiplex “Happy” between Infrastructure/Adhoc modesPenalizing normal case behavior for rare scenarioConnected Client “Happy” (Infrastructure)Disconnected Client“Grumpy”Access PointCannot be on 2 networks. Packet dropped!SOSAdhoc Mode14Stops beaconingSolution: Client Conduit Connected Client“Happy”DisconnectedClient “Grumpy”Access PointDisconnected station detected Becomes an Access Point(Starts beaconing)SOS (Beacon)SOS Ack(Probe Req)Ad hoc networkvia MultiNetHelp disconnected wireless clients with:•Online diagnosis•Certificate bootstrapping DisconnectedClient “Not-so-Grumpy”15Client Conduit Features•Incurs no extra overhead for connected clients–Use existing 802.11 messages: beacons & probes•Works with legacy APs•Includes security mechanisms to avoid abuses16•Time for “Grumpy” to get connected < 7 seconds–Reduced time can enable transparent recoveryClient Conduit Performance17Outline•Diagnostics architecture and implementation•Client Conduit: diagnosing disconnected clients•Diagnostic mechanisms–Locating disconnected clients–Detecting unauthorized APs–Analyzing performance problems•Summary and Future Work18Locating Disconnected ClientsGoal: Approximately locate to determine RF HolesSolution: Use nearby connected clients•“Grumpy” starts beaconing•Nearby clients report signal strength to server•Diagnostic server uses RADAR [InfoCom00] twice–Locates connected clients–Locates “Grumpy” with clients as “anchor points”•Location error: 10 – 15 meters19Outline•Diagnostics architecture and implementation•Client Conduit: diagnosing disconnected clients•Diagnostic mechanisms–Locating disconnected clients–Detecting unauthorized APs–Analyzing performance problems•Summary and Future Work20Rogue AP ProblemsWhy problematic?•Allow network access to unauthorized users•Hurt performance: interfere with existing APsDetection goals:•Common case: mistakes by employees•Detect unauthorized IEEE 802.11 APs–Not considering non-compliant APsSolution: Use clients for monitoring nearby APs21Rogue AP Detection•Clients monitor nearby APs. Send to server:–MAC address, Channel, SSID, RSSI (for location)•Server checks 4-tuple in AP Location Database•Obtaining AP Information at clients:–Same/overlapping channel as client: from Beacons–AP on non-overlapping channel:•Active Scan periodically•AP information from Probe Response22Rogue AP Detection Overheads•Bandwidth usage < 0.2 Kbps per client•Can active scans be performed without disruption?–Sufficient idleness available (2½ – 3 min.)–Simple threshold-based prediction:Active scan completed in idle period for 95% cases23Outline•Diagnostics architecture and implementation•Client Conduit: