Recently, myself and a few others were tasked with attempting to figure out how to capture 6GHz traffic in much the same way traffic is captured currently, by utilizing 8 Netgear AC1200 adapters with the monitor mode drivers and a copy of OmniPeek. This allows for capturing the voice device frames over the air to see how the device is performing on the wireless network. Beacons, control frames, upstream and downstream traffic, etc.
The only solution so far is the Ekahau Sidekick 2, which allows for four 20 MHz channels to be captured. I'm still working out how best to position the device and the Sidekick 2, because my testing environment is extremely limited. Once I get an environment suitable for testing, I will post about how that goes and what pitfalls await.
Meanwhile, the Ekahau uses the raw radio tap headers to determine RSSI values, and OmniPeek has an algorithm that generates values in percentages to create an easy to read I/O graph without needing to know anything about dBm. Since I was taught to do the captures using OmniPeek, these are the graphs we have always presented to clients to explain what was discovered in the traces.
Example of Trace Using OmniPeek Shown in Percentage
This is an I/O graph I am used to seeing that shows the upstream frames in the black line across the top. The reason the percentage is so high is that the adapters are so close to the device, this is essentially establishing a background. The blue dots are all the downstream frames, the red lines are upstream retries, and the green lines are probes. The downstream frame blue dots start at the top of the graph because when the trace started the device had a very good signal and as the device roams away from the access point, the signal degrades to a point where the device probes and looks for a more suitable access point. At about 22 seconds, the device roams to another access point, and the blue dots jump up a little bit (but not to the top of the graph - more on that later). The process continues through the trace and each time the device roams to a good signal, the blue dots jump back up. This is all well and good and makes for a pretty graph to explain the trace. The first roam that didn't jump all the way up to a high percentage of signal strength is indicative of either low coverage or roaming into access points mounted in a hallway with nothing to attenuate the signal. Since this area did not lack coverage, the device ended up roaming well after it encountered the target access point and had walked past it before it connected. When it did connect, the signal was weaker than if it was right on top of the device. Notice the retries as well when the device has nothing to roam into - again, looks like low coverage, except it has plenty of coverage.
Anyway, now look at this:
I have been studying the Rockstar Wifi Wireshark profile from Rasika
I am spending my downtime trying to figure out all the filter buttons he has included and wondering how much of this I can and should be using that I might currently not be...
Comments
Post a Comment