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
_______________________________________________
observium mailing list
observium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium