I’ll start this post with two admissions:
1. Of late, I’ve been interested in the capabilities of 7Signal.
2. Long before 7Signal came to the WLAN space, I’ve been beating the drum for my WLAN vendor (and all vendors) to deliver what I call virtual client functionality.
On 7SIgnal, I’m struggling with sticker shock and trying to figure out where it’s very cool capabilities stop and where they overlap with tools like Cisco’s CleanAir (which isn’t cheap either). I am hearing good things about 7Signal from current customers.
About that virtual client thing, it is something 7Signal can do (along with a slew of other cool things). But by now, I also think this is one of those capabilities that should be built into enterprise WLAN systems. (If I’m not mistaken, Motorola comes closest to having something like this.)
Quick note to vendors- you give us one innovation after another that you think would benefit your clients. Thank you. But how about this one that is long overdue? Your customers that actually run the WLANs of the world would LOVE you for it.
Here are two versions of what I’m looking for:
Simple version:
- I can do all of this through my wireless management system
- I can schedule the function to run at regular intervals and report on it
- I choose one of my installed APs to put into “Virtual Client Mode”
- Through the wire, I can have my Virtual Client connect to each of my SSIDs and exercise the likes of RADIUS, Credential Stores, DHCP/DNS, L2 and L3 paths via ping, traceroute, etc, rate limiting, throughput tests, whatever
- All of this is coordinated in a way that doesn’t disrupt the existing client environment
Advanced Version:
- All of the above, PLUS
- I can manually choose any AP within a given range
- I can tell the virtual client to test itself against every AP it can hear within a certain range
You probably get the gist. The payoff- I can “be” in buildings or at sites that I don’t have to travel to. The Virtual Client would be a force multiplier, and in many situations would bring far more value than seeing pages upon pages of rogues and interfering signals from neighboring WLANs that I couldn’t react to if I wanted (hallmark of many current systems).
I can’t believe that I’m about to say this- I get tired of the sometime extreme feature licensing that has come to be all too common in the WLAN industry. But I’d actually pay (a fair price) for GOOD virtual client functionality.
Am I asking for too much? Are there WLAN vendors beyond 7Signal that are natively doing this that I don’t know of?
wirednot 
Meru Service Assurance Manager allows their APs to act as virtual clients to other APs. I didn’t dig too deep into it, so I don’t know whether it meets your advanced requirements.
100% right! its very important feature. I need to get the network status from the wireless side and not from the wired side. I use SheevaPlug with a bash script as a probe for wireless side of the network.
Yep- I have built a netbook “probe”, but you still have to deploy it, frog around with static routes, etc. much prefer built-in!
i agree. i just talked with our SW manager (i work for a small wiif vendor) about this issue because i know that many vendors use virtual client for their mesh capabilities. he raised the issue of limitation to only be able to work on the same channel the modem is currently working on(AP/VAP channel).
Not sure why that would be- if you put AP into client mode, then picked an AP to connect to (as I’m envisioning) then you would have some control. But let’s say that the virtual client joined whatever it chose- so be it. Better than nothing, but again, I’d want to test all SSIDs and key functions.
The biggest reason I think this wouldn’t be as effective as you might imagine is the same people who design the ‘client’ code are those that wrote the AP/controller code. So, you have the ‘client’ implementation done using the same assumptions (if not some of the same routines entirely) that the rest of the code base was written with. Isn’t this a best case scenario?
I would think a better implementation would be one where you could flip between client types. We have virtual machines, why not virtual clients?
Thanks for the note, Scott. Not sure I completely follow you, though. If I have my virtual client test 802.1x auth, association, and ability to reach target destinations, not sure how underlying controller code could skew that. But then again…
I guess what I’m trying to say is clients will test your network differently based on the assumptions they have written in their code on how to handle things like band steering/band select, load balancing, etc.
How one client responds when it is trying to be ‘steered’ towards one band could be very different from another (I know, I’ve seen it). Each client implementation has different assumptions written into their code based on how they interpreted the standard (right or wrong). It could be a simple as longer or shorter timeouts before it tries again, but that might affect how it bumps up against your controller timeouts.
Instead of testing the ‘perfect client’ for your network (perfect because it is written with the same assumptions as the controller software) wouldn’t you get more information based on how different client types respond?
Ah- now I get you, Scott. I fully agree with the likes of steering/load balancing influencing behavior. At the same time, I’m not trying to draw conclusions that all clients will be fine based on virtual client functionality, but am trying to exercise key paths on the WLAN as opposed to rolling a tech to do the same.