Hi Steve,
There's less than zero chance of us committing that weird DHCP-derived MAC>IP>Host lookup stuff. It's useful to maybe 2 people on the planet who have pfsense and airports, and is a massive pain in the arse to maintain.
The rest is probably fine.
adam.
On 2014-03-19 15:34, Steve Evans wrote:
See attached diff against release 0.13.10.4585 which adds a WiFi Clients entry under the devices tab and augments Apple AirPort device "Overview" tabs with a list of clients. Currently connected clients are highlighted green, others grey. Clicking on the "WiFi Clients" header will display graphs of signal strength, noise and speed for all clients connected to that base-station. Clicking on a client will display graphs for connections to all base stations that client has connected to. MAC addresses are used to identify clients unless the mac_ip_host table is populated as shown below. There's no sensible way to gather this data as the base-station could be anywhere, so ARP won't help.
Note that the following tables must be created for this to work.
create table airport_clients (device_id SMALLINT, client_mac VARCHAR(18), active CHAR, signal_db SMALLINT, noise_db SMALLINT, speed SMALLINT);
To create a mac lookup database exported from pfsense DHCP status create a table
create table mac_ip_host (mac VARCHAR(18), ip VARCHAR(16), hostname VARCHAR(255));
Import the data
GRANT FILE ON *.* TO 'observium'@'localhost' IDENTIFIED BY PASSWORD 'xxx'; LOAD DATA INFILE '/tmp/macs.csv' INTO TABLE mac_ip_host FIELDS TERMINATED BY ',';
I tried to upload a post containing explanatory screenshots, but that got bounced, so if anybody is interested, please let me know.
Steve
On 6 Mar 2014, at 21:39, Steve Evans Steve@SCEvans.com wrote:
Pretty simple really.
Poll the airport base stations in includes/polling/wifi.inc.php and create RRD files for each base station named wificlient-xx_xx_xx_xx_xx_xx.rrd containing Signal/Noise/Speed info.
Modify html/pages/device/graphs.inc.php to, when iterating through the $graph_enable array, detect a $graph of 'wifi_client'. Then to iterate over each rrd file under rrd/'hostname' with a prefix of wificlient- passing the $rrd_client MAC address in the $graph_array array. The corresponding html/includes/graphs/device/wifi_client.inc.php file then plots the RRD file.
Voila.
Now, the bit that whiffs a bit is the interation over the file names. Much neater would be an SQL query to get a list of all Airport RRD files associated with a given basestation, and then, the clever bit, to also be able to use another query to get a list of all Airport basestations with which a given client MAC address has been associated so that roaming behaviour can be observed. Replacing MAC addresses with hostnames would, of course, aid usability.
Steve
On 6 Mar 2014, at 08:00, Tom Laermans tom.laermans@powersource.cx wrote: The current very simple "wifi client count" was/is also under graphs/wireless, which is probably why it's there in Steve's patch. :-)
On 06/03/2014 03:50, Adam Armstrong wrote:
Depends upon how it's done, probably not with the stuff being dropped into "graphs", but if it's written in a sensible fashion I can probably move it to a better place.
adam.
On 2014-03-05 19:57, Steve Evans wrote: Some hacking later, I have each of my airport base stations reporting the WiFi stats seen by their clients thus:
Is this of interest for the greater good?
Steve
On 23 Feb 2014, at 22:46, Steve Evans Steve@SCEvans.com wrote:
Tracking roaming could be very useful for understanding where wifi access points are needed. Much of the power in data is the associations between it. Several years ago I authored the SUN-PLATFORM-MIB as an extension to the ENTITY-MIB. That was all about associations.
Steve
On 23 Feb 2014, at 21:55, Adam Armstrong adama@memetic.org wrote:
On 2014-02-23 14:50, Steve Evans wrote: One challenge, if graphing the wirelessClientsTable, would be the fact that as the clients came and went their corresponding entries in the tables would come and go. There would therefore be gaps in the recording of packets associated with these nodes. That's a fairly simple concept, but how would you manage roaming whereby a client hops between base stations? Would you try to tie these together so that a trace of traffic associated with such a client, irrespective of base station would be available? I think that decision might shape any framework; ie would it be base station or client centric? Of course more than one view may be desirable.
And you see why no one has written any software to do this before...
I try to stay away from recording any history for transient things, we'll store a count and sometimes a snapshot of the state, but more than that usually not.
Though, it depends how useful it would be in the end. We do store history for MAC accounting, and this is vaguely similar.
adam. _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1]
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
Links:
[1] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium