1 / 39

802.11n Sniffer

802.11n Sniffer. Vladislav Mordohovich Igor Shtarev. Foreword. 802.11n is the new emerging WiFi Standard No suitable Sniffer is in production (as far we know)

erik
Download Presentation

802.11n Sniffer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.11n Sniffer Vladislav Mordohovich Igor Shtarev

  2. Foreword 802.11n is the new emerging WiFi Standard No suitable Sniffer is in production (as far we know) This project’s aim is to create one - a General description of it and technology basis of 802.11n are presented in the following slides

  3. APPLICATION DETAILED

  4. Features Logging “real” 802.11n frames via Radwin driver LOCALLY/REMOTELY Logging simulated 802.11n frames via “winpcap” REMOTELY (in WireShark format), including MSDU/MPDU aggregation simulation (both in send and receive) Building topology of visible network, including distance simulation between visible stations

  5. Features cont… Clear and concise user interface – both for embedded platforms and for Windows After each local sniffer is configured – all activity can be done from remote (start, stop, MSDU/MPDU aggregation trigger) Apart from remote GUI module – application is OS independent and Real Time / embedded OS compatible ( main modules are coded in C++ with RT and efficiency considerations)

  6. Features cont…(2) Can be used as a basis for other applications in the field – contains “OS UTILS” package, including common OS functionality and implementation for Win32 All software modules are strictly separated and communicating via clear and concise API – allowing code reuse OO designed and implemented

  7. General Design Overview • Two main components • Sniffer Client • Reports Server • The Client application resides on the machine with the physical 802.11n interface or “winpcap” interface, simulating 802.11n card. • The Reports Server can be installed on any host with IP access to the Client component (.net framework required for GUI, if used)

  8. General Design Overview (2) • The Client and the Reports Server are communicating via the Syslog Protocol: • Standard Event reporting protocol • Over UDP • There is no limitation on number of Client stations, connected to single Report Server.

  9. General Illustration Sniffer Clients Reports Server IP Network ……

  10. Sniffer Client Directly interacts with the RadWin driver Directly interfaces with “winpcap”, wrapping Ethernet packets with 802.11n envelop, including MSDU/MPDU aggregation Simple User Interface Syslog - UDP client Logs received from interface frames to simple log file (available only in Radwin version)

  11. Sniffer Client (2) • UI functions • Start sniffing • Stop sniffing • Configure Reports Server address (or disable feature) • Choose “winpcap” interface to listen (any of winpcap compatible network connections ) • Change working Frequency / Bandwidth of driver

  12. Reports Server • Syslog - UDP Server • WireShark Compatible report Database, including 802.11n format • UI (platform independent version) or GUI (windows host with .net framework installed) • Turn On/Off (local and each connected core) • MSDU/MPDU aggregation On/Off (for each connected Client)

  13. Application at work Run Client application on several PC’s in lab, all connected to one local net Run Server application on the same net Send “start sniffer” command from server to each connected Client Trigger MSDU/MPDU aggregation from server on each connected core

  14. Application at work cont… Send “stop sniffer” command from server to each connected Client All net traffic, excluding application internal UDP messaging, is “sniffed” locally to plain logs (Radwin version only) and remotely to plain and WireShark logs – one log per connected client See approximated net Topology

  15. Testing and known limitations • Application was tested with about 5 clients, with heavy internet traffic (P2P clients) • The most annoying limitation is a size of logged frame – only frames with size < 1024 bytes are logged. This limitation is due to SysLog protocol limitation on size of message (< 1024 including protocol preamble) • Because of the limitation above we have to trim Ethernet packets and in WireShark log file these trimmed packets appear as “Malformed”

  16. THEORETICAL PART(based on James M. Wilson - Intel,“Quadrupling Wi-Fi speeds with 802.11n”)

  17. 802.11n - Improvements • Modifications of 802.11a/g on PHY/MAC layer in order to deliver a minimum 100mega bit per second throughput on MAC Service Access Point (b- 5Mbps, g – 25 Mbps, a – 25 Mbps). • Requires backward compatibility with a / b / g.

  18. 802.11n Improvements cont… • 3 areas considered in order to improve performance • Radio technology – increasing the physical transfer rate • Effective management of enhanced PHY technology above • Data transfer efficiency – reducing performance impacts of PHY headers and turnaround delays

  19. Radio technology • Radio technology – • MIMO – multiple antenna systems for both transmitter and receiver. Antenna diversity and spatial multiplexing. Spatial Division Multiplexing (SDM). SDM spatially multiplexes multiple independent data streams, transferred simultaneously within one spectral channel of bandwidth. Evolving OFDM. • Widening channel bandwidth – from 20Mhz to 40 Mhz

  20. MIMO

  21. Effective management of PHY • MAC layer should establish and maintain adaptation to wireless channel conditions • Selection of modulation coding schemes • Antenna configurations • Channel bandwidths • MIMO channel selection

  22. Data transfer efficiency • MAC SAP layer improvements. • PHY header significantly limits achievable throughput . • PHY headers need to be longer to support the new advanced PHY Layer modes described earlier.

  23. Data transfer efficiency (2) • Introducing new aggregate exchange sequences • multiple MAC protocol data units (MPDU’s) are aggregated into a single PPDU (PHY protocol data unit) • Block ACK – single ACK for multiple MPDU’s in response to BAR (block ACK request) • Require longer PPDU’s than previous standarts allow (> 4095 bytes)

  24. AGGREGATION DETAILED(based on several internet sources)

  25. Frame AggregationScope of 802.11n An extension of the existing 802.11 framework The allowed changes are enhancements No existing functionality is subtracted Only those existing mechanisms that pertain in some way to higher throughput are altered

  26. Frame AggregationRationale(Effects of PHY data rate improvements) The 802.11n amendment calls for rates of at least 100 MBPs, as measured at the interface between the 802.11 media-access control (MAC) and higher layers The motivation is that the net data rate experienced by the user in wireless LANs is significantly affected by the many sources of overhead within the 802.11 protocol The overhead comes primarily from packet preambles, acknowledgements, contention windows and various interframe-spacing parameters

  27. Frame AggregationRationale (2) • Typical net data rates: • 802.11b - 5 to 6 MBPs (11 at PHY) • 802.11a/g - 20 to 24 MBPs (54 at PHY) • The high-throughput extension thus demands, at the very least, a four- to five-times improvement over the maximum achievable with 802.11a/g devices

  28. Frame AggregationIntroduction • Thus, since the overhead remains rather fixed, no improvements in PHY data rate can compensate for low throughput at the MAC level • To solve this issue the 802.1n amendment proposes MAC enhancements to maximize throughput and efficiency • The most important of these are the two Frame Aggregation mechanisms: • MAC Service Data Unit (MSDU) Aggregation • MAC Protocol Data Unit (MPDU) Aggregation

  29. MSDU Aggregation • A MSDU is the data unit received by the MAC from a higher level (LLC in 802.11) • The principle of MSDU aggregation is to allow multiple MSDUs to be sent to the same receiver concatenated in a single MPDU. • The efficiency is improved by increasing the actual payload size of the MPDU, specifically when there are many small MSDU to be sent (such as TCP acknowledgments) • Only one PHY header and one MAC header for multiple frames

  30. MSDU Aggregation (2) For an A-MSDU (Aggregated MSDU) to be formed, a layer at the top of the MAC receives and buffers multiple packets (MSDUs) The A-MSDU is completed either when the size of the waiting packets reaches the maximal A-MSDU threshold or the maximal delay of the oldest packet reaches a pre-assigned value

  31. MSDU Aggregation (3) • Since the aggregation is performed at the top of the MAC, and since there’s one MAC header for all sub frames, the following constrictions are applied: • All MSDUs must have the same TID value (QOS identifier within the MAC data service) • The destination address (DA) and sender address (SA) parameter values in the subframe header must match to the same receiver address (RA) and transmitter address (TA) in the MAC header The destination address (DA) and sender • The maximal A-MSDU size is 8K • A major drawback in using A-MSDU is under error-prone channels – by compressing multiple MSDUs into a single MPDU with a single sequence number, for any subframe that is corrupted, the entire A-MSDU must be retransmitted.

  32. MPDU Aggregation • A MPDU is the data unit forwarded by the MAC to a lower level (PHY) • The principle of MPDU aggregation is to join multiple MPDUs to be sent with a single PHY header • A key difference from A-MSDU is that A-MPDU functions after the MAC header encapsulation process

  33. MPDU Aggregation (2) Since each MPDU sub-frame includes it’s own MAC header, the A-MSDU restriction of matching TID no longer applies All sub-frames must be addressed to the same receiver Maximal length of an A-MPDU is 64K Maximal number of sub-frames is 64 because of the BA (block acknowledgment) mechanism

  34. MPDU Aggregation (3) In contrast to A-MSDU, A-MPDU is not retransmitted in it’s entirety after a failure of a subset of sub-frames The BA (block acknowledgment) mechanism is used to signal failed / succeeded sub-frames within an A-MPDU 802.1n introduces a compressed BA map frame – a bit map of 64 bits, each bit acknowledges a sub-frame of an A-MPDU

  35. Two-Level Aggregation

  36. Example • A 2304 bytes frame sent in the best case 802.11n scenario:  • Raw (PHY) data rate - 600 Mbps • No other contention for the medium • Net data rate - ~105 Mbps (17% throughput!)

  37. Example (2) • A-MSDU aggregation introduced into previous scenario:  • Raw (PHY) data rate - 600 Mbps • No other contention for the medium • Maximal frame size increased to 8K • Net data rate - ~250 Mbps (42%)

  38. Example (3) • Two level aggregation (A-MPDU added to A-MSDU):  • Raw (PHY) data rate - 600 Mbps • No other contention for the medium • Maximal frame size increased to 64K • Net data rate - ~510 Mbps (86%)

  39. Frame AggregationSimulation in the Project • MSDU • Each A-MSDU is generated with random number of sub-frames. Configured in code. • Several captured Ethernet Packets are buffered until the A-MSDU is filled. • MPDU • As with A-MSDU, A-MPDU’s sub-frames number is randomly generated. • Each sub-frame is sent without being buffered. • A sub-frame includes meta-information • Is a MPDU is part of aggregation • Is a MPDU is the last in aggregation

More Related