|
|
|
|
Wireless LAN Explorer
| |||||||||||||||||||||||||||||||||||||||||||
 | General Page |
| General Statistics Page |
| IP Information Page |
| WLAN Page |
| 802.11 Page |
| Filters Page |
The tab page information is not complete at this release. Some pages are not populated at all at this point.
Press the Capture button to begin capturing on the selected adapter. The Capture dialog (below) will be presented when the Capture button is pressed.
The current Capture dialog (below) can be broken into three areas:
| Capture Controls (Top) - These control capture start/stop and display capture status. |
| Capture Log (Bottom) - A text box displaying capture log information. |
| Interface Controls (Right) - This panel includes various controls that can be used to control the adapter miniport. |
It is expected that the Capture interface will change significantly in future releases.
Each of these controls will be briefly described below. It is expected that the user of this tool will already be familiar with the basics of 802.11, the Microsoft WLAN API and the Microsoft NDIS API.
These controls are used to start and stop a capture, configure capture parameters and display capture status.
| Start Button - Starts a
capture operation. |
| Stop Button - Stops an
in-progress capture. |
| Buffers to Read - Selects
the number of buffer reads to perform during the capture. |
| Extended Logging - Controls
features used primarily for NDIS development and research.
|
The Extended Logging feature allows capturing of NDIS requests (and their completion) a they pass through the PcaFilter LWF driver as well as capturing NDIS status indications made by the lower-level miniport. This feature is useful in understanding how Windows manages a Native 802.11 miniport.
The Capture Status group displays basic information about the status of a capture operation.
The current packet display implementation is very crude.
The current packet read implementation is a process where multiple concurrent asynchronous read operations are initiated Each read is on a buffer that can be filled with multiple log records. As read operations are completed buffers that are read are placed in a Queue. A separate thread de-queues log buffers and generates the log text output.
The current log display implementation outputs information about each log record as verbose formatted text. This is a poor, but easy, way to demonstrate that the tool can fetch Native 802.11 packets and other information. Because of the simplicity and verbosity of this scheme, the text output takes significantly longer than the time to collect packets. An artifact of this simple approach is that the packet display will continue to be updated for a noticeable time after actual packet collection has completed.
Captured information is currently displayed in a simple text box. This is totally unsuitable for a production product for various reasons because of performance and resource considerations. However, this console-like output is something that this driver-writer can achieve. Leave it to others to beautify the output.
It may be useful to copy the Capture Log to a text file. To do so simply right-click on the text area. In the context menu select Select all and then copy. Paste from the clipboard into Notepad.
Example Capture Logs are described below. Note that the Capture dialog image above shows a Beacon and a data frame.
These controls should be considered experimental. Several of them are "state dependent" and a suitable state implementation has not yet been implemented. In addition, some controls such as specifying the PHY ID are not yet provided.
The bottom line here is that although as far as known these controls perform the requested operation, the results may be somewhat unexpected. Will be so until the "right mojo" is provided.
The interface controls do not change any value until the companion Apply button is pressed.
The Auto-Configuration control uses the user-mode Native Wi-Fi Api WlanSetInterface function and the wlan_intf_opcode_autoconf_enabled OpCode to enable or disable auto-config for the selected interface.
The Background Scan control uses the user-mode Native Wi-Fi Api WlanSetInterface function and the wlan_intf_opcode_background_scan_enabled OpCode to enable or disable background scan for the selected interface.
The Packet Filter control provides a limited capability to control the NDIS packet filter on the selected interface. In the current implementation choosing Promiscuous selects a packet filter of NDIS_PACKET_TYPE_ALL_802_11_FILTERS. The control uses a NDIS set information request on OID_GEN_CURRENT_PACKET_FILTER.
The Monitor Mode control uses the user-mode Native Wi-Fi Api WlanSetInterface function and the wlan_intf_opcode_current_operation_mode OpCode to set the current operation mode for the selected interface.
The Current Channel control uses a NDIS set information request on OID_DOT11_CURRENT_CHANNEL to set the channel on the selected interface.
The Miniport Reset control uses a NDIS set information request on OID_DOT11_RESET_REQUEST to reset the 802.11 station MAC and PHY layers.
The NIC Power Off control uses a NDIS set information request on OID_DOT11_NIC_POWER_STATE to control the NIC power state.
The state of all interface controls is updated by querying the 802.11 miniport after the Apply button is pressed on any control. To update the state of the interface controls at any time press the Refresh button.
More to come...
There are some behaviors that simply
aren't understood at this point. As of this writing all Native 802.11
adapter/miniport combinations tested so far have their own "personality".
Inconsistent behavior makes it difficult to finish the Native Wi-Fi controls.
Of course, some of the inconsistency could be blamed on the new WLAN Explorer software as well as an incomplete understanding of the Native Wi-Fi API.
As of this release only a few of the
Capture controls are implemented. Use of these controls should probably be
avoided.
In some
cases the WLAN Explorer application will report that it cannot open the
supporting NDIS driver. This problem has been identified as being caused when a
802.11 miniport driver unexpectedly fails a query on NDIS 6.0 Emulated 802.11
miniports. The fix is to improve the WLAN Explorer exception handling.
There is plenty left to-do:
Here are some examples of the Capture Logs taken from WLAN Explorer:
This log includes captures of beacon and data packets. Here is an excerpt showing capture of an outbound ping and its reply:
Block 6; Type NdisLogPacket; Length 132
Packet Length 92 - Outbound
Version: 0; Frame Type: Data
Sub-Type : Data
Control Bits: ToDS
Address1 : 00-18-39-B1-FD-5D
Address2 : 00-12-0E-B9-DD-8B
Address3 : 00-23-EE-1C-A5-CE
Frame Header: (24 bytes)
0000 08 01 00 80 00 18 39 B1 : FD 5D 00 12 0E B9 DD 8B ......9 ]... .
0010 00 23 EE 1C A5 CE 00 00 : .# . ..........
Frame Body:(68 bytes)
0000 AA AA 03 00 00 00 08 00 : 45 00 00 3C 3D 7F 00 00 ......E..<=...
0010 80 01 5D B5 C0 A8 0F 3B : C0 A8 0F 01 08 00 16 B4 ..] .; .....
0020 00 01 36 A7 61 62 63 64 : 65 66 67 68 69 6A 6B 6C ..6 abcdefghijkl
0030 6D 6E 6F 70 71 72 73 74 : 75 76 77 61 62 63 64 65 mnopqrstuvwabcde
0040 66 67 68 69 : fghi............
Block 7; Type NdisLogPacket; Length 132
Packet Length 92 - Inbound
Version: 0; Frame Type: Data
Sub-Type : Data
Control Bits: FromDS, ProtectedFrame
Address1 : 00-12-0E-B9-DD-8B
Address2 : 00-18-39-B1-FD-5D
Address3 : 00-23-EE-1C-A5-CE
Frame Header: (24 bytes)
0000 08 42 2C 00 00 12 0E B9 : DD 8B 00 18 39 B1 FD 5D .B,.... ...9 ]
0010 00 23 EE 1C A5 CE 40 D9 : .# . @ ........
Frame Body:(68 bytes)
0000 AA AA 03 00 00 00 08 00 : 45 00 00 3C 6A DF 00 00 ......E..<j ..
0010 FF 01 B1 54 C0 A8 0F 01 : C0 A8 0F 3B 00 00 1E B4 . T .. .;...
0020 00 01 36 A7 61 62 63 64 : 65 66 67 68 69 6A 6B 6C ..6 abcdefghijkl
0030 6D 6E 6F 70 71 72 73 74 : 75 76 77 61 62 63 64 65 mnopqrstuvwabcde
0040 66 67 68 69 : fghi............
Click here
to view a sample WLAN Explorer packet capture log.
This capture was taken with only Log Requests & Status selected in the Extended Logging control. The capture begins with an active connection. The connection was disconnected and then re-connected towards the end of the capture.
Click
here to view a sample WLAN Explorer NDIS request and status log.
For better or worse the WLAN Explorer application is written exclusively as Managed Code using C#.
The current release should be considered to be an ALPHA release. It is not fully featured and is not widely tested. Certainly there has been very little out-of-house testing.
The Capture controls are not fully functional at this point and their misuse may cause wireless connectivity to break. As far as known connectivity can be restored by disabling and re-enabling the 802.11 adapter. In rare cases it may be necessary to uninstall/re-install the 802.11 driver using the Device Manager to restore connectivity.
WLAN Explorer is provided as a Windows Installer MSI package.
Click
here to download The WLAN Explorer Windows Installer (32-Bit Edition).
2261.00KB (2315264 bytes)
Click
here to download The WLAN Explorer Windows Installer (64-Bit Edition).
1804.00KB (1847296 bytes)
All that should be required is to run the installer. The installer installs the supporting NDIS filter driver.
Uninstall WLAN Explorer using the Add/Remove programs facility as you would any other software. The uninstaller should uninstall the supporting NDIS filter driver.
If you have an interest in receiving notifications when WLAN Explorer is updated, please send an E-Mail with subject "WLAN Explorer Update Notification Request". I'll send a notification occasionally as updates are posted. Send the request to:
tdivine AT pcausa DOT com
|
Release Overview |
||
| V4.00.00.24 | June 1, 2010 | Fixed bug that caused "Unexpected error opening adapter" exception on Vista when NDIS 5 filters were present. |
| V4.00.00.23 | February 25, 2010 | Added exception handler for dealing with packet read operations that are cancelled. |
| V4.00.00.15 | January 28, 2010 | Initial technology demonstration release. |
01/28/10
|
PCAUSA Home ·
Privacy Statement ·
Products ·
Ordering ·
Support ·
Utilities ·
Resources
|
