Chapter 2 - Data Units, their names and roles

As data is passed through the layers and sublayers, they take on different forms. Each with different information being added or stripped depending on the direction (up or down through the layers.) Each of these forms will have a different name to help differentiate them from each other.

MSDU - MAC Service Data Unit - This is the upper layer data from L7-L3 that needs to be passed along. Technically its actually the LPDU from the LLC that was passed along to the MAC layer thus making it a MSDU.

• All 802.11 frames that contain data have an MSDU. But Management frames do not contain any data so they don't contain an MSDU.

MPDU - MAC Protocol Data Unit - This is the MSDU that is being handed down to the PLCP (top sublayer in the PHY layer)

PSDU - PLCP Service Data Unit - This is actually the MPDU only now that its on the PHY layer its called the PSDU.

• The PLCP sublayer adds information to the PSDU and passes it along to the PMD sublayer calling that new data unit containing the PSDU and extra information a PPDU.

PPDU - PLCP Protocol Data Unit - This is the last stop. Everything that has been passed down from L7 and encapsulated is now ready to be transmitted. 

Chapter 2 - Beacon Frames

Beacon frames are a special type of 802.11 management frames. They contain a number of important information elements regarding the AP or STA's capabilities.

Timestamp - As discussed previously these are used for synchronization

Beacon Interval - Specifies the time between beacon transmissions

Capability Information - This is aptly named since it is used to communication various capabilities. Notably security requirements and if the service set is in an ESS or an IBSS. The book mentions that there are other capabilities advertised here that are specified in the 802.11 standard and its amendments, but does not go into further detail.

SSID - This is the ID or the "name" of the network that the beacon is identifying. I'd say this is a pretty important one.

FH Parameter Set - This is used by old Frequency Hopping STA's

DSSS Parameter Set - An element used by old DSSS PHY methods.

CF Parameter Set - This would be an element used with PCF. However since PCF is not actually used, this isn't used.

IBSS Parameter Set - Only used by STA's participating in an IBSS. Contains the ATIM Window information used for power saving in an IBSS.

TIM - Traffic Indication Map - An Element used by STA's that are using some form of power saving mode. Also the name of the enchanter in Monte Python and the Holy Grail

Supported Rates - This is a list of up to 8 data rates. Some of which would be "Basic" Rates. Defining these Basic rates, in turn defines modulation methods. Which essentially ensures that both the AP and the STA can speak the same language. From those basic rates there are other supported rates, and potentially other modulation methods that the beaconing device supports. But those are not required for a connection. They are just potential modulation methods if both the STA and AP support them.

Extended Supported Rates - This just includes other supported data rates that aren't included in the first 8 supported rates.

ERP Information - This element is only included on the 2.4GHz spectrum. Its used to communicate if a Non-ERP STA is in the cell, a neighboring cell is detected that only allows non-ERP datarates.

RSN - Robust Security Network (RSN) - This element contains information regarding the devices RSN capabilities. Such as their Authentication Cipher, Encryption Cipher, etc.

HT Capabilities - This is used with 802.11n networks, defining maximum MPDU length, short GI, various elements surrounding beamforming, and new to 802.11n (at this point) supported spatial streams.

HT Operation - Further defining some 802.11n capabilities. Such as channels, frequencies, and any protection modes being used.

 VHT Capabilities - Much like HT Capabilities defined 802.11n capabilities, this defines 802.11ac capabilities. Such as max MPDU length, short GI, beamforming options, and supported spatial steams and MCS's

VHT Operation - Defines the 802.11ac channels and frequencies 

Chapter 2 - Physical Layer Operations - In Depth... or at least deeper

Lets talk about the PSDU and the MPDU again. Guess what? They're still the same thing. Its just that they are called different things depending on what layer you are on. The MAC layer calls it the MPDU (Note the "M") and the  Physical layer calls it the PSDU (Note the "P") 

The book says its which side of the door you are on, is it the entrance or the exit. It's still the same door, its just a matter of from what direction are you looking at it. When you are outside its the entrance, when you are inside and looking at it, its an exit. Now, we could get all existential and say things like "Well, yeah, but if you are outside and looking at it, it could be an *exit* from the outdoors as well as an entrance." Sure, we could say that. But we won't. Because this isn't a philosophy class, we're learning about WiFi. 

So anyway, if you are at the Physical Layer, its a PSDU. If you are on the MAC Layer its a MPDU. Just to recap in case you have forgotten what all of the acronyms mean, like I did by this point.

PLCP - Physical Layer Convergence Procedure

PSDU - PLCP Service Data Unit - Yo dawg, I heard you liked Acronyms, so I put an acronym in your acronym.

Alright, so lets try and follow the path again.

If coming from the upper layers down to the Physical Layer - L3-7 info comes down to L2 which is split into two layers. The first one that it hits is the LLC, here the L3-7 data is in the form of an MSDU. That MSDU is then passed down to the next sub-layer of L2, the MAC sublayer. Here the MSDU is encapsulated into an MPDU. The MPDU is then passed down to the Physical layer. Which, like L2 is split into two sub-layers. The first one that it hits is the PLCP. Now that its here, its considered a PSDU. Remember going from L2 to L1 means that somewhere along the lines the MPDU went off to college and changed its name to PSDU because it thought that sounded edgier. Now that it has had its name legally changed, it gets a PHY header and a preamble added to it. Thus creating a PPDU or PLCP Policy Data Unit. The PPDU is then passed from the PLCP sub-layer down to the PMD sublayer, where its actually modulated as bits.  

Great! We just transmitted data wirelessly. Well, at least thats the progression of the protocol. 

Now lets take a bit of a deeper look at the PPDU, which remember is the PLCP Policy Data Unit. The components of the PPDU are the recently rebranded PSDU that was handed down from the MAC Layer (remember it was the MPDU at the MAC layer) the PLCP Header, and lastly, although it comes first in the transmission, the PLCP Preamble. 

A preamble? Like -- We the bits of this wireless frame? Well, in a way, yes. A preamble by definition is a preliminary or preparatory statement such as an introduction. Here, the transmitting station will send out a series of bits (1's and 0's) to give the receiving STA a heads up that the frame is incoming and how to synchronize to it. 

The book lists six different preambles. Three that were defined in the 802.11-2007 standard and another three that were defined in the 802.11n standard. If there were any additional that were introduced in 802.11ac they aren't in this book. But if I come across them I'll edit this. 

802.11-2007 Preambles

Long PLCP preamble 

Short PLCP preamble

OFDM PLCP preamble

802.11n additional Preambles

Non-HT legacy PPDU

HT-mixed PPDU

HT-Greenfield PPDU

Long PLCP Preamble

This is a 144-bit PLCP Preamble, with 128-bits of that coming in the form of a sync field, and the remaining 16-bits are a "Start of Frame Delimiter" (SFD) A receiving STA will start to synchronize with the incoming signal when it detects the sync field. But now that the synchronization has started, how will the receiving STA know when the actual data has started? Because it detects the SFD. As soon as the receiving STA hears the SFD, it knows that the PCLP Header is incoming. Its important to note that the receiving STA doesn't need to hear the entire Sync field, as long as it identifies the SFD. The Long Preamble is transmitted using DBPSK (Differential Binary Phase Shift Keying) at 1Mbps, as is the PLCP Header. However the modulation method of the PSDU is not necessarily the same as the preamble or the header.  It can be transmitted at 1, 2, 5.5, or 11 Mbps. The whole transmission of the preamble and header takes 192µs.

From the CWAP PW0-270 Book

Short PLCP Preamble

The Short PLCP Preamble is... shorter! In fact, its half the size at 72-bits versus the 144-bits of the Long Preamble. Those 72-bits are made up of a 56-bit Sync field and a 16-bit SFD. Note that the SFD is the same length with both Preambles. Their content is actually just reversed. The short Preamble is transmitted using the same DBPSK as the Long, transmitting at 1Mbps. However the Header is transmitted at 2Mbps using DQPSK (Differential Quadrature Phase Shift Keying) Just as with the Long preamble, the Short Preamble and Header both have fixed modulation, but the PSDU can differ. 

From the CWAP PW0-270 Book

OFDM PLCP Preamble

This is often referred to as the OFDM training structure - It uses 10 short symbols, and 2 long symbols with a guard interval separating them. Following the second long training symbol are Signal and the Data Fields. However between the training symbols and individual subsequent fields, are Guard Intervals. 

From the CWAP PW0-270 Book

PLCP Header

Following the Long and Short PLCP Preambles, comes the PLCP Header. It's 48 bits long and contains four fields. 

Signal (8 bits) - Indicates what modulation type the PSDU will be used to transmit the PSDU

Service (8 bits) - 5 out of 8 bits of this are actually used. Each bit thats used determines a different thing.

     - Bit 3 is used to indicate which modulation method is used. Whether its CCK (0) or the seldom used PBCC (1)

     - Bit 2 is used to indicate that the transmit and frequency clocks are derived from the same oscillator

     - Bits 5-7 are used to resolve data length field oddities if PBCC is actually used for whatever reason. 

Length (16 bits) - Indicates how long in microseconds will be required to transmit the PSDU

CRC (16 bits) - Cyclic Redundancy Check

But wait! There's more... with the ratification of the 802.11n amendment came two new PPDU's, and the sort-of reuse of an older one to allow for legacy devices to coexist with newer HT devices. Below are their explanations, and below that is a figure showing all three. 

Non-HT Legacy PPDU

This format was developed is for the standard to essentially mimic and provide backwards compatibility to legacy STA's. And is essentially the OFDM Preamble with 10 short symbols and 2 long symbols.

HT-Mixed PPDU

The beginning part of the HT-Mixed Preamble is the exact same as the Non-HT, with the 10 short and 2 long training symbols. This is so that legacy devices can decode the preamble and essentially understand enough to know that they have to wait to transmit, and that the following data isn't for them. The rest of it can be decoded by HT devices though. This HT portion contains information necessary for MIMO.

This is probably the most commonly used format for 802.11n since it supports both legacy and HT type devices. 

It works on both 20MHz and 40 MHz channels. If a 40MHz channel is being used, then all of the broadcast traffic that might be used by legacy devices needs to be sent on a legacy 20MHz channel. Obviously if a transmission is destined for a Non-HT client then they would be use only the 20MHz channel. 

HT-Greenfield PPDU

This method is *not* compatible with legacy devices. Because of this its support is only optional. 

From the PW0-270 Book

  

Of course mrn-cciew has a great writeup on this as well

https://mrncciew.com/2014/10/14/cwap-802-11-phy-ppdu/ 

Also, you may have noticed that the captions mention the PW0-270 book. Thats because it is. The CWAP-402 book touches on this, but only lightly (in comparison to the PW0-270 book). 

Chapter 2 - 802.11 Communications

This portion of the chapter discusses the methods/processes/procedures of finding and associating to an AP.  The 802.11 MAC layer has a number of mechanisms in order to do this, as well as to help traffic along.

Scanning - STA's are not just magically associated with an AP. They need to be able to find them first. Scanning is the methodology used to find BSS's. There are two types of Scanning, Passive and Active. These will be gone into further detail later

Synchronization -  There are certain features that may require the STA's to all reflect the same time. Beacon frames can provide a time stamp value for STA's to update their clock with

Frame Transmission - Nowadays this is DCF (Distributed Coordination Function)

Authentication - This takes place before the Association… its um, where the STA authenticates.

Association - The next step after a STA is Authenticated is becoming associated with the BSS. This process is much more akin to becoming associated with someone/something. The STA and AP find out various capabilities of each other. What they support, what they don't, etc. Much like getting to know someone.

Reassociation - We use wireless so we aren't tied to a specific location. As such, we often need to roam from one AP to another within the same ESS. To roam to the new AP, the STA must "reassociate" with it.

Data Protection - Since wireless uses plain ol' RF, it can be "listened to" by those who may be inclined to do so. Data Protection allows us to use encryption techniques to try and thwart potential attackers.

Power Management - Most, if not all STA's utilize battery power. Which, as anyone who uses a Smart Phone can attest, is a valuable commodity. With this in mind, Power Management features have been created to help optimize the battery life of these devices. They do so by allowing devices to go to "sleep" for certain periods of time. Therefore they don't "pull" any extra power.

Fragmentation - The wireless medium can have a number of influencers on its stability. Due to this, it may be prudent to fragment frames before they are sent. This will be covered more deeply later on.

RTS/CTS - Request to Send and Clear to Send are basic functionalities of the 802.11 standard. These help prevent (but are not 100%) hidden node issues. This too will be covered more deeply later on. 

Chapter 2 - MAC & PHY

Layer 2 - The Data Link Layer has two sublayers

• Logical Link Control sublayer - Shared sublayer across all 802 standards
• Medium Access Control sublayer

Layer 1 - Physical Layer is often abbreviated as PHY - Also divided into two sublayers

• Physical Medium Dependent (PMD)
• Physical Layer Convergence Protocol (PLCP)

Carpenter, Tom. CWAP: Certified Wireless Analysis Professional: Official study guide: Edition CWAP-402. Certitrek Publishing, 2016.

PMD and PLCP

PMD - Physical Medium Dependent - This is where the data is actually modulated. You can remember that because if you look at the name, its Dependent on the Physical Medium. At least if you read it backwards.

• The 802.11 standard states that every PHY provide different PMDs. The majority of these different PMDs are the modulation schemes.
• The MAC layer remains the same for most of the current PHY's deployed today. Although some will have special features. Such as protection mechanisms or optional features like QoS.

PLCP - Acts as a mediator and/or translator between the MAC layer(s) and the PMD. 

Chapter 2 - 802.11 Communications - Bits/Bytes/Segmentation/Encapsulation/etc. REALLY brief

Layer 4 - Segments (TCP) Datagrams (UDP)

Layer 3 - Packets

Layer 2 - Frames

Layer 1 - Bits 1's and 0's

There is a little discussion in this chapter about bits to bytes. As well as converting bytes to decimal values.

Chapter 1 - Troubleshooting Tools

As with any profession, the tools of the trade are incredibly important. A carpenter without a hammer or saw is just a person. Or a dentist without their picks and drills and other instruments of torture is just someone with an infatuation with dental health. Likewise, a WLAN Professional without the requisite tools, is just a person with a lot of knowledge about something people cannot see or touch.

Networking Tools
 

Throughput Tester: These are Tools like iPerf that test TCP/UDP traffic. Normally work off a client/server model to test throughput. It's important to note that throughput testers test for overall data throughput, not the data rate. This is incredibly beneficial when validating performance issues. Just because you have a fast advertised data rate, doesn't mean that your end-to-end throughput will match that. In fact, with normal overhead and contention, it never will.

Protocol Analyzer: These allow you to capture and decode frames and packets. A perfect example of this is Wireshark. According to the book there will be an entire chapter dedicated to Protocol Analyzers (understandably given the context of the book.)

Spectrum Analyzer: These allow you to actually see the RF. Not just the WLAN, but all of the RF in the area. Allowing you to determine the actual strength of the signal, pinpoint sources of interference, and determine the channel utilization. For the utilization piece again, its how much of the channel is taken up by all RF sources, not just WLAN ones. This is important because although you may not see any other networks on Channel 6 for example, due to a poorly shielded microwave or a wireless security camera, it might be more utilized than another choice of channel.

Operating System Tools

Ping: Used to test connectivity/reachability between devices. Sends an ECHO ICMP to the target IP address.

• -l (Lower case L) will change the data size in the ECHO message. The default ECHO message is only 32 bytes, so it may not reveal issues that a large message would.
• -t will run the ping continuously until a interrupt command is issued (Windows its CTRL+C) This can be used to verify random connectivity issues, or to consistent roaming, or when testing reachability during HA failovers.

Traceroute: Determines the "path" that packets take to reach their destination. Using ICMP ECHO's (much like Ping) Traceroute will show each hop along the route that the packet needs to take.

Pathping: This is essentially Traceroute, but with more details included in the response.

Nslookup: Used to query DNS servers to resolve hostnames to IP Addresses.

Netstat: Shows network statistics for all network connections from the host machine. This can be run "ongoing" to help show any new connections that are created.

Netsh: This is a Windows-Only command that shows information about both the wireless adapter, connections, and configurations. It has a number of sub-commands (my term) four of which are going to be focused on in the exam. Those are detailed below. Note: The command will be "netsh wlan" followed by the sub-command below. For example "netsh wlan show drivers"

• SHOW INTERFACES
• Shows details about the currently used wireless interface and profile.
• Including the Authentication type
• Channel
• Data Rate
• Signal Strength
• SHOW NETWORKS
• Shows all visible wireless networks
• To gain more detailed information the "mode=bssid" tag be added to the end of the command
• This will show you the actual MAC Address of the radio(s)
• Authentication Type
• Radio Type
• Signal strength
• Channel
• Basic Rates
• "Other Rates"
• SHOW DRIVERS
• Shows the actual wireless driver files being used by the adapter
• Shows the security methods offered/supported by the adapter
• Shows the PHYs that are supported
• SHOW PROFILES
• This will show all wireless profiles configured on the machine
• If a specific profile name is provided it will then show a more details about that specific profile
• Example "netsh wlan show profiles name="DCRWireless"
• If the additional "Key=clear" command is used at the end of the above command it will show the PSK in cleartext. Which is fun. Remember to lock your systems when you walk away from them kids.

Chapter 1 - Troubleshooting Methodologies

Troubleshooting Methodologies

Only the CWNP Troubleshooting method will be tested on. However the book goes into Cisco, Microsoft, and CompTIA's methodologies to compare and contrast them.

CWNP Troubleshooting Methodology:

1. Identify the problem.
1. Do this through asking multiple open-ended questions. Try to determine everything about it, where its happening, what device(s) the user is using, what application(s) its affecting, any recent changes, etc.
2. Discover the scale of the problem.
1. Is the issue isolated to just this one user? Is it an application issue that is causing issues across multiple devices and areas?
3. Define the possible causes of the problem.
1. As with everything in IT, there could be any number of causes for the issue. Narrowing down and defining these will help in the following steps. It could be anything from a wrong password, to a supplicant misconfiguration, to a down AP, to a down server hosting the application. Or it could be something random like the user changed departments, and their new role doesn’t allow them access to something they used to have access to and as such they are blaming it on the network.
4. Narrow to the most likely cause.
1. Using the list of possible causes, use what you know of the issue and of the environment to narrow the list to the most likely cause. Obviously some environments will be more prone to certain types of issues. Use your knowledge of these "traits" to figure out the most likely cause.
5. Create a plan of action or escalate the problem.
1. Now that you have identified what you think to be the issue. Create a plan of attack on how to fix the issue. If the cause of the issue is outside of your purview, then escalate the issue and potential cause to those who have the capabilities of fixing it. For example, if it’s a server issue, then escalate it to the team who handles the servers. Document the cause and course of action you plan on taking.
6. Perform corrective actions.
1. Execute on your plan established in Step 5.
7. Verify the solution.
1. If the plan did *not* work, then cycle through step 4 again for the next probable cause. Documenting everything.
2. Also ensure that roll back any steps you took during step a.
8. Document the results.
1. Really you should be documenting the entire thing.

Cisco Troubleshooting Process:

1. Define a clear problem statement with symptoms and potential causes.
2. Gather the facts to help isolate the possible causes.
3. Consider possible problems based on the facts discovered
4. Create an action plan based on the remaining potential problems and the most likely cause.
5. Implement the action plan.
6. As changes are made, gather results.
7. Analyze the results and determine whether the problem has been resolved.
8. If the problem is not resolved, create a new action plan based on the next most likely cause and proceed with steps 5-8. Repeat until resolved or escalated.

Microsoft Troubleshooting Process:

• Phase 1: Discovery - Gather information about the problem
• Phase 2: Planning - Create a plan of action.
• Phase 3: Problem Reproduction - Reproduce the problem, or determine that you cannot reproduce it. If you cannot reproduce the problem then you might not have enough information to confirm there is a problem.
• Phase 4: Problem Isolation - Isolate the variables that relate *directly* to the problem.
• Phase 5: Analysis - Analyze your findings to determine the cause of the problem.

CompTIA Troubleshooting Methodology:

1. Identify the problem.
2. Establish a theory of probable cause. - Question the obvious.
3. Test the theory to determine cause.
4. Establish a plan of action to resolve the problem and implement the solution.
5. Verify full system functionality, and if applicable implement preventative measures.
6. Document! Findings, actions, and outcomes.