I decided to show you how I use I/O graphs when analyzing Wi-Fi frame captures. Here is an example of low coverage as detected in an Emergency Department of a hospital.
This is the graphical representation of a trace I took of a device on a call to another device while roaming down the hall. Please note that this is all in percentages and not dBm, since I wanted to have all my data above zero to make pretty pictures. 😇
The black line across the top represents the upstream frames from the device that I made a call to. The reason the black line is at 100 percent is that badge is on my laptop as close to my adapters as I can get it and still see the screen; the signal is very strong at the adapters on its way to the access point.
The blue dots are the downstream frames (audio) that came from the DS to the device. the closer to the very top of the graph they are the stronger the signal from the access point and as you walk down the hall the signal drops until the device roams to a more suitable access point, where the dots should jump back up to the top of the graph and start all over again.
The green lines are probes (request and response) and the red lines are downstream re-tries. So the syntax to generate this data looks like this:
So let's break this down bit:
The blue dots start the trace with a decent signal and as I walk away from that access point towards another the dots slide down the graph. at 17 seconds-ish, the device picks up channel 149, so the dots did jump up, but not all the way to the top of the graph. This tells me the signal was better but not great. Right here is where you begin to ask 'why' and hold onto that for a minute. When I check the trace file I can see the time the device roamed:
Knowing what we now know and based on what's in the trace, the device stayed on channel 149 for a long time for a device walking quickly down the hallway. The trace shows it way past a signal I would have felt comfortable with this roaming to. Then when it finally does roam, the channel 48 access point is showing as bad of a signal is where the device roamed from. (Why?) The blue dots start to ascend up the graph because I am walking towards the access point. It peaks after a bit and begins to descend down where it finally picks up a very good signal on channel 40. It stays there for the remainder of the trace.
So there are now two 'why's' I need to answer: Why did the device roam to 149 with a marginal signal and why did it not let go for so long, only to find another bad signal?
My immediate thought is either low coverage or sticky roaming, so I need to figure out what the AP transmit power is and what the coverage looks like.
The settings in RRM are the default -10 to 30 dBm, which is too wide a berth to give to anything you want to work. However, this client is very security conscious and would not under any circumstances allow us to see the show advanced 802.11a summary output from the controller. Since I cannot investigate this path further, this will be a possible issue addressed in the assessment report. Without knowing what these three access points actually are set to, I have no idea if sticky roaming is a cause for this behavior, but I suspect it.
Then there is also this...
This is the primary access point coverage, there were no malfunctioning access points, just lousy coverage. Both of these issues are addressed in the report and since my job is to assess and not actually re-design and remediate, this is what was presented to the customer. It was explained that we could still make the go-live date on schedule if these issues could be remediated in time.
Comments
Post a Comment