WifiNigel

The Microsoft Network Policy Server (NPS) is often used as a RADIUS server for WiFi networks. It can provide authentication and authorization services for users on a wireless network. I put this document together to highlight one particular little 'gotcha' when using NPS with Windows 2008. Windows 2008 comes in three flavours: Data Centre Enterprise Standard When using NPS as a RADIUS server, you have to add a number of 'RADIUS clients' to the configuration of the NPS server. These are the devices on your WiFi network that will send the RADIUS requests to NPS each time a user tries to logon to the network. The screenshot below shows where RADIUS clients are configured in NPS: The RADIUS request contains username and password information for the user trying to logon to the network. The request is generally checked against a Windows AD domain to see if the user is supplying a valid set of AD credentials to access the WiFi network. In controll

Wireshark has an expression builder to help build filter expressions to filter out the frames that perhaps you don't want to see, or to allow you to select the frames would like to view. At first glance, the categories are pretty overwhelming due to the fantastic array of protocols that Wireshark can decode for us. I certainly had to dig around a little the first time I looked through the list before I found the WiFi related categories. I thought it might be useful to list the categories (that I have found so far!) that relate to WiFi traffic.  Here is the list, together with a brief description of each one: 802.11MGT - IEEE 802.11 Wireless LAN management frame 802.11MGT - Radiotap - IEEE 802.11 Radiotap Capture Header IEEE 802.11 - IEEE 802.11 wireless LAN IEEE 802.11 Aggregate Data - IEEE 802.11 wireless LAN aggregate frames Wi-Fi P2P - Wi-Fi Peer-to-Peer

I quite like to be able to see the frame type, sequence numbers and flags field when looking at a summary of an 802.11 capture in Wireshark.  However, Wireshark can be too helpful when decoding frames and  will display a summary of the frame which shows the detail of hight layer protocols (thus hiding the 802.11 summary info). This generally happens when decoding a capture of a WiFi network that has a guest network that is not using over the air encryption. Here is an example. Some data frames in the trace summary below are shown as ' https ' or ' Application Data ' frames, rather than layer 2 data frames: To prevent this behaviour, simply go to the " Analyze > Enabled Protocol" menu option in Wireshark and de-select 'LLC ': This will restore the standard 802.11 frame summary so that 802.11 frame types, flags etc. are available: One thing to bear in mind with this approach is that some exchanges you would normally decoded (e.g

Generally, when capturing and decoding frames in a wired network, there isn't a huge amount of interest going on at layer 2 of the OSI stack. There is pretty much one type of frame at the data link layer (i.e. an Ethernet frame), with all of the real 'interesting' stuff going on in layer 3 and above. However, when looking at 802.11 wireless packet capture and decoding, there are a whole host of different frames types at layer 2 that we might see. ( As a side note, layer 3 and above are often inaccessible to us in wireless captures as the payload of our layer 2 frames may be encrypted, rendering upper layers impossible to view. ) There are actually 3 types of frames we might see at layer 2 when performing a wireless capture: Management frames - these frames are used by wireless stations to join and leave a wireless network Control frames - these are used to assist with the delivery of data frames Data frames - these contain the actual higher-layer data that we want

Often when looking through a wireless capture file, there may be a number of frames which have been corrupted, but Wireshark has attempted to decode it as best it can. When a frame is corrupted, the frame check sequence of the frame will fail, indicating that some part (or parts) of the frame have errored during transit. When reviewing a trace, it can be very easy to miss the fact that the FCS is wrong and that you are essentially looking at a corrupt frame. This will often manifest itself bizarre frame types and field values which can lead you completely astray in your diagnosis efforts. There are a couple of ways to get around this. Firstly, you can add a display filter to remove all of the frames with a bad FCS ( wlan.fcs_bad == 1 ), but use this option with care (see note below): The drawback to this approach is that just because some frames fail the FCS, the actual frame that arrived at the destination station may have been OK. It depends on where your analyse

Meru access points, like many other controller-based APs, can use DHCP option 43 to acquire the address of the wireless LAN controller that they need to join. In brief, controller-based APs need to find their way back to a controller to obtain their operating code and parameters. Out-of-the-box, they don't know the IP address of the controller they should be talking to. When they are hooked to a wired network, they will request an IP address via DHCP. The DHCP process can also be used to pass them the address of the wireless LAN controller they should be speaking with (in addition to the usual parameters such as IP address, mask, default gateway etc.). DHCP option 43 is used to pass the WLC IP address information to the AP. However,  figuring out the format of the information that should be put in to the option 43 field can be something of a challenge, depending on the DHCP server you are using. I recently had to set up a DHCP server on a Cisco switch to provide IP ad

I've been doing some study for my CWAP  (wireless analysis) exam recently, so I've been spending quite some time staring at Wirehsark traces trying to figure out precisely what all of those 802.11 fields actually mean. One thing I noticed whilst pouring over a few capture files is that some of them seemed to have some additional fields included in the trace, which seem to have nothing to do with fields defined in 802.11 frames at all. They are in a section of the packet decode called 'RadioTap Headers'. I wasn't too sure what they were and why they are available in some captures, whilst in others they were missing. After a little bit of research, I found out a bit more information and thought it might be worth sharing in a quick blog post. In summary, radiotap headers provide additional information that is added to each 802.11 frame when capturing frames with an analysis application. Just to be clear, these are not part of the standard 802.11 frame form