Tag Archives: wlan

iBwave Wi-Fi Training – Day Three

The final day of training with iBwave was primarily focused on a from scratch design to help ensure understanding of all the topics covered. The exam itself is a practical exam, meaning that you have to create a design and submit it for approval and wait up to seven days to find out if you passed. Oh the stress 🙂

The from scratch design was of a shopping mall that was a moderately small floor plan of about 100 meters in length (well small for a modern shopping mall). The specifications included information about capacity areas, equipment constraints, the number of users and so on. Have a real-world design scenario to wrap up the training was a good way to end it all.

Now that the training is over, I will take the exam in the next couple of days and then write a review of iBwave Wi-Fi and the certification program at the CWNP website.

My final take away from the training, in relation to iBwave Wi-Fi as a design tool is that it has the features and capabilities that most WLAN designers would need. It has some areas for improvement, as all tools do, but is a solid solution for WLAN design.

Just for fun, here’s some RF art courtesy of iBwave Wi-Fi’s propagation modeling:

RF Flame of Power
RF Flame of Power
RF Horizons
RF Horizons

Look for my post at CWNP.com in the coming weeks to get a more thorough and integrated review of the tool. As we are vendor-neutral at CWNP, it will not make an ultimate recommendation for or against the tool or compare it with other tools, but will give you all the information you need to make a good decision yourself.

My goal is to do the same exercise or similar with other design and Wi-Fi tools so that you can have excellent information to help you make buying and use decisions. As with many tools, you may very well find that you will use one tool for one type of project and another tool for another type (assuming a large budget [smile]).

Until then, thanks for viewing.


Tom Carpenter’s WiFiStat Tool

UPDATE: WIFISTAT has been modified so that you can run:

wifistat 0

For unlimited iterations. The three options now are:

  • wifistat
    • this will run 1 iteration
  • wifistat 0
    • this will run until you press CTRL+C
  • wifistat #
    • this will run for the number of iterations specified as #

Additionally, a timestamp is provided.

Here is a tool by request. WIFISTAT.EXE will show the Tx/Rx rate and signal strength for the current connection (WLAN) in dBm. By default, it lists the information and exits, like so:

WiFiStat.exe with No Parameters
WiFiStat.exe with No Parameters

Here is the tool with the parameter 5 (of course, if you move while running, the signal will change:

WifiStat.exe with a Parameter of 5
WifiStat.exe with a Parameter of 5

Here is the download, have fun. Like all my tools, it comes with no support and no error processing as they are created as learning experiments or for my own use [smile].

WiFiStat.zip Download


Tom Carpenter’s WiFiScan Tool

NOTE: Tool has been updated to resolve problems on some systems. (Feb. 13, 2017)

OK. I have a problem with NETSH. It shows signal levels in percentages based on a known algorithm, but gives no option to show dBm levels. Hence, WiFiScan.exe. This little tool will pull the NETSH information in, convert signal strength to show dBm as well (for strengths weaker than -50 and stronger than -100) and show them parenthetically after the percentage info. The command is the same as:


It goes against the default WLAN interface and has no parameters. I may modify it to allow for interface specification, but it serves my purpose for now. By the way, the conversion to dBm follows this logic:

if(quality <= 0)
    dBm = -100
else if(quality >= 100)
    dBm = -50 or better
    dBm = (quality / 2) - 100

The wifiscan.exe tool should be run while not connected to a WLAN. It will sort of work if you’re connected, but give you an error related to an array. I may fix that when energy returns. Here’s the tool, feel free to download and use at your own risk [smile]:

Download the Feb. 13, 2017 WiFiScan tool.


That Pesky SSID and Your Wireless LAN

The service set identifier (SSID) is meant to differentiate networks from one another. The default SSID should be changed on all access points having a default SSID. Access points are often set to a default SSID when they are first purchased. For example, most Linksys access points are set to the network name of linksys, most early Cisco access points had a default SSID of tsunami, most Netgear access points are set to netgear, and so on. These default SSIDs are widely documented on the Internet and are well known by any cracker. The fact that the SSID is still set to the default is often a glaring banner to the attacker that reads, “Please attack me as I am still configured to all default settings!”  While it may not be true that “all” settings are still at their defaults, let’s just say there is a very good chance.

When access points are first installed, the SSID should be changed to something cryptic and not something that could be used to determine the company to whom the access point belongs. This recommendation assumes that other companies may be nearby. If no other companies are nearby, the attacker can assume that any visible SSID with a good signal strength is the local company’s network. Changing the SSID to something meaningful such as a department name can provide an intruder valuable information. For example, if a wireless network is installed for the accounting department, and you set the SSID to accounting, any intruder will know there could be financial information on the network to which the access point is attached.  However, with all that being said, proper security makes it all a moot point – and you should have proper security (WPA2-Personal or WPA2-Enterprise these days).

Some wireless security professionals will suggest that you set the SSID according to strong password principles. I disagree with this suggestion as it implies that the SSID somehow affords security itself. While you can give away too much information about the intent of the network with the SSID name (such as in the accounting department example in the preceding paragraph), you cannot really ensure security through what you might call a cryptic SSID or a strong SSID. Skilled attackers can find and access a wireless network that has no security other than a cryptic SSID very easily. Ultimately, I suggest you use the SSID for its intended purpose: to differentiate between networks and not to provide security.

By default, an access point broadcasts the SSID several times per second in beacons (10 times for most standards-based implementations). By listening for these beacons, intruders are provided the opportunity to gather the SSIDs of any access point within range. “Closing the system” by not broadcasting SSIDs in beacons prevents intruders from passively locating the network. Closed system features are not part of the 802.11 series of standards and they are not supported on all access points. When SSIDs are not broadcast, operating systems like Windows XP do not automatically discover the SSID. This configuration causes a potential intruder to put forth a little more effort to gain access to the network—something an intruder may not be willing to do. Unless your organization is protecting something that a cracker knows is valuable, most crackers will attack the “low hanging fruit” first, meaning that any networks that are broadcasting an SSID will be the first targets for intrusion.

However, even when SSID broadcasting is disabled, the SSID can be discovered using utilities that perform active scanning (sending probe request frames) or wireless packet analyzers (which hear all frames types). Sometimes disabling SSID broadcasting may go against business goals, such as with public wireless networks. These networks must be open to allow customers to easily access network resources (usually Internet access). In the end, again, use the SSID for network differentiation and not for security.

Now, to be clear, you can certainly have different security settings associated with different SSIDs, but this is not the same thing as saying that SSIDs give you security. They do not. Can we rid ourselves of this thinking once and for all? I hope so.

SUMMARY: Use the SSID attribute to provide organizational structure to your wireless network and as an indicator to your users as to what network they are accessing. Do not use it as a security solution.

Headed to Wireless Field Day 3 (WFD3)

I have been selected as a delegate for WFD3 and will be attending in September. You can learn more about it here: http://techfieldday.com/2012/wfd3. This event is just one more thing that shows how great it is to be an IT professional. We understand community. We breath community. We are not the nerds in the basement anymore. Now, we’re the nerds on Twitter 🙂

Seriously though, the WFD3 event is going to be exciting. We get to visit with vendors and learn about the latest enhancements to their technologies for WLANs. I’m looking forward to learning new information and hanging out with the greatest techs in the whole industry: Wi-Fi geeks.

During the event, I will blog, tweet and post videos so that we can all learn together. If you don’t follow me yet, I’m at twitter.com/carpentertom. As I blog during the event, the blog posts will be duplicated here and at CWNP.com so you can check either location to see all that’s happening.

Currently, the delegates for the event are as follows:

Ryan Adzima A Boring Look @radzima
Tom Carpenter CWNP @carpentertom
Sam Clements SC-WiFi @samuel_clements
Daniel Cybulskie Simply WiFi @SimplyWiFi
Rocky Gregory Intensified @bionicrocky
Jennifer Huber I ♥ WiFi @JenniferLucille
Blake Krone Digital Lifestyle NSA Show @blakekrone
Chris Lyttle WiFi Kiwi’s Blog @wifikiwi
Sean Rynearson WiFiGeeks @Srynearson
Scott Stapleton Not your fathers WiFi @scottpstapleton
George Stefanick my802.11 @wirelesssguru
Gregor VuÄŤajnk 802dot11 @gregorvucajnk