So this guys, is why we are often resistant to contributions.
Had I committed this stuff, it would now be a load of abandoned code and database tables.
re: this patch, we won't accept any vendor-specific database tables or ui code. Database structure and UI code must be generic, with vendor specific poller code passing data to generic code dealing with the database. This is the only way to keep it sane.
We're kinda in the process of working out how the wireless stuff should be presented, so it's all quite a lot of mess. It's probably wifi-sessions that you want, it might need expanding to fit in the new data though.
adam.
On 2014-05-31 15:57, Steve Evans wrote:
So, I've ditched my Apple Airport base-stations and I'm now using Cisco Aironet AIR-AP1252AG-E-K9 access points which are in a different league.
See below a patch to 0.14.4.5229 to add graphic of signal strength/quality for all connected clients. This no longer needs the dodgy MAC/IP lookup table in SQL that you objected to as the Cisco kit has much better SNMP support (the association MIB to be specific).
A table needs to be created in MySQL thus before applying this patch.
create table aironet_clients (device_id SMALLINT, client_ip VARCHAR(18), active CHAR, signal_db SMALLINT, quality_db SMALLINT, radio SMALLINT, ssid VARCHAR(32));
Enjoy,
Steve
On 28 Mar 2014, at 18:35, Steve Evans Steve@SCEvans.com wrote:
Hi Adam,
It's not actually pfsense specific; it just so happens that I use pfsense as my DHCP server. Same issue exists whatever provides the DHCP service; how can you map remote MAC addresses to meaningful hostnames?
I think it would be useful to at least leave some hook in the code which can either resolve the MAC address or not; that would accommodate the needs of both me and the other person on the planet, and the rest of you get to look at MAC addresses. :)
Thanks,
Steve
On 20 Mar 2014, at 01:20, Adam Armstrong adama@memetic.org wrote:
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] [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 [1] [1] _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1] [1] _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [1] Links:
[1] 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 [1]
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