I've been tinkering with a couple of additions to the app this week. Many people use pings to test connectivity from mobile devices. As with most projects on Android, this comes with its tradeoffs...
- What to ping to? If we take the generic meaning of ping, rather than the specific function, we want to bounce a packet off something on the wired side of the AP (or even the AP itself) and see if we get a response within a reasonable time. It's good to have it at the IP layer, I think, so we need an IP address, and the easiest one to grab is the default gateway. I'm guessing this is usually a box that's not far from the mobility controller, and the controller is well-connected to the AP: because we want to get an idea of how good the WLAN is, not the wired network. And this default gateway IP address is easy to obtain from the Android Wi-Fi API, so you won't have to configure it separately.
- How to 'ping'? Being Android, there's no embedded ping function. I found three ways to do it.
i. InetAddress.isReachable(timeout) returns a boolean, success if a response was received before the timeout. This is a useful method because it won't hang if there's no response, but it reputedly doesn't actually use ICMP, rather it sends a TCP packet to the echo port 7. I haven't verified this with my sniffer yet. Also, I routinely get results that bounce around anywhere up to 100msec. Probably due to delays in the interior plumbing of Android rather than the very pristine Aruba WLAN I'm testing on, but I need to do some more investigation. By timestamping before and after the function I can get some idea of how long it took.
ii. Runtime.getRuntime().exec("ping -c 1 IPaddr") and iii. ProcessBuilder().command("/system/bin/ping"...) methods, which are probably identical if one digs deeper into Android. With these one can invoke a Linux ping function and I used the syntax to set up for single ping operation because that saves some concurrency and keeps the coding simple. Both methods work, but again the results fluctuate wildly in the 5 - 100msec range.
It was very difficult to compare the different methods for accuracy, but I coded them all up and picked the InetAddress.isReachable() option with timestamping for now.
- How often to ping? I'd like to be able to bound outages to a granularity of ~10msec. Can't get that accurate, but 500msec is achievable and it can probably be shaved down from there once the feature is tuned. Since many of the handover outages are multi-second (due to the client not looking for other APs very often and getting caught with its pants down when its signal drops), even 500msec gives some idea of what's going on.
- Now for how to display the information. Here are some screenshots:
The pings are represented by the green bar line near the top. Higher bars mean faster pings - is that counter-intuitive? Where a ping was transmitted but no ack received (failure in isReachable() terms) I print a hollow red rectangle. Where no ping was sent (the previous one took more than its 500msec or the Wifi interface lost its connection (I think that prevents me reading the default gateway address) there's nothing on the chart.
That's where we are today. I'm struggling with whether to present the round-trip time - the figures are all over the place and I'm quite sure it's not because of the Wi-Fi layer - or make it a boolean pass/fail.
What does the great Aruba public think?
Useful or not?
Better ways of displaying the information?
I'll be working on it next week.
The ping pass/fail is more than useful information, because most people cannot correlate when a ping fails to a roam or a ping failing due to weak signal strength today. You would just ping and you would try to be looking up when it fails to know where you are and what you were doing. The correlation between ping and signal strength is huge.
The round trip is less useful, because it probably is not accurate....
If I catch your drift, Colin, ping should be a go/no-go test? Just as well since I don't trust the figures. What about this, I made the 'success' mark a green filled square (rect) while when I send a ping and get no reply there's a red hollow square. Where I didn't send a ping there's nothing.
The figures below the graphic (isReachable, etc) are just my working version of the code, although I can put the ping time somewhere on the screen if it helps.
I still need to do some work to see if the gaps are too long, and also drop the ping into an AsyncTask so it doesn't block the UI thread but that's not difficult.
I was also going to adjust the number of histograms in the sequence to the size of the screen, so for instance if you put the phone on its side you will get maybe 2 minutes worth of history instead of 20 seconds. I've been lazy in not adding a different layout for tablets vs phones, there's certainly scope to put more information on the screen with the former - but that's for another day.
Thank you Colin for the advice,
No ping response is good as a hollow square unless it is to hard to read. If it is too hard, it can be a solid red square.
Are the pings one per second like every other OS?
Histogram adjustment = Good
I'll ditto Colin, the visual correlation of ping (pass/fail) with the signal-strength histogram is an excellent idea.
me an msabin agree.. Excellent!
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.