possible improvements in the interface side:
-> TROUBLESHOOT-> UNCONNECTED CLIENTS-> Timestamps do not show the date (just hour of the day). would be nice to show attempted connections / disconnections in a "log"
fashion, with number of "hits", counters, and/or scrolling
upwards in chronological order.
Ability to assign an "alias" to a given mac would come in handy, as in xx:xx:xx:yy:zz:ab <JOHN'S WIFI THINGY>
that could help pinpointing why something important is not working in events/ high density environments, where
one could have a mix of visitor's laptpos and local/event infrastructure equipment in the same AP
I.E:
MAC<32 character "comment"> || VENDOR || ATTEMPTED SSID || LAST SEEN [DAY/HOUR/MINUTE] || MESSAGE || "Hit count"?||
->> Dashboard --> Wireless Clients:
Possibly have a split box for 2.4 and 5.8 radios? If we have them on the same SSID there is no way to separate who's in 5.8 and who's in 2.4
plus, i understand that i could have up to 256 stations in each radio(aggregate of all SSID's in that radio), so it seems reasonable to break them per band.
--> Wireless Clients:
Cnmaestro already shows RSSI per station along with SNR and band, would like to see those in the local UI too.
Altough i tend to prefer a split box presentation,
just having the band field is already better than nothing.
-->Split RX/TX data rates?
--> Show "alias" for devices?
--> Feature: Per band ACL *\\ kick them from 2.4 until they submiss to the 5.8 dictatorship\\.
Say that i know that Joe visitor's I-thing is both 2.4 and 5.8 band capable, but being an Ithing it does'nt like to be told what band to connect to.
I would like to be able to kick joe visitor from the congested 2.4 radio, until his Ithing decides it's time to steer to the 5.8 radio.
> At least a KICK button, preferably a KICK and a BAN button for each MAC per band (ban joe's Ithing from 2.4 but not 5.8?)
--> Dashboard
Display total memory and percentage, instead of just relative metric. IE: 65%/128M instead of just 65%
[after all we have 64 and 128M varieties as of now, and that could change in the future.]
--> Dashboard --> Cpu Usage:
Have an option to "top" the device and display what's eating up CPU cycles (not daemonized, just measure in a per request basis)
As in: is it the firewall, the NAT, conntrack, queueing of packets(traffic shaper per client),routing... that's the bottleneck/misconfigured.
--> Clarification: Whats the polling interval(are those values gathered at 12:34 hours in absolute values, or the mean value in the last 5 minutes?) of the troughput/connected
dashboard graphs?
How granular can those get? (1 minute intervals? ) real time troughput graphing/displaying is practical to implement?
-->DNS: Cache ttl and cache "clean" are interesting options to have buttons for.
This way no reboot is required if suspected dns issues arise.
--> Troubleshoot --> WiFi Analyser:
Ability to run a longer [30 second-ish] scan would be nice.
any way to display a metric of channel occupation? (can be somewhat poorly infered by noise floor; usage based in decoded/detected packets would be best/desired).
Can the RSSI values get a column in the table?
Clarification: ->>
I've seen values of -110 to 0 in the debug logs(unrelated to the tool, driver spitting mesages, like:
my laptop in 2.4ghz 14:22:42.083: client-stats msg len272 on vap=0 for 24-F5-AA-62-F1-92 (stats.c:208)
interface 14:22:42.084: snr 41 nf -109 rssi -68 rate 72109 (stats.c:233)
My cellphone, in 5.8 14:35:42.514: client-stats msg len272 on vap=1 for 24-C6-96-8D-AE-5F (stats.c:208)
interface 14:35:42.514: snr 36 nf 0 rssi -59 rate 0 (stats.c:233)
)
Nf calculation for the 5.8ghz interface appears to have some interesting math going on.
Nf calculation for the 2.4ghs has sound mathematics, but a somewhat unrealistic noise floor for the 2.4ghz band.
i believe that the 41db snr value (if the displayed value in the UI comes from this driver, that is)
can be a bit misleading, especially since we have a RSSI based KICK mechanism in the "Enhanced Roaming" settings.
with the driver considering a noise floor of -110, the parameter would only start to make any difference if set to >~16db.
for a RSSI of arround -94. 20db would kick-me at -90, but 20db sounds to me like a high SNR value.
the 5.8 radio gives me a floor of -95(-59-36), 6db snr would kick me at -89. that's the parameter i have set today(both radios), but haven't had an opportunity
to test the feature. (Too many walls here).
Anyway, some further explanation of the feature in the user guide is welcome!
RSSI based kicking of stations, in my opinion, is a more straightforward way of doing it.
RSSI can be infered from distance, antennas and other known or more "palpable factors"
SNR is one step further in the "RF-Voodoo" direction.
"Combined" RSSI or SNR lower than "kickRSSI","kickSNR" is practical?
===============================================================================================================================================
A bit of my feelings about diagnostics and troubleshooting tools:
IPtraf is a very very nice tool to help customers in distress.
We (usually) don't care that the fault is in their side. Being able to
open a tcp "connections active" screen and pinpoint "you have a windows update going on" is priceless.
We don't sell layer3 connectivity to customers, we sell layer "8" value-added "customer's <app here> works and the customer is happy"
meaning, we need a way to point the customer in the right direction analysing our side of the connection.
this gets us in a position where we almost by definition have to have a mikrotik or linux box in between the customer ant the internet.
Iptraf in cnPilot gear, and for that matter, Epmp CPE's, would allow us to pretty much erradicate the need for a separate "diagnostic box" in the topology.
===============================================================================================================================================
My best regards, and congrats for yet another awesome product, full of features, and the always great support!!
Guilherme Poletto.
1 Like
One other important thing that i forgot to mention, would be to strip-out with the clear text passwords in the debug log.
It appears to me that those logs survive reboots.
Having a way to erase all logs if needed is important, but not having clear text passwords in them is absolutelly necessary.
Since i cannot properly format the text up there, i'll attach the .txt for easier reading, if desired.
- E400_2cents.zip (3.17 KB)
thanks for the great feedback, we'll discuss and work through all the topics you have mentioned here. Some quick updates:
- yes, the counters for hits would indeed be useful, we'll add that. We'll also look to convert the timestmap from 'how long ago' to 'exactly when date/time' (probably in the GUI, keeping backend as seconds so we dont move the numbers aroudn when the AP syncs time with NTP etc)
- the next release will be adding a column for radio-type which would show the band the client has connected on. Note that the 256 client limit is aggregate on the AP.
- per band ACL -- we'll add this to roadmap (instead of tying ACLs to just WLAN, allow mac-acl to be tied to radio). Note that for the use-case of forcing dual band clients to 5GHz instead of 2.4GHz the upcoming 2.0 release has a band-steering feature where the AP will automatically force the connection of a client capable of both bands, to the 5GHz radio. Its more a push/suggestion though, unlike an ACL which will simply not allow it to connect to 2.4GHz in any case.
Another option if you want to be really strict about this is to define two WLANs, map one to 2,4GHz the other to 5GHz, and have Joe's I-Device configured only for the 5GHz SSID (ok for small deployments where you control client devices, band-steering from release 2.0 is the more flexible solution for this)
- CPU usage of all processes is available in the CLI today, is not in the device GUI. "Service show top" in the CLI displays all processes, their CPU and memory utilizations.
- we'll look at more granular than 5min updates, for now we take snapshots of stats every 5 minutes. A semi real-time dashboard is coming from release 2.0: we are adding an opton for periodic 'auto-refresh' of the dashboard.
- good point on flushing DNS cache through a button, will add that to the roadmap
we'll investigate the wifi-analyzer and stats values.
2 Likes
@Guilherme wrote:--> Troubleshoot --> WiFi Analyser:Ability to run a longer [30 second-ish] scan would be nice. any way to display a metric of channel occupation? (can be somewhat poorly infered by noise floor; usage based in decoded/detected packets would be best/desired). Can the RSSI values get a column in the table?</pre><hr>Thanks for your suggestions...</blockquote><blockquote>Currently we rely on the OS and driver to perform the scan and do not have much control over it. Controlling the duration of the scan and channel occupation are not something that we can provide currently. In the future with our custom scan, we will try to incorporate these suggestions.</blockquote><blockquote>Yes, we are currently adding RSSI and Noise columns to the table as requested. Will keep you updated as soon as the release with the new data is out.</blockquote><blockquote>Regards,<br>Deepak</blockquote>
2 Likes