Just another site

A Voice Of Reason On Voice Over WiFi

leave a comment »

Voice over WiFi is scary.  Retries, packet errors (due to lots of Retries) and high latency (usually due to packet errors that happen because of lots of Retries) will murder a WiFi network’s ability to handle Voice and leave your users screaming (not actually screaming) like they were cast in a horror movie (or, at the very least annoyed like a character from Office Space).  But there’s one thing that sometimes scares people, but really shouldn’t: Voice Arbitration.  It’s not going to kill your WiFi voice calls.  In fact, it will almost certainly help.

Arbitration is a process defined in the 802.11 standard.  Every device (client/station and AP) goes through it.

The simplest way I can describe 802.11 Arbitration is like so:

If your AP or station has heard a quiet channel for 37 microseconds (0.000037 seconds), then your AP or station transmits a frame (what most people call a packet, but I call a frame).

If your AP or station has been hearing a busy channel for the past 37 microseconds, then it enters Arbitration. Arbitration is the process by which APs and stations go through a series of procedures in order to avoid devices sending at the same time (and, thus, causing a collision).

The big worry some people have is that Voice will mess up Arbitration.  That it will make it MORE likely that collisions will happen.  The Voice QoS category (as originally defined in the 802.11e amendment) reduces the amount of randomness in Arbitration.  For ordinary (called Best Effort in 802.11e), APs and stations choose a random value between 0 and 15 (on their first try; retries choose from exponentially larger random pools of values).  Voice applications (at least, applications that get tagged as voice by the AP or station) choose values between 0 and 3.  The problem comes when two devices (APs or stations or one of each) choose the same random value during Arbitration.  If that happens, then both devices try to transmit at the same time and most likely a collision occurs.  Two devices choosing the same number between 0 and 15 could happen, but maybe not all that often.  Two devices choosing the same number between 0 and 3 would be far more likely.

The flaw in this thinking is that devices have to be in Arbitration at the EXACT same moment for the 802.11e Voice category to become a problem.  Most likely, they won’t be.

Even though voice applications seem like they’re always running, they’re really not.  Each voice packet only uses about 300 microseconds* (assuming a 39 Mbps data rate — because smartphones don’t support MIMO — and the use of RTS/CTS) or 150 microseconds (if RTS/CTS is not used) of channel time.  And a modern voice application is going to have at most about 90 packets go over the wireless channel per second (combined send and receive).  That’s not a whole lot of channel time.  If we take the example of an iPhone on a typical WLAN — where RTS/CTS is used when the iPhone sends, but not used when the AP sends — that’s only 20,250 total microseconds being used.  20,250 microseconds is 20.25 ms.  Or 0.02025 seconds.  In other words, each phone is only using about 2% of the available channel time when a call is active.

If all of these numbers are too much, here is a visualization of how often a typical voice app is actually using the wireless channel:

The red and blue mean that the channel is occupied, while the empty boxes mean that the channel is unused**.

 Look at all of that open space.  And remember that open space is not the only way that collisions are avoided.  Collisions are avoided if:

-A phone becomes ready to send data while the channel is clear.
-A phone becomes ready to send data while another phone or AP is already sending data (assuming the devices can hear each others’ transmissions).

The only way a collision can occur due to an Arbitration match is if two or more devices begin attempting to send data at the exact same time.  For applications that use as little channel time as voice, that’s just not very likely to happen.

I have found the 802.11e Voice category to not cause problems in high density/congested environments.  In fact, I’ve found it to help.  When voice applications use the 802.11e/WMM Best Effort category instead of the Voice category, an extra 63 microseconds*** gets added to the packet transmission process.  That’s about a 20% jump in used channel time for devices that do use RTS/CTS and a whopping 40% jump for devices that don’t. That means more channel time per packet.  Using more channel time per packet is an actual problem, because it leads to the real reason that collisions tend to happen.  Collisions most often occur because one device is in the middle of sending and another device can’t hear it.  More channel time being used by each packet is most likely going to exacerbate the problem of collisions, not minimize it.


*All time calculations include 28 microseconds for a Voice AIFS, 18 microseconds for the Random Backoff (that’s two slot times), 10 microseconds per SIFS, 50 microseconds for non-HT physical layer headers (used by RTS, CTS and Block Ack frames) and 40 microseconds for HT physical layer headers (used by Data frames).

**That little graph has 10,000 boxes, meaning that each box could represent 100 microseconds.  The red dots are a visualization of how much channel time is being used when the iPhone sends (300 microsecs, including RTS/CTS) and the blue dots are a visualizations of the AP sending (since 150 microsecs would mean 1.5 boxes, I just represented half of the AP’s packets with two boxes and half with one box). 

***63 microseconds is calculated by adding an extra 9 microseconds to the AIFS (the Best Effort AIFS is 37 microseconds) and by adding six extra 9 microsecond slot times for the Random Backoff.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

February 24, 2015 at 10:31 pm

Free Sniffing in Windows! (Kind Of)

with one comment

Nine months ago (bad way to start a blog post, I know) I wrote a blog about the future of WiFi sniffing.  In the comments section (perhaps the only worse thing for a blogger to say), someone mentioned a free, Windows-based application called Acrylic WiFi.   I briefly checked out the app and dismissed it as yet another Discovery utility disguised as a something more. 

Then I actually used Acrylic WiFi and…  it works!  It sniffs WiFi frames (sort of) and it does it for free (outside of the cost of an ordinary 802.11 USB adapter)!  This changes everything (kind of)!

For years, the method for free WiFi sniffing on a Mac has been simple.  Head down to the bottom of this post for a reminder.

Now, we can do similar things in Windows.  It’s not quite as simple and it’s not totally free, but it works (pretty much).

1. Download and install Acrylic WiFi Free, including Monitor Mode support (and, actually, if you can find an old download of Acrylic v1, then you’ll be able to save captured frames in a *.pcap file, just like you can in Mac OS X Wireless Diagnostics.  If you download Acrylic v2 [the current version], then you can’t).

2. Procure (see, I can use corporatey talk sometimes too) a USB adapter that allows monitor mode capture in Acrylic (I use the Netgear A6200, and if you use that link then you’ll be supporting this blog by giving me a kickback from Amazon).

3. Open Wireshark (and if you’re a Mac user running 64-bit Windows in Bootcamp or as a Virtual machine, you’ll have to Run as Administrator).

4. Select the Acrylic NDIS Netgear A6200 (or whichever model of USB adapter you procured) Adapter and click Start.

Bingo!  A real-life 802.11 Monitor Mode capture in Windows (just about), done for free!  (Actually, for the cost of an ordinary WiFi USB adapter, but still…)

And here’s a tip for enabling a channel scan by using Acrylic with Wireshark:

Normally, Wireshark only allows for monitor mode capture on a single channel.

Just look at that screenshot above.  No channel scanning option to be found.  

If you decide that you want to scan channels for whatever reason, all you have to do is let Acrylic control the capture.  Just open Acrylic (while keeping Wireshark open and capturing), click Monitor in the upper right until it says, Monitor: ON, and then click the channel number just to the left to choose which channels you want to scan.  See:

Fantastic.  We can not only do a (nearly) free monitor mode capture with channel scanning in Windows (more or less).

About that, “more or less” (and the “kind of” and “sort of” and all the rest)…

Monitor mode capture with an Acrylic driver is flawed.

Check out this little capture I did of my iPod Touch (the most underrated device in the history of WiFi site surveying, troubleshooting and analysis, by the way) streaming the 2015 Royal Rumble on WWE Network:

Specifically, check out the Rate column in that screen shot.  Every single cotton-pickin’ frame captured by my Netgear A6200 using the Acrylic WiFi driver shows the same rate: 0.0 Mbps.

(And just to show that it’s not a problem with my setup, here’s what it looks like when the Airpcap NX adapter does a monitor mode capture into Wireshark:

Notice that the rate of 58.5 Mbps comes through loud and clear.)

So, there you have it.  You can now do free sniffing in Windows, but there are still kinda/sorta limits to how useful it can be.


If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi


Free sniffing in Mac OS X:

1. Open Wireless Diagnostics (in Mac OS X 10.10 [Yosemite], holding down alt/option while clicking the WiFi Settings icon on the top menu bar reveals Wireless Diagnostics).

2. Open the Sniffer window (older versions of Mac OS X have different methods of sniffing, but a monitor mode capture has always been an option in Wireless/WiFi Diagnostics).

3. Choose your Channel and click Start.

4. When finished, click Stop, and then go to the Desktop to open the captured frames (in the form of a *.pcap file) in Wireshark.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

January 27, 2015 at 7:33 pm

How Fast Is My 802.11ac WiFi?

leave a comment »

802.11ac is the latest and greatest WiFi standard, but it’s confusing.  So many questions: Is it really that much faster than 802.11n? (It can be.)  Is it worth upgrading?  (Probably not in the enterprise, but at home, absolutely.)  How fast is my device?  (Data rates as low as 6.5 Mbps and a high as 1.3 Gbps.)  

Getting specific answers to 802.11ac performance questions can be a chore sometimes, but there’s a simple way to check your APs.  All you need is a wireless sniffer and about five minutes.

Today I wanted to find out what my 802.11ac AP is capable of.  I suppose I could’ve gone in search of a data sheet, but instead I decided to break out the wireless sniffer.  It was a quick and simple process.

Step 1: Find the channel of your AP

If you’re a Mac OS X user, you can use Wireless Diagnostics.  If you use Windows, then Acrylic WiFi is probably your best option.

My channel was 48.

Step 2: Capture on your channel 

Using a professional protocol analyzer like AirMagnet WiFi Analyzer or WildPackets OmniPeek is usually best.  If you need to keep it free (but remember, free sniffer software almost always means having to spend/waste more time once it’s time to get a job done), then OS X users can use the Wireless Diagnostics Sniffer window and Windows users can install Acrylic WiFi drivers on certain USB adapters and capture into Wireshark.

I started a capture in OmniPeek on Channel 48.

Step 3: Filter on Beacon frames

If you use Wireshark, then type the following in to the Filter text box and click Apply:

wlan.fc.type_subtype == 0x8

I used OmniPeek, so I went to the Filters window (link on the left hand menu bar), opened the Wireless filters and selected the 802.11 Beacons filter.

Step 4: Open a Beacon from your AP

This is the only step where things could get tricky.  You need to make sure that you are looking at your AP and not the neighbors.  In Wireshark that means you might have to try out source MAC addresses until you find one that looks like your AP.

In OmniPeek, I went to the Packets window (again, via the link on the left hand menu bar), enabled the Decode column (by right-clicking any of the existing columns and scrolling all the way to the bottom in order to select Decode) and then selected the SSID field within the SSID information element.  I was then able to see the SSID of every Beacon frame by looking at the Decode column.

Step 5: View the VHT Supported MCS Set

Once you have found a Beacon from your AP, you’ll have to open up the Beacon’s decode and find the VHT Capabilities information element.

In OmniPeek, the VHT Capabilities information element was down towards the bottom.  Once I found it, I opened it up and was able to see the VHT Supported MCS Set.

The key thing to look for is the number of lines that read “10”.  A line that reads “10” indicates that a spatial stream is available.  A line that reads “11” indicates that no spatial stream is available.  That means if three lines read “10” and the remaining five lines read “11”, then there are three (of the possible eight mentioned in the 802.11ac standard) spatial streams available for my AP.

What does that mean for data rates?

1 spatial stream: 6.5 Mbps to 433 Mbps data rates
2 spatial streams: 6.5 Mbps to 867 Mbps data rates
3 spatial streams: 6.5 Mbps to 1.3 Gbps data rates

The reason that multiple spatial stream devices can use single stream rates like 6.5 Mbps is that all 802.11ac devices allow MIMO (the technology behind multiple spatial streams) to be used to improve range instead of speed.  So, my three-stream 802.11ac AP could use its MIMO powers to increase range by keeping the data rate as low as 6.5 Mbps.

This whole process should take you less time than it took to read this blog post (which doesn’t say much about Yours Truly’s relationship with brevity, but I digress).  Once you know what your APs support, it will be that much easier to set up a WiFi network that fits your needs.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

January 27, 2015 at 12:45 am

Posted in 802.11ac, Data rates

Killing My WiFi (With This Song)

leave a comment »

Spec-ing the Layers with WiSpy
(one time, one time)
Channel gone red with this stream
(two times, two times)
Killing my channel with this song
Killing my WiFi
With this song
Taking my WiFi
With this stream
Killing my WiFi
With Bluetooth spe-ee-ee-eeakers…

Wireless streaming (music, video or, in the case of the wonderful song referenced above, a music video) can sure kill a WiFi connection.  It’s good to have a spectrum analyzer to identify the problem.  It’s even better to remember to use it.

Wireless streaming devices are popular nowadays, but most of them are benign.  An AppleTV, for instance, can wirelessly stream audio and video or it can act as a mirroring device for whatever audio or video is on your smartphone, tablet or laptop.  (And mirroring is tougher on WiFi than basic streaming.  When I mirror my iPhone 5, I’m creating three streams.  One from my wireless router to my phone for the Internet stream, a second from my phone back to the wireless router as part of mirroring and then a third from my wireless router to my AppleTV, also as part of mirroring.  Mirroring is a real bandwidth hog.)  When I stream or mirror to an AppleTV, the wireless audio or video is all using WiFi.  The 802.11 standard (which is what WiFi is based on) has excellent sharing protocols built in, so that my other WiFi devices don’t get killed by my streaming or mirroring.

Non-WiFi streaming devices can be a big problem.  Sonos systems, for example, are commonly set up using a non-WiFi wireless technology.  In fact, if Sonos audio is used as part of a home theater, non-WiFi wireless is required.  Sonos, and many other non-WiFi streaming systems, use the 2.4 GHz frequency band.  Some speakers may use Bluetooth and some may use a proprietary technology, but it’s almost all 2.4 GHz.  And when it’s in the 2.4 GHz band and it’s not WiFi, then it doesn’t share the way 802.11 devices do.  It creates interference.

So, what to do about 2.4 GHz interference?  First of all, don’t do what I did when I was trying to help a friend set up his WiFi recently.

My friend is paying for 150 Mbps Internet download speeds, but he was getting less than 1 Mbps.  He was using a wireless modem from the phone company, and the wireless modem is a model that I’ve had problems with before.

I was faced with an important choice:

A) Troubleshoot like a professional by working my way up the OSI layers.  Start with the physical layer by running a spectrum analyzer (I use Metageek WiSpy 2.4x with Chanalyzer software.  Lots of people use WiSpy DBx because it allows for analysis of the 5 GHz band, but that is unnecessary and can sometimes even be counterproductive).  Then move to the MAC layer by checking devices’ WiFi Settings and possibly using a Protocol Analyzer.

B) Act like I know everything and complain to the phone company about their crappy wireless modem.

Naturally, I chose B.  After wasting hours on the phone with the phone company (hours that we were supposed to be spending seeing “Top Five” before the Kings vs. Maple Leafs game), I finally set up a 5 GHz radio with a separate SSID and saw the Sonos interference magically (not magic, of course, because Sonos systems only ruin the 2.4 GHz band) disappear.

The moral(s) of this story?

1) Avoid acting like a know-it-all when troubleshooting wireless problems.

2) Start with a quick spectrum sweep if audio/video streaming is happening nearby.

3) Don’t sleep with your co-star if you don’t want to get divorced.

One last little note: I’m often a critic of spectrum analyzers.  I see people (people on Twitter, people on blogs and especially people in real life) use them incorrectly all the time.  “If you’re looking at Duty Cycle, you’re in the wrong place,” is a saying that I like using when it comes to using spectrum analyzers in WiFi environments, for example.  But spectrum analyzers are darned good for one very specific use: identifying things (speakers, microphones, security cameras, microwave ovens) that are killing your WiFi (with or without this so-oo-ooooong).

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

January 6, 2015 at 10:07 pm

An Android Change for the Better (Maybe)

with one comment

Chatty smartphones have been an issue for years.  Whether you’re concerned with security or performance (or both), the amount of Probing being done by unconnected iPhones, Galaxies and the like has been worrisome.  

Today, things have changed.  Smartphones don’t Probe as much.  This is probably for the better, but there could be a catch.

I’m an Apple guy.  Even when I was using PCs in college (things were different back in the 90’s, I tell ya), it was always because they were free.  Once I finally had to buy a computer, I went straight to the very first iBook in 2001.  I own an iPod, iPad, iPhone and MacBook Air.  My next computing purchase will probably be an iMac (to better record those promised-but-not-yet-delivered online training videos on WiFi that I touted six months ago).  So, I like the company.  And I like bashing its competitors sometimes.  (Not my most magnanimous trait, but nobody’s perfect.)

I liked pointing out that Google’s Android operating system had worst wireless security than Apple’s iOS.  Including:

-Apple requires server certificate validation by default for WPA2 Enterprise authentications (even if it is user-controlled), while Android does not.

-Apple smartphones and tablets Probe only for hidden SSIDs, like so:

(That’s a Probe Request filter in WildPackets OmniPeek.  The SSIDs that you see in those Probe Requests are all hidden SSIDs, with the exception of “Google Starbucks”.  Read on to learn why my local Starbucks’ SSID is showing up in there.)

-Android smartphones and tablets Probe for all saved SSIDs.

At least, they used to.

I was demonstrating the inferiority of Android’s wireless security recently when I learned something new.  They’re not inferior anymore.  Some time recently (or, at least in between the time of my previous Android OS update and my recent update to Android 4.2.2) Google changed Android devices’ wireless behavior to match that of Apple’s.  Android smartphones and tablets started Probing for hidden SSIDs and staying quiet for broadcasting SSIDs, like so:

Of course, I was ambivalent.  GOOD that Android devices’ wireless security has improved!  BAD that I can no longer tout Apple devices’ wireless security superiority in comparison!

So, there you go.  A begrudging admission that Android’s wireless security has been shorn up to match the level of Apple’s.  (In fact, Android’s wireless security is even considered superior in some circles because Android has an option to eliminate user-based verification of server certificates during WPA2 Enterprise authentication.  But we don’t need to discuss that right now.)

But… (and, there’s always a But)

…this may actually be bad for mobility.

Apple iOS and Android devices don’t Probe unless they connect to a hidden SSID.  Nice.  But, let’s take a step back.  Why is Probing in the IEEE 802.11 standard to begin with?

Probing (a process where a client/station device sends a Probe Request frame in order to elicit a Probe Response frame from an access point [AP]) is in the 802.11 standard to facilitate mobility.  Roaming.  Handoff.  Whatever you want to call it when someone moves out of the range of one AP and into the range of another.  Probing also helps devices connect more quickly when starting/waking up and can help devices find an AP in areas that are congested with neighboring WiFi devices and APs.

So, Probing can be a good thing.  Especially for mobile devices in crowded areas.  And now Android devices (like Apple iOS devices) do less of it.

If you say to yourself, “gosh, this iPhone/iPad/Galaxy/HTC One seems to really crap out when I go to a crowded place” (like the Starbucks by my place in Los Angeles), then you might want to ADD Probing to your device.  How?  By tricking your device into thinking that the SSID is hidden.

That’s what I did at my local Starbucks.  My phone sends out these Probe Requests…

…because I manually added the “Google Starbucks” SSID to my phone.  Instead of tapping on “Google Starbucks”, I tapped Settings -> Wi-Fi -> Other… (ellipse in the GUI, not added by me) once I got in line for a Tall Skinny Peppermint Mocha, Hold The Whipped Cream and then typed in “Google Starbucks”.  I don’t know if it helps a whole heck of a lot (Starbucks still uses the darned Captive Portal, which will slow down any wireless connection), but it does optimize a couple of things.
In summary, Android’s move to Apple-like wireless behavior is good for security and overall channel performance.  But if your problems are mobility and speed of connectivity, then you might want to un-do what Android has done by adding your SSID manually.
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

December 19, 2014 at 8:33 pm

Not Sniffing, But… Oscium WiPry-Pro

leave a comment »

It’s been over two-and-a-half years since yours truly last wrote about Oscium WiPry, but there is reason to today: they fixed it!  Now the only 2.4 GHz spectrum analyzer for Apple iOS reads signal level correctly.  And using the new, corrected version reminded the author why WiPry is a nice product at a reasonable price.

The concept of a spectrum analyzer hasn’t changed in decades, and for good reason.  It’s simple.  A device listens for activity at a given frequency and displays a readout of said activity, usually in a fancy, colorful way.

In the last two years, however, many things have changed about spectrum analysis for WiFi.  PC card slots have become increasingly rare, thus leaving the Cisco Spectrum Expert in the margins.  Sensor-based spectrum analysis has increased in popularity.  Metageek, makers of my favored spectrum analyzer, stopped offering free software with their signature WiSpy series of spectrum analyzers.

What hadn’t changed in the last couple of years was the signal readings for Oscium WiPry.  They remained about 63 dB higher than they should have been.  The incorrect display wasn’t a dealbreaker, because WiFi spectrum analysis isn’t (or, at least, shouldn’t be) about precise decibel levels.  It’s about locating interference sources.  WiPry did a fine job showing lots of activity when an interference source was near.

The new WiPry is an improvement.  The signal readings are finally accurate!

Check that above screenshot out.  The horizontal line reads around -70 dBm.  The SNR comparison with the dotted noise floor line below is about 25 dB.  Excellent!  Those were the real numbers in the office where I ran my test.
Oscium made an adjustment to the WiPry’s form factor in giving it a Lightning connector instead of the old 30-pin connector.  That was a nice update, especially since I have been using my iPod Touch a lot for troubleshooting and surveying.  I’ve learned that spectrum analysis is really only useful to WiFi folks when looking for an interference source, so I don’t really need a device the size of an iPad.      I prefer the lighter, smaller iPod Touch.  And if you do like the screen size of the iPad, then Lightning will work for any iPad that was released after the iPad 3.
(At this point I should offer a link to my previous blog post on why I find spectrum analysis to be an inadequate form of WiFi troubleshooting.  That post was written months ago, but if anything my view on protocol analyzers’ superiority to spectrum analyzers has only hardened.  Maybe someone will let me debate the topic at the next WLAN Professionals Conference.)
The Oscium WiPry Pro is $200 and the software is a free download from the App Store.  If you’re just using a spectrum analyzer to locate interference sources, then it’s a nice piece of equipment to have.
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

October 27, 2014 at 11:24 pm

Not Sniffing, but… Fluke Networks LinkSprinter

leave a comment »

It’s time to switch things up a bit.  WiFi sniffing is a fascinating topic and all, but good ol’ Yours Truly wants to try something new.  

This will be the first in the “Not Sniffing, but…” series on the Sniff WiFi blog.  I come across interesting topics outside of sniffing all the time, so I want to add short blog posts on some of these topics.

Several months ago WLAN bon vivant Keith Parsons posted a blurb on his blog about the Fluke Networks LinkSprinter.  I contacted someone from Fluke Networks to ask about the LinkSprinter, and they were gracious enough to send me one to test.

LinkSprinter is a wired testing tool.  It’s more for people who install APs than for people who, like me, primarily do frame captures.  Still, we both do troubleshooting.  The LinkSprinter is definitely for troubleshooting.

The tool is pretty simple.  You plug in an Ethernet cable, and you press the lone button to start the test.  You’ll immediately get an indication of whether PoE is present.  The tool then proceeds on an up-the-OSI-layers network connection test.  First it’s physical connectivity to a switch.  Then it’s a DHCP check.  Then it pings the default gateway.  Finally it tries to reach the Internet.  Every step is confirmed (or not confirmed) by a simple green light.

When yours truly used LinkSprinter, the network was working.  That’s great, but it also meant that I didn’t really test the tool out.  The value in a troubleshooting tool isn’t to tell me that’s it’s working.  It’s to help me find out what’s going on when things aren’t working.

According to my contacts from Fluke Networks, the LinkSprinter records information that can help identify why a cable isn’t working.  PoE voltage levels, VLAN and default gateway information are all recorded by LinkSprinter.  the information can be accessed in one of two ways.  Both models of LinkSprinter — the “100” w/o WiFi and the “200” w/ WiFi — have their information automatically uploaded to a cloud service.  (I have yet to try the cloud service, but I know that it is accessed via and I know that my Fluke contact told me that it will be free for life.)  The WiFi model also turns into an access point to allow nearby devices to access the connection information via a web browser.  The WiFi model costs an extra hundred bucks ($300 instead of $200), but I would think that having a local GUI would be worth it.

Would the author buy a LinkSprinter?  My initial reaction was, “No”.  My thinking was, “I don’t install APs for a living, so I don’t need to test cables when installing APs”.  Then I thought about it some more.  I do sometimes deal with downed APs.  In the past that has always been Someone Else’s Job, but it would be nice to be able to stick a LinkSprinter on the end of that cable and see it there’s PoE.  Or if there’s an IP address.  And if I have a Link Sprinter 200 w/ WiFi, which IP address in which VLAN.  Because even when something is Someone Else’s Job, it’s still good to help them out.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Written by sniffwifi

October 14, 2014 at 12:56 am