ctdawe

Fair enough, but if I’m cursed with a set of bad options (which I’m assuming I am because I gather that testing leverages the existing Wi-Fi connection), I would personally be happier to get iPerf readings off the most powerful AP, rather than unknowingly continue to get my iPerf readings off a sticky AP that’s halfway across the facility because Apple’s software isn’t triggering an association to something with a better quality connection.

The issue is that it seems like all of the available choices have some significant downsides, but the issue of sticky client failing to roam to a more powerful AP is likely to give us bad results in iPerf testing. :-(

I’m duplicating this comment in to topics I created where it might be appropriate:

Thinking about this, it occurs to me that disabling and re-enabling Wi-Fi on the surveying Mac would probably cause it to re-associate using the best-performing AP, and would further cause the Mac to re-associate using the best-performing connection.

I would be interested in whether it might be possible to have an option in which NetSpot kills and then re-establishes the Wi-Fi in order to ensure that the Mac performing the survey is connected to the closest AP and connected at the best possible speed.

Note, this also does seem like an incredibly hackish way around this issue.

That would be relatively straightforward for a small network, but once you get into campus projects that have dozens of APs, that will become onerous, especially since the aliases are a bit arbitrary.

For instance, for a project in small development shop it would be easy enough to label things “Dev 2.4 GHz AP”, “Dev 5 GHz AP”, “Support 2.4 GHz AP”, and so on. However, once you get into a school with dozens of APs, you’d have to label a bit more arbitrarily “Room 205 5 GHz AP”, and the problem that would grow from that would be that as soon as you move something to another location, your alias needs to change in order to remain geographically accurate.

I suppose you could label the APs “001”, “002”, “003”, and so on, but as you point out above, the labor goes up quite a bit. Ultimately, I think it bypasses the issue a bit, as I was looking for an easy visual association of BSSID to map location without needing to switch back and forth between reading the AP list and looking at a legend that’s not on the map.

In general, yes, these would both be acceptable solutions. #1 is great for the printed final report and relating to information seen in the pop-up, while #2 is great for the actual understanding of the network via the project file.

Thanks!

Okay. Thanks!

So I’ve been intending to do a full rebuild of my machine as part of upgrading to Yosemite, and I finally did that over the weekend, with the following results:

1. A freshly-installed copy of NetSpot 2.4.585 running under 10.10.2 did not ask for access to the keychain on every sample point as I described above.

2. In addition, the behavior that I described above in which NetSpot displays the maximum transmit rate available on the network no longer occurs. In the test scan I performed today, the reporting shows variable transmit rates which I interpret to be the achievable data rate at each location.

I would be happy to share the .netspd file with you if you would like to examine it.

Okay, so I followed up with some testing at another site that I’ve walked through before. I downloaded and compiled iperf3 on an available testing machine running OS X 10.10.1 and assigned it a static IP address. When attempting to run a scan that includes iPerf testing, I notice a couple of things:

1. Every time NetSpot goes to start a performance test it asks for permission to ask the network (named by SSID) in the keychain. Even if I click “Always Allow”, NetSpot asks for every sample point. This is incredibly irritating.

2. After allowing access to the Keychain Item in question, NetSpot gives me an error that “iperf3 TCP upload speed test failed: $CompanySSIDName”. If I try again, it eventually stops erring out and continues.

The behavior described in 1&2 above occurs for every sample point.

It occurs to me that the test I described in an earlier post was done at a site with a RADIUS server that has an expired certificate. Notably, the behavior with Keychain never occurred at the other site, making me wonder if there’s some kind of authentication issue happening in NetSpot. Notably, at the first site described, running a vanilla iperf3 test from my machine worked just fine; it’s only in NetSpot that I’m getting kicked out.

Noted them in the release; thanks so much for that, and sorry for the delayed response.