:3000 (login admin/admin, changed on first login)
135 |
136 | In web GUI, add datasource: Configuration > Datasources
137 |
138 | - Type: InfluxDB
139 | - Name: WiperfDB
140 | - URL: http://127.0.0.1:8086
141 | - Access: Server
142 | - Database: wiperf
143 | - User: grafana
144 | - Password: R34dth3DB
145 | - HTTP Method: GET
146 |
147 | 13.Obtain the Grafana dashboard files from the wiperf dashboards folder and place on your browser machine (/usr/share/wiperf/dashboards)
148 |
149 | Using the web GUI, import dashboards using these menu options:
150 |
151 | "+" > Create > Import > Upload .json file > select dashboard file
152 |
153 | Select folder (General by default)
154 | Select WiperfDB
155 |
156 | Repeat for each dashboard required.
157 |
158 | At this point, you should be good to go! Verify the status of polling using the usual wiperf log file (runs every 5 minutes):
159 |
160 | ```
161 | tail -f /var/log/wiperf_agent.log
162 | ```
--------------------------------------------------------------------------------
/mkdocs/docs/adv_secure.md:
--------------------------------------------------------------------------------
1 | Title: Security Hardening
2 | Authors: Nigel Bowden
3 |
4 | # Security Hardening
5 |
6 | ### WLAN Pi
7 | Wiperf employs the following security mechanisms in an attempt to harden the WLAN Pi when deployed in wiperf mode:
8 |
9 | - No forwarding is allowed between interfaces
10 | - The internal UFW firewall is configured to only allow incoming connectivity on port 22 on the wlan0 & eth0 interfaces
11 |
12 |
13 | ### RPi
14 | If you'd like to harden the RPi when deployed in a network, a quick solution is to install & activate the 'ufw' firewall. This can be configured to stop all incoming connections except those on SSH, which will still allow remote administration. All outgoing traffic from the probe (i.e. network tests and management traffic) will flow as normal.
15 |
16 | #### Install ufw
17 |
18 | ```
19 | apt-get update
20 | apt-get install ufw
21 | ```
22 |
23 | #### Add Firewall Rules
24 |
25 | ```
26 | ufw allow in on eth0 to any port ssh
27 | ufw deny in on eth0
28 | ufw allow in on wlan0 to any port ssh
29 | ufw deny in on wlan0
30 | ```
31 |
32 | #### Activate Firewall
33 | ```
34 | ufw enable
35 | ```
36 |
37 | #### Useful Commands
38 |
39 | ```
40 | # Disable the firewall comletely
41 | ufw enable
42 |
43 | # List fw rules with numbers
44 | ufw status numbered
45 |
46 | # See firewall status
47 | ufw status
48 | ```
49 |
--------------------------------------------------------------------------------
/mkdocs/docs/blog_neo3.md:
--------------------------------------------------------------------------------
1 | Title: Using the Neo3 as a wiperf Probe
2 | Authors: Nigel Bowden
3 |
4 | # Using the Neo3 as a wiperf Probe
5 |
6 | *28th January 2021 - Author: Nigel Bowden*
7 |
8 | Although I tend to recommend running wiperf on either a WLAN Pi or A Raspberry Pi, there is no reason you can't try running it up on other Linux-based small board computers.
9 |
10 | One of my favourite SBCs is the [Neo3 from Friendly Elec](https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=279){target=_blank}. It's a very compact, high performance unit. The only downside it has is that it does not have a wireless NIC if you wish to test over wireless. To fix this, you can use a Comfast CF-912AC USB adapter, which will give you a reasonably good 802.11ac, 2 stream connection.
11 |
12 | In this article, I'll run through the basic build process to get you going with wiperf using a Neo3 kit. To perform this build, you'll need:
13 |
14 | - [NanoPi Neo3-LTS](https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=279) (Select combo with case when purchasing)
15 | - A 16Gb or better Micro SD card
16 | - A [CF-912AC USB wireless NIC](https://www.amazon.com/Comfast-CF-912AC-1200MBPS-Realtek-Network/dp/B01KX1M436/){target=_blank} (checkout eBay & Aliexpress for other sources)
17 | - Some kind of power source. The Neo3 needs a Type-C power connection (I use a phone charger with a USB-A to Type-C cable - the power requirements are quite low)
18 | - A USB to micro-SD adapter to burn the image (for example: [an adapter like this](https://www.amazon.com/Vanja-Adapter-Portable-Memory-Reader/dp/B00W02VHM6){target=_blank}
19 | - A copy of [balenaEtcher](https://www.balena.io/etcher/){target_blank} (free) to burn the image on to your SD card
20 |
21 | 
22 |
23 | Here are the steps I followed to build wiperf on Neo3:
24 |
25 | 1. Go to the image download page for the Neo3 on the Armbian site:
26 |
27 | [https://www.armbian.com/nanopineo3/](https://www.armbian.com/nanopineo3/){target=_blank}
28 |
29 | 2. Select the "Armbian Buster" direct download link.
30 |
31 | 3. Put the micro-SD card in to your SD to USB adapter and plug it in to your computer, ready to burn an image. Burn the image on to the micro-SD card using balenaEtcher (https://www.balena.io/etcher/){target=_blank}. This takes a few minutes to complete.
32 |
33 | 4. Once the image is burned on to the micro-SD card, put the micro-SD card in to the slot on the back of the Neo3, plug in your wireless USB NIC and power up the Neo3.
34 |
35 | 5. Plug the Neo3 in to a switch Ethernet port so that it can get an IP address (You will likely need to look on your DHCP server or switch MAC/ARP table to figure out the IP address assigned(). The default hostname you may see listed on your DHCP server client list is `nanopineo3`. The Ethernet port used will also need Internet access to allow package downloads.
36 |
37 | 6. Once you have the IP address of the Neo3, SSH to it and login with the following credentials:
38 | ```
39 | username: root
40 | password: 1234
41 | ```
42 |
43 | 7. During this initial login, you will be prompted to provide:
44 | a. New root password to replace the default (don't forget this once you set it!)
45 | b. Configure your locale
46 | c. Choose a default shell (go with bash)
47 | c. Create an "every day" user account that should be used to administer the probe. Suggested settings:
48 |
49 | username: wiperf
50 | password: [select your own]
51 | real name: wiperf user
52 |
53 | 8. Drop the SSH session and establish a new session using the new "every day" account username (wiperf).
54 |
55 | 9. The NetworkManager package can be very problematic for networking, so we need to disable it. Follow these steps to disable it and create a static configuration file for eth0:
56 |
57 | a. Create a static config file to ensure eth0 gets an IP address from DHCP (you will be prompted to enter your everyday user password again)
58 |
59 | ```
60 | sudo sh -c "printf '\n\nallow-hotplug eth0 \nauto eth0\niface eth0 inet dhcp\n' >> /etc/network/interfaces"
61 | ```
62 |
63 | b. Disable NetworkManager
64 |
65 | Disable the NetworkManager process and prevent it from staring at boot-up:
66 |
67 | ```
68 | sudo systemctl stop NetworkManager
69 | sudo systemctl disable NetworkManager
70 | ```
71 |
72 | c. By default, traditional interface names are not used for wireless NICs....lets fix that. Add this command:
73 |
74 | ```
75 | # Comment: add update to use traditional interface names (e.g. wlan0)
76 | sudo sh -c "echo 'extraargs=net.ifnames=0' >> /boot/armbianEnv.txt"
77 | ```
78 |
79 | d. Reboot:
80 |
81 | ```
82 | sudo reboot
83 | ```
84 |
85 | Log back in to the Neo3 over an SSH session once it has come back up (may take a couple of minutes)
86 |
87 | 10. Perform an update of all packages before adding any new software, followed by a reboot of the probe by entering these commands:
88 | ```
89 | # Comment: the update may take a few minutes to complete...go get a coffee
90 | sudo apt-get update && sudo apt-get -y upgrade
91 | sudo sync; sudo reboot
92 | ```
93 |
94 | Log back in to the Neo3 over an SSH session once it has come back up (may take a couple of minutes)
95 |
96 | 11. Add a couple of package that we need to install python modules (these may already exist):
97 |
98 | ```
99 | sudo apt install python3-pip
100 | sudo pip3 install setuptools wheel
101 | ```
102 |
103 | 12. At this stage, the Neo3 is prepared ready for the installation of required packages and scripts. To complete the installation and configuration of wiperf, follow the instructions provided for the Raspberry Pi installation starting on this page:
104 |
105 | [Raspberry Pi Hostname Configuration](https://wifinigel.github.io/wiperf/probe_prepare/#hostname-configuration_1) (Note that the default hostname for the Neo3 is `nanopineo3`, rather than `raspberrypi` that is specified in the RPi instructions)
106 |
107 | Once you have completed the wiperf installation, you may use it in the same manner as the instructions provided for the Raspberry Pi on the wiperf web site. Have fun!
108 |
--------------------------------------------------------------------------------
/mkdocs/docs/data_points.md:
--------------------------------------------------------------------------------
1 | # Data Points Reference Guide
2 |
3 | ## Background
4 |
5 | The wiperf probe collects a variety of data points about various aspects of network connectivity and performance. It then makes those data points available to a number of databases via their standard API (e.g. Splunk, InfluxDB etc.).
6 |
7 | The data collected in all instances is the same, but the format of the data presented to each type of database varies depending on the their API and formatting rules and syntax.
8 |
9 | This document details the data points collected by the probe. These field names and the data values should be the same no matter which database is used.
10 |
11 | The probe may collect data for the following network tests, depending upon its configuration:
12 |
13 | - [Wireless network connectivity details](#wireless-network-connectivity)
14 | - [Speedtest testing results data](#speedtest-results)
15 | - [ICMP ping tests to various destinations](#ping-results)
16 | - [DNS lookup tests to various destinations](#dns-results)]
17 | - [HTTP (web) tests to various destinations](#http-results)
18 | - [iperf3 TCP test to a nominated iperf3 server](#iperf3-tcp-results)
19 | - [iperf3 UDP test to a nominated iperf3 server](#iperf3-udp-results)
20 | - [DHCP renewal test to test DHCP performance on network to which the WLAN Pi is connected](#dhcp-test-results)
21 | - [SMB/CIFS file copy tests from various desinations](#smb-results)
22 | - [Poller Errors](#poller-errors)
23 | - [Poll Status Information](#poll-status-info)
24 |
25 | The tests are run each time the wiperf process is triggered (usually every 5 minutes from a local cron job). The tests that are run, together with test configuration parameters are configured in the config.ini file.
26 |
27 | Here are the data points that may be collected, displayed by test type:
28 |
29 | ## Data Points Details
30 |
31 |
32 | ### Wireless Network Connectivity
33 |
34 | **(Data source: wiperf-network)**
35 |
36 | * time : Unix timestamp of time test was performed
37 | * ssid : The network name of the wireless network to which the wiperf probe is currently connected
38 | * bssid : The basic service set identifier (i.e. MAC address) of the radio to which the wiperf probe is currently connected
39 | * freq_ghz : The centre frequency of the channel on which the probe is operating (note this may be different to the primary channel centre freq if a bonded channel is in use)
40 | * center_freq_ghz : The centre frequency of the primary channel on which the probe is operating
41 | * channel : The channel number on which the probe is operating
42 | * channel_width: The channel width (e.g. 20MHz, 40MHz, 80MHz) of the channel on which the probe is operating
43 | * tx_rate_mbps : The PHY rate at which data is being sent from the probe to the AP (note this is not a throughput rate, just a physical connection rate)
44 | * rx_rate_mbps : The PHY rate at which data is being sent from the AP to the probe (note this is not a throughput rate, just a physical connection rate)
45 | * tx_mcs : For HT & VHT connections, this is the the MCS value used by the probe to the AP
46 | * rx_mcs : For HT & VHT connections, this is the the MCS value used by the AP to the probe
47 | * signal_level_dbm : The power level of the AP radio signal as observed by the probe (in dBm)
48 | * tx_retries : The number of transmitted frames that have had to be sent gain (retried)
49 | * ip_address : The IP address assigned to the probe WLAN NIC
50 |
51 | ### Speedtest Results
52 |
53 | **(Data source: wiperf-speedtest)**
54 |
55 | * time : Unix timestamp of time test was performed
56 | * ping_time : The RTT of a ping test to the speedtest server
57 | * download_rate_mbps : The throughput rate achieved when receiving data from the speedtest server in megabits per second
58 | * upload_rate_mbps : The throughput rate achieved when sending data to the speedtest server in megabits per second
59 | * server_name : The name of the speedtest server used for this test
60 |
61 | ### Ping Results
62 |
63 | **(Data source: wiperf-ping)**
64 |
65 | * time : Unix timestamp of time test was performed
66 | * ping_index : wiperf runs up to 5 instances of ping test via its configuration file. This index uniquely identifies each instance.
67 | * ping_host : The IP address or hostname of the target host/site being pinged
68 | * pkts_tx : The number of ping request packets sent during the ping test
69 | * pkts_rx : The number of ping response packets received back during the ping test
70 | * percent_loss : The percentage (%) of packets lost during the test (i.e. how many responses were received compared to requests sent)
71 | * test_time_ms : How long the ping test took in total
72 | * rtt_min_ms : The minimum round trip time of all ping tests to this test instance in milliseconds
73 | * rtt_avg_ms : The average round trip time of all ping tests to this test instance in milliseconds
74 | * rtt_max_ms : The maximum round trip time of all ping tests to this test instance in milliseconds
75 | * rtt_mdev_ms : Standard deviation of all ping tests to this test instance (...no, I don't know either...but you'll look cool at dinner parties if you mention it.)
76 |
77 | ### DNS Results
78 |
79 | **(Data source: wiperf-ping)**
80 |
81 | * time : Unix timestamp of time test was performed
82 | * dns_index : wiperf runs up to 5 instances of DNS test via its configuration file. This index uniquely identifies each instance.
83 | * dns_target : The domain name of the target host/site which is the subject of the DNS lookup test
84 | * lookup_time_ms : The time taken to perform the DNS lookup in milliseconds
85 |
86 | ### HTTP Results
87 |
88 | **(Data source: wiperf-http)**
89 |
90 | * time : Unix timestamp of time test was performed
91 | * http_index : wiperf runs up to 5 instances of HTTP test via its configuration file. This index uniquely identifies each instance.
92 | * http_target : The domain name (or IP address) of the target site which is the subject of the HTTP test
93 | * http_get_time_ms : The time taken (in mS) to retrieve the html page from the target site in milliseconds
94 | * http_server_response_time_ms: The time taken (in mS) to receive the response headers from the target site. This is a more useful figure in many instances, as it does not include the page load time to is more indicative of the web server RTT.
95 | * http_status_code : The HTTP status code returned from the target site in this test instance (200 is good, other values have varying meanings: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes )
96 |
97 | ### iperf3 TCP Results
98 |
99 | **(Data source: wiperf-iperf3-tcp)**
100 |
101 | * time : Unix timestamp of time test was performed
102 | * sent_mbps : The transmit throughput achieved (in megabits per seconds) during the TCP iperf test
103 | * received_mbps : The receive throughput achieved (in megabits per seconds) during the TCP iperf test
104 | * sent_bytes : The number of bytes (i.e. data volume) sent from the probe to the iperf server during the test
105 | * received_bytes : The number of bytes (i.e. data volume) received by the probe from the iperf server during the test
106 | * retransmits : The number of times frames had to be re=transmitted during the test
107 |
108 | ### iperf3 UDP Results
109 |
110 | **(Data source: wiperf-iperf3-udp)**
111 |
112 | * time : Unix timestamp of time test was performed
113 | * bytes : The number of bytes transferred from the probe to the iperf server during the test
114 | * mbps : The throughput achieved (in megabits per second) during the iperf test when sending data to the iperf server
115 | * jitter_ms : The level of jitter measured (in milliseconds) during the test
116 | * packets : The number of packets sent from the probe to the iperf server during the test
117 | * lost_packets : The number of transmitted packets lost during the test
118 | * lost_percent : The percentage of transmitted packets lost during the test
119 |
120 | ### DHCP Test Results
121 |
122 | **(Data source: wiperf-dhcp)**
123 |
124 | * time : Unix timestamp of time test was performed
125 | * renewal_time_ms : The time taken for the probe to renew it's IP address in milliseconds
126 |
127 | ### SMB Results
128 |
129 | **(Data source: wiperf-smb)**
130 |
131 | * time : Unix timestamp of time test was performed
132 | * smb_index: test index number
133 | * smb_host: name/IP of host under test
134 | * filename: name of file being copied during the test
135 | * smb_time: the file transfer time in mS
136 | * smb_rate: the file transfer rate in Mbps
137 |
138 | ### Poller Errors
139 |
140 | **(Data source: wiperf-poll-errors)**
141 |
142 | * time : Unix timestamp of time test was performed
143 | * error_message: text string containing error message
144 |
145 | ### Poll Status Info
146 |
147 | **(Data source: wiperf-poll-status)**
148 |
149 | * time : Unix timestamp of time test was performed
150 | * network: text string indicating if network connection up OK
151 | * ip: IP address being used by probe network connection
152 | * speedtest: text string indicating if test completed/failed/disabled
153 | * ping: text string indicating if test completed/failed/disabled
154 | * dns: text string indicating if test completed/failed/disabled
155 | * http: text string indicating if test completed/failed/disabled
156 | * iperf_tcp: text string indicating if test completed/failed/disabled
157 | * iperf_udp: text string indicating if test completed/failed/disabled
158 | * dhcp: text string indicating if test completed/failed/disabled
159 | * smb: text string indicating if test completed/failed/disabled
160 | * probe_mode: string indicating if probe in wireless or ethernet mode
161 | * mgt_if: name of management interface (e.g. eth0, wlan0)
162 | * run_time: time is secs that poll cycle took to run
163 |
164 |
165 |
166 |
167 |
--------------------------------------------------------------------------------
/mkdocs/docs/db_health.md:
--------------------------------------------------------------------------------
1 | Title: Probe Health
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - Probe Health
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_http.md:
--------------------------------------------------------------------------------
1 | Title: HTTP
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - HTTP
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_probe_summary.md:
--------------------------------------------------------------------------------
1 | Title: Probe Summary
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - 01 - Probe Summary
5 |
6 | ## Overview
7 | The probe summary report attempts to provide a high level view of the tests that are run by the probe. By providing summary data in one place, it allows view of correlation between any factors that may be causing performance issues.
8 |
9 | For instance, if HTTP tests are showing a drop in response times, by looking at other test results, it is possible to see if this issue is limited to just HTTP traffic or maybe other network conditions are the root cause of the issue. If a low physical connection rate on the wireless connection is also observed, the the issue is more likely to be related to a wireless connection issue than a connectivity elsewhere on the network, such as an overloaded Internet WAN link.
10 |
11 | By observing the results of all tests, an assessment of the likely fault domain is more readily available by inspecting this report.
12 |
13 | ## Grafana
14 | For an overview of this report please see [this explanation](#overview)
15 |
16 | ### Report Panels
17 |
18 | #### Speedtest (Download/Upload)
19 | This panel show the results of tests to the Ookla speedtest service. The average upload and download speeds (in mbps) are shown.
20 |
21 | Note that although these results are interesting, they are results from servers that are out on the Internet. The results are going to be subject to the varying conditions on those servers, the Internet network infrastructure itself and your own organizations's Internet pipe. These factors are likely to vary significantly during the day as conditions change.
22 |
23 | Unless there are other supporting test results, poor speedtest results should not be taken as a definitive indication of an issue on your infrastructure. These results are useful when correlated with other network test results, but their value in isolation is limited.
24 |
25 | #### Wireless Connection Rate/Signal
26 | TBA
27 |
28 | #### DNS Lookup Time (mS)
29 | TBA
30 |
31 | #### HTTP Server Response Time (mS)
32 | TBA
33 |
34 | #### DHCP Renewal Time
35 | TBA
36 |
37 | #### TCP iPerf Rate
38 | TBA
39 |
40 | #### Ping Targets RTT Avg Times
41 | TBA
42 |
43 | #### UDP iPerf Throughput
44 | TBA
45 |
46 | #### iPerf UDP (Jitter/Loss)
47 | TBA
48 |
49 | #### Poller Status Info
50 | TBA
51 |
52 |
53 |
54 | ## Splunk
55 | For an overview of this report please see [this explanation](#overview)
56 |
57 | ### Report Panels
58 |
59 | #### Speedtest (Download/Upload)
60 | This panel show the results of tests to the Ookla speedtest service. The average upload and download speeds (in mbps) are shown.
61 |
62 | Note that although these results are interesting, they are results from servers that are out on the Internet. The results are going to be subject to the varying conditions on those servers, the Internet network infrastructure itself and your own organizations's Internet pipe. These factors are likely to vary significantly during the day as conditions change.
63 |
64 | Unless there are other supporting test results, poor speedtest results should not be taken as a definitive indication of an issue on your infrastructure. These results are useful when correlated with other network test results, but their value in isolation is limited.
65 |
66 | #### Wireless Connection Rate/Signal
67 | TBA
68 |
69 | #### DNS Lookup Time (mS)
70 | TBA
71 |
72 | #### HTTP Server Response Time (mS)
73 | TBA
74 |
75 | #### DHCP Renewal Time
76 | TBA
77 |
78 | #### TCP iPerf Rate
79 | TBA
80 |
81 | #### Ping Targets RTT Avg Times
82 | TBA
83 |
84 | #### UDP iPerf Throughput
85 | TBA
86 |
87 | #### iPerf UDP (Jitter/Loss)
88 | TBA
89 |
90 | #### Poller Status Info
91 | TBA
92 |
--------------------------------------------------------------------------------
/mkdocs/docs/db_smb.md:
--------------------------------------------------------------------------------
1 | Title: SMB
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - SMB
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_speedtest.md:
--------------------------------------------------------------------------------
1 | Title: Speedtest
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - Speedtest
5 |
6 | ## Grafana
7 | Help page - TBA
8 |
9 |
10 | ## Splunk
11 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_tcp_iperf3.md:
--------------------------------------------------------------------------------
1 | Title: TCP iperf3
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - TCP iperf3
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_udp_iperf3.md:
--------------------------------------------------------------------------------
1 | Title: UDP iperf3
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - UDP iperf3
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/db_wireless.md:
--------------------------------------------------------------------------------
1 | Title: Wireless Detail
2 | Authors: Nigel Bowden
3 |
4 | # Dashboard - Wireless Detail
5 |
6 |
7 | ## Grafana
8 | Help page - TBA
9 |
10 |
11 | ## Splunk
12 | Help page - TBA
--------------------------------------------------------------------------------
/mkdocs/docs/extra.css:
--------------------------------------------------------------------------------
1 | body,
2 | input {
3 | color: #000;
4 | }
5 |
6 | .md-nav {
7 | font-size: 14px;
8 | line-height: 1.4;
9 | }
10 |
11 | .md-typeset {
12 | font-size: .7rem;
13 | line-height: 1.5;
14 | }
15 |
16 | .md-typeset code,
17 | .md-typeset pre {
18 | white-space: pre-wrap;
19 | color: #532ba8;
20 | }
21 |
22 | .md-logo img {
23 | width: 48px;
24 | height: 48px;
25 | }
26 |
27 | @media only screen and (min-width: 76.25em) {
28 | .md-logo img {
29 | width: 24px;
30 | height: 24px;
31 | }
32 | }
33 |
34 | .text-center {
35 | text-align: center !important;
36 | }
37 |
38 | /* needed because images have `max-width: 100%` in the theme */
39 | img {
40 | height: auto;
41 | }
42 |
--------------------------------------------------------------------------------
/mkdocs/docs/faq.md:
--------------------------------------------------------------------------------
1 | # FAQ
2 |
3 | ## How can I report a bug / ask a question / make a suggestion for wiperf?
4 |
5 | Please checkout the [discussion section](https://github.com/wifinigel/wiperf/discussions) of the wiperf site of [GitHub](https://github.com/wifinigel/wiperf/discussions)
6 |
7 | ## Why do I get a message saying "Switch : failed wiperf mode" when I try to switch on to wiperf mode on the WLAN Pi?
8 |
9 | In almost every instance, this is due to the fact that the configuration file for wiperf has not been configured before trying to switch in to wiperf mode.
10 |
11 | Check out the required instructions here: [Probe configuration](https://wifinigel.github.io/wiperf/probe_configure/)
12 |
13 | ## When using wiperf on the WLAN Pi, how can I remotely flip between classic and wiper modes via the CLI?
14 |
15 | **Warning** : Although it is possible to flip modes remotely (via an SSH session), be aware that you may hit network connectivity issues unless you are very careful. Remember that in classic mode the file `/etc/network/interfaces` and `/etc/wpa_supplicant/wpa_supplicant.conf` are used for network connectivity configuration. In wiperf mode, the files `/etc/wiperf/conf/etc/network/interfaces` and `/etc/wiperf/conf/etc/wpa_supplicant/wpa_supplicant.conf` are used for network connectivity configuration.
16 |
17 | To check the current mode of the wiperf, enter the following command:
18 |
19 | ```
20 | # this files shows the current mode state (i.e. wiperf, wconsole, hotspot or classic)
21 | cat /etc/wlanpi-state
22 | ```
23 |
24 | To check the current mode of wiperf using the wiper switcher script:
25 |
26 | ```
27 | sudo /usr/bin/wiperf_switcher status
28 | ```
29 |
30 | To toggle from classic mode to wiperf:
31 |
32 | ```
33 | sudo /usr/bin/wiperf_switcher on
34 | ```
35 |
36 | To toggle from wiperf mode to classic:
37 |
38 | ```
39 | sudo /usr/bin/wiperf_switcher off
40 | ```
41 |
42 | __(Remember, when switching modes, the wlanpi will reset and you will lose comms for around a minute)__
43 |
44 |
45 |
46 | ## Why does installation of wiperf fail with the message "(fail) pip installation of wiperf_poller failed. Exiting." ?
47 | This is usually due to the fact that the version of python required for wiperf is python version 3.7 or greater. This means that python version 3.7, 3.8...etc are fine but 3.6, 3.5, 3.4, 3.3... etc. will not work.
48 |
49 | To check the version of python on your probe, enter the CLI command: ```python -V``` (note the uppercase 'V').
50 |
51 | If you cannot upgrade your version of python using "apt-get", then you will need to obtain a more recent image for your probe.
52 |
53 | ## How do I use wiperf with a proxy in my network?
54 | Please see this advanced configuration note: [link](adv_proxy.md)
55 |
56 | ## My probe only needs to hit internal network targets. How do I stop the DNS check to google.com?
57 | Before commencing tests, wiperf will perform a test DNS lookup to ensure that DNS is working OK. By default, the DNS target in ```/etc/wiperf/config.ini``` is set to 'google.com'. If your DNS is internal to your network and does not resolve public Internet targets, you can change the section below to point at an internal lookup target (that will pass a lookup!).
58 |
59 | ```
60 | ; connectivity DNS lookup - site used for initial DNS lookup when assessing if DNS working OK
61 | connectivity_lookup: google.com
62 | ```
63 |
64 | ## How do I upgrade to the latest version of wiperf?
65 | Please see the details in this page: [link](probe_upgrade.md)
66 |
67 | ## How do I change the hostname of my probe?
68 | Please see the details in this help page: [link](probe_prepare.md)
69 |
70 | ## Why are MCS & Rx Phy rates missing from my reports?
71 | In several dashboard reports, the reported MCS values & Rx Phy rate may be blank or permanently zero. This is because these values simply are not reported by many NICs. Sorry, there's not much I can do about this as I don't write the wireless NIC drivers.
72 |
73 | ## My probe seems to reboot itself intermittently. Why?
74 | Wiperf has a watchdog feature that it uses to try to reset things when it is having connectivity related difficulties.
75 |
76 | There may be instances when tests are continually failing or wireless connectivity is intermittent due to perhaps being stuck on a remote AP that is sub-optimal from a connectivity perspective.
77 |
78 | If persistent issues are detected, then wiperf will reboot the probe to try to remediate the issue. This will provide the opportunity to the reset all network connectivity and internal processes.
79 |
80 | Note that this is a last ditch mechanism. Wiperf will also try bouncing network interfaces to remediate any short-term connectivity issues, which will likely fix many issues without the need for a full reboot.
81 |
82 | If you observe your probe rebooting on a regular basis (e.g. a couple of times a hour), then check its logs as it is very unhappy about something.
83 |
84 | ## How Can I Harden the Probe Security?
85 | Please see this note for some suggestions for hardening the probe: [link](adv_secure.md)
86 |
87 |
88 | ## Where do I get the dashboard reports for Splunk and Grafana?
89 | Use SFTP/SCP and pull the xml files in ```/usr/share/wiperf/dashboards``` from your probe. Or, visit the wiperf GitHub site [here](https://github.com/wifinigel/wiperf/tree/main/dashboards){target=_blank}
90 |
91 | ## How can I fix my probe to only connect to one specific wireless access point for testing?
92 |
93 | Checkout [this note](adv_fixed_bssid.md) for specific instructions on this configuration.
94 |
95 | ## Can I make a feature suggestion?
96 | Yes, get along to the GitHub site and post your suggestion in the [discussion section](https://github.com/wifinigel/wiperf/discussions){target=_blank} of the wiperf GitHub site. It will be added to my "todo" list.
97 |
98 | ## Can I get some support with wiperf?
99 | I try my best to support folks who are having difficulty, but it's a best efforts endeavour. Please make sure you checkout all of the documentation I've provided, but if all else fails, post a question in the [discussion section](https://github.com/wifinigel/wiperf/discussions){target=_blank} of the wiperf GitHub site. Please be patient...
100 |
101 | ## Can I contribute some code for a new feature for wiperf?
102 | Please, get in touch before starting work on any code you'd like to submit as a PR. I love feedback and ideas, but each new feature costs me more cycles to support. Let's agree it can be included before submitting.
103 |
104 | ## Can I run tests over the Ethernet interface of the WLAN Pi?
105 | Yes, from wiperf v2 onwards.
106 |
--------------------------------------------------------------------------------
/mkdocs/docs/google3a4cd61e7ae2d199.html:
--------------------------------------------------------------------------------
1 | google-site-verification: google3a4cd61e7ae2d199.html
--------------------------------------------------------------------------------
/mkdocs/docs/grafana_configure.md:
--------------------------------------------------------------------------------
1 | Title: Grafana Configuration
2 | Authors: Nigel Bowden
3 |
4 | # Grafana Configuration
5 |
6 | 
7 |
Once the Granafa installation is complete, there are two main tasks remaining:
8 |
9 | - Integration of Grafana with InfluxDB
10 | - Addition of the wiperf dashboards
11 |
12 |
13 | ## Integration of Grafana with InfluxDB
14 | Integration with InfluxDB is required to allow Grafana to send data queries to the InfluxDB database and turn the data in to graphical reports. To do this, Grafana needs to know:
15 |
16 | - the data source is an InfluxDB database
17 | - where it is (IP address & port)
18 | - the name of the database within Influx DB (as we previously configured)
19 | - the access credentials to be used to pull the data out of InfluxDB
20 |
21 | The screen-shots below show the required steps:
22 |
23 | - __Configuration > Data Sources > Add Data Source__:
24 |
25 | 
26 |
27 | - Select __InfluxDB__:
28 |
29 | 
30 |
31 | - Enter the name to be referenced for the connection, the URL, database name, username & password (all highlighted below) - note the InfluxDB values use those configure previously when we set up InfluxDB (the datbase name, username & password settings must match those used in the InfluxDB setup):
32 |
33 | 
34 |
35 | 
36 |
37 | Once completed, if you hit __'Save and Test'__, the database connection test should indicate success if all information has been correctly entered.
38 |
39 |
40 | ## Adding Wiperf Dashboards
41 |
42 | Dashboard xml files can be obtained from the ```/usr/share/wiperf/dashboards``` folder of the probe. These may be downloaded to your local laptop using a utlity such as SCP or SFTP. Alternatively, the dashboard files may be accessed in the main wiperf repo at : [folder](https://github.com/wifinigel/wiperf/tree/main/dashboards){target=_blank}
43 |
44 | Once the dashboard files have been downloaded, they may be imported to Grafana using the following steps:
45 |
46 | - Use the menu option __Dashboards > Manage > Import__:
47 |
48 | 
49 |
50 | - Hit the __'Upload Json'__ button and select the dashboard file on your local laptop that you'd like to upload
51 |
52 | 
53 |
54 | - The name of the imported report will be shown as indicated. If you'd like to create or select a folder, this can be done in the __'Folder'__ field. The database connection previously created as the data source must also be selected to ensure the InfluxDB database can be queried:
55 |
56 | 
57 |
58 | Once __'Import'__ is hit, the dashboard will be available in the main Grafana GUI.
59 |
60 | To find out more about usng Grafana, visit the [Grafana getting started pages.](https://grafana.com/docs/grafana/latest/getting-started/getting-started/){target=_blank}
61 |
62 |
63 |
--------------------------------------------------------------------------------
/mkdocs/docs/grafana_install.md:
--------------------------------------------------------------------------------
1 | Title: Grafana Installation
2 | Authors: Nigel Bowden
3 |
4 | # Grafana Installation
5 |
6 | 
7 |
Obtaining and installing the Grafana software is straightforward. The following notes provide a high level overview of the steps required. Note that these instructions are for Grafana version 6.7 (other versions may work, but have not been tested):
8 |
9 |
10 | - Visit the Grafana 6.7 installation guide at [https://grafana.com/docs/grafana/v6.7/](https://grafana.com/docs/grafana/v6.7/){target=_blank}. This provides acces to a wide variety of information about Grafanam including supported OS'es and platform concepts
11 | - To download the code and to see the commands required for installation on the server CLI, visit the following download page: [https://grafana.com/grafana/download](https://grafana.com/grafana/download){target=_blank}
12 | - Select the required version, Open Source edition and your OS (most likely a Linux variant)
13 | - Make a copy of the CLI commands provided to download and install the software for your OS
14 | - SSH to the server that will be used to host Grafana
15 | - Make sure your server has Internet connectivity (as it will need to pull down the required software)
16 | - On the CLI of your server, paste in the copied commands to kick-off the software download & install
17 | - Once installation is complete, start the InfluxDB processes with the server CLI command: ```sudo systemctl start grafana-server```
18 | - Ensure that the service will be started in the server is rebooted with: ```sudo systemctl enable grafana-server```
19 | - Check the software is installed and running by executing the following command on the server CLI: ```sudo systemctl status grafana-server``` (ensure the process is "active (running)" )
20 |
21 | As a final check, ensure that the Grafana web GUI is available using the URL: http://<server_IP>:3000/ (Note that the default login/pwd is admin/admin)
22 |
23 |
--------------------------------------------------------------------------------
/mkdocs/docs/grafana_platform.md:
--------------------------------------------------------------------------------
1 | Title: Grafana Platform
2 | Authors: Nigel Bowden
3 |
4 | # Grafana Platform
5 |
6 | 
7 |
Grafana is an open-source visualization tool that allows us to create reports around the data sent from wiperf probes to InfluxDB. It can integrates with a variety of data sources to query raw data and provides a wide variety of graphical report options - in our case, Grafana integrates with InfluxDB
8 |
9 | This guide does not cover all installation details of the software package, as these may be obtained from the official Grafana web site: [https://grafana.com/docs/grafana/latest/](https://grafana.com/docs/grafana/latest/){target=_blank}. Installation instructions are available for all major operating systems. Note that although Windows is supported, if you intend to install Grafana on the same platform as InfuxDB, Windows is not an option as InfluxDB v1.8 does not support Windows.
10 |
11 | To install Grafana and use it with a handful of probes, a modest server may be built (e.g. I use a low-end Intel NUC running Ubuntu), so for testing purposes, don’t get too hung up on sourcing a high end server. If you'd like to look into server requirements further, then [check out this page](https://grafana.com/docs/grafana/latest/installation/requirements/){target=_blank}.
12 |
13 | Note that Grafana is an open-source product. There is no cost for downloading and installing your own instance of the software.
14 |
15 |
16 |
17 |
--------------------------------------------------------------------------------
/mkdocs/docs/images/generic_overview.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/generic_overview.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/github_token.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/github_token.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_cfg1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_cfg1.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_cfg2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_cfg2.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_cfg3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_cfg3.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_cfg4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_cfg4.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_dashboard1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_dashboard1.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_dashboard2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_dashboard2.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_dashboard3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_dashboard3.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_logo.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/grafana_overview.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/grafana_overview.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/hardware.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/hardware.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/http_summary.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/http_summary.jpg
--------------------------------------------------------------------------------
/mkdocs/docs/images/influx_ethernet_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/influx_ethernet_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/influx_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/influx_logo.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/influx_wireless_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/influx_wireless_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/influx_zerotier_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/influx_zerotier_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/iperf_summary.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/iperf_summary.jpg
--------------------------------------------------------------------------------
/mkdocs/docs/images/neo3.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/neo3.jpg
--------------------------------------------------------------------------------
/mkdocs/docs/images/probe_summary.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/probe_summary.jpg
--------------------------------------------------------------------------------
/mkdocs/docs/images/rpi.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/rpi.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/speedtest_summary.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/speedtest_summary.jpg
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg1.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg10.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg10.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg11.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg11.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg12.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg12.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg13.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg13.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg14.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg14.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg15.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg15.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg16.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg16.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg17.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg17.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg18.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg18.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg19.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg19.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg2.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg20.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg20.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg21.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg21.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg3.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg4.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg5.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg6.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg6.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg7.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg7.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg8.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg8.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_cfg9.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_cfg9.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_ethernet_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_ethernet_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_login.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_login.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_logo.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_overview.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_overview.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_software1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_software1.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_software2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_software2.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_software3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_software3.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_software4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_software4.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_wireless_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_wireless_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/splunk_zerotier_mgt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/splunk_zerotier_mgt.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/wiperf_logo.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/wiperf_logo.png
--------------------------------------------------------------------------------
/mkdocs/docs/images/wlanpi.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/wifinigel/wiperf/388990a241e9d02f2d1120c04fdc4e60e4007b24/mkdocs/docs/images/wlanpi.png
--------------------------------------------------------------------------------
/mkdocs/docs/index.md:
--------------------------------------------------------------------------------
1 | Title: Wiperf V2 Documentation
2 | Authors: Nigel Bowden
3 |
4 | # wiperf V2: An Open Source UX Performance Probe
5 |
6 | 
7 |
8 | 
9 |
10 | Wiperf is a utility that can be installed on a [WLAN Pi](https://wlan-pi.github.io/wlanpi-documentation/) or a Raspberry Pi to act as a network probe that runs a series of network performance tests. It is primarily intended to provide an indication of the end-user experience on a wireless network, but may also be used as an ethernet-connected probe.
11 |
12 | The probe can run the following tests to give an indication of the performance of the network environment into which it has been deployed:
13 |
14 | - Wireless connection health check (if wireless connected)
15 | - Speedtest (Ookla/Librespeed)
16 | - iperf3 (TCP & UDP tests)
17 | - ICMP ping
18 | - HTTP
19 | - DNS
20 | - DHCP
21 | - SMB
22 |
23 | Tests may be performed over the wireless or ethernet interface of the probe unit. The results must then be sent back to a Splunk or InfluxDB server (which we'll call the "data server") to provide a reporting capability. (*NOTE: There is ([usually](adv_rpi_standalone.md)) no graphing/reporting capability on the wiperf probe itself*)
24 |
25 | Wiperf has been primarily designed to be a tactical tool for engineers to deploy on to a wireless network where issues are being experienced and longer term monitoring may be required. It is not designed to replace large-scale commercial offerings that provide wireless and end-user experience monitoring in a far more comprehensive and user-friendly fashion.
26 |
27 | 
28 |
29 | Tests are run on the wiperf probe at a configured interval (usually 5 minutes) and collected data is sent back to a data server over a network connection between the probe and data server (no connection = no data collection). The data server must be an instance of either:
30 |
31 | - Splunk, or
32 | - InfluxDB with Grafana
33 |
34 | ## Data Server
35 | The core focus of this project is the probe device that gathers the network performance data in which we are interested. However, the data server is a critical component that allows visualization of that performance data. High-level configuration details will be provided to "get you going", but detailed information about the operation of these platforms is beyond the scope of this project.
36 |
37 | Both of the data servers supported are "NoSQL" servers, which means that no data structures have to be pre-defined in database tables. This means we can send our data structures, that contain network performance data, to the server with very little set-up compared to traditional database servers.
38 |
39 | As long as we have a valid set of credentials for the data server, we can just send JSON-formatted data over HTTPS in whatever structure we choose. A database query language on the data server allows us to retrieve and graph the data collected by the wiperf probe.
40 |
41 | ### Splunk
42 | Splunk is supported on all popular operating systems and is very easy to set up on your server of choice. It acts as both the data store and visualization platform. Splunk is a commercial, rather than open-source product.
43 |
44 | The volume of data returned by the probe is very low, so the free tier of Splunk may be used to gather and report on data. For details on how to set up a Splunk server, start at this documentation page: [link][splunk_platform.md]
45 |
46 | - Splunk product web site: [https://www.splunk.com/](https://www.splunk.com/)
47 |
48 | ### InfluxDB/Grafana
49 |
50 | Grafana is a popular open-source data visualization tool. It is used to graph the performance data collected by wiperf. However, Grafana needs a data server from which to pull its network performance data. To meet this requirement, the InfluxDB database server is used. Like Grafana, InfluxDB is also an open-source package.
51 |
52 | For small-scale instances, Grafana & Influx may be installed on the same server platform and Grafana configured to use the local instance of Influx as its data source.
53 |
54 | - Grafana web site (v6.7): [https://grafana.com/](https://grafana.com/)
55 | - Influx web site (v.1.8): [https://www.influxdata.com](https://www.influxdata.com)
56 |
57 | ## Workflow to Setup Wiperf
58 |
59 | The workflow to get Wiperf fully operational consists of a number of steps that break down in to two main areas:
60 |
61 | - Probe setup (the RPi or WLAN Pi device itself)
62 | - Data server setup (the Splunk or Influx/Grafana server)
63 |
64 | The data server setup tends to be a task that needs completion only once (or at least very infrequently).
65 |
66 | Conversely, some or all of the probe setup will need to be completed each time a probe is deployed - this is mainly due to the fact that in each environment in which it is deployed, the connectivity for the probe will vary (e.g. different SSID, different network connection type etc.).
67 |
68 | Here is an overview of the workflow::
69 |
70 | - Data server setup:
71 | - Prepare a server platform
72 | - Obtain the data server application software
73 | - Install the data server application(s)
74 | - Configure the data server application(s)
75 | - Probe setup:
76 | - Obtain a probe device (Raspberry Pi or WLAN Pi)
77 | - Prepare the device for the wiperf software
78 | - Install the wiperf software
79 | - Configure the wiperf software
80 | - Deploy & test the wiperf probe
81 |
82 | __Links:__
83 |
84 | - Start here for Splunk: [link](splunk_platform.md)
85 | - Start here for InfluxDB/Grafana: [link](influx_platform.md)
86 | - Start here for the probe: [link](probe_platform.md)
87 |
88 | In addition to the setup and deployment of the components, there may also be a requirement to troubleshoot the setup. The following pages provide useful support information:
89 |
90 | - [Troubleshooting steps](troubleshooting.md)
91 | - [Review known issues / FAQ](faq/md)]
92 |
93 | ## Further Documentation References
94 |
95 | - [Configuration file parameters](config.ini.md)
96 | - [Data points sent by the probe to the data server platform](data_points.md)
97 |
98 |
99 | 
100 |
101 | ## Credits
102 | This project has had some great input from a number of people. Here are a few words of thanks to those who have been so generous in helping out.
103 |
104 | Thanks to [Kristian Roberts](https://uk.linkedin.com/in/krisalexroberts) for his invaluable project input, testing and guidance on Splunk. He kicked this whole thing off and it definitely wouldn't have happened without him. A top bloke.
105 |
106 | Thanks also to Eric Garnel and James Whitehead for their invaluable help in providing me so many Grafana dashboard files to "borrow" from. It was a steep learning curve for me, but the generosity of Eric & James really helped me to get to grips with Grafana. Also thanks to Eric for providing the idea to use InfluxDB as a data source (....even if I did use the wrong version initially! Lol).
107 |
108 | The code for the MOS score calculation was kindly provided by Mario Gingras. What a great idea...I wish I'd thought of that! Thanks Mario, it's great addition.
109 |
110 | ## Caveats
111 | This free software is provided for you to use at your own risk. There are no guarantees around its operation, suitability or accuracy of the data that it provides. Please consult the [license file](https://github.com/wifinigel/wiperf/blob/main/License.txt) shipped with this software.
112 |
113 | ## Developer
114 | Nigel Bowden (WifiNigel):
115 |
116 | - (https://wifinigel.blogspot.com)[https://wifinigel.blogspot.com]{target=_blank}
117 | - (https://github.com/wifinigel)[https://github.com/wifinigel]{target=_blank}
118 |
119 |
120 |
121 |
--------------------------------------------------------------------------------
/mkdocs/docs/influx_configure.md:
--------------------------------------------------------------------------------
1 | Title: Influx Configuration
2 | Authors: Nigel Bowden
3 |
4 | # Influx Configuration
5 | 
Now that we have the InfluxDB software installed, the next step is to create a database in which data from our wiperf probes will be stored.
6 |
7 | To create the database, we need to execute a series of commands on the CLI of the Influx DB server. Follow the following steps to create the required database:
8 |
9 | - Check the InfluxDB service is running before starting ```sudo systemctl status influxdb``` (ensure the process is "active (running)" )
10 | - Enter the InfluxDB shell using the following command: ```sudo influx``` (shell is indicated by the new ">" prompt)
11 | - Create an admin user to administer InfluxDB:
12 | - ```CREATE USER admin WITH PASSWORD 'letmein' WITH ALL PRIVILEGES```
13 | - Exit the InfluxDB shell with the command ```exit``` to return to the standard Linux CLI
14 | - Edit the InfluxDB configuration file (/etc/influxdb/influxdb.conf):
15 | - ```sudo nano /etc/influxdb/influxdb.conf```
16 | - uncomment the line ```# auth-enabled = false``` in the ```[http]``` section and change to ```auth-enabled = true``` to enable authentication of access to the database
17 | - restart the InfluxDB process for the change to take effect: ```sudo systemctl restart influxdb```
18 | - Enter the InfluxDB shell again using the following command: ```sudo influx -username admin -password letmein``` (now using authentication)
19 | - Create a new database with the following commands:
20 | - ```CREATE DATABASE wiperf```
21 | - Check the new database exists using: ```SHOW DATABASES``` (the database "wiperf" should be shown in the list)
22 | - Create and assign a user who can write to the wiperf database (i.e. a probe) using the following CLI commands (note the single and double quotes are signifcant for the user & pwd fields):
23 | - ```CREATE USER "wiperf_probe" WITH PASSWORD 's3cr3tpwd99'```
24 | - ```GRANT WRITE ON "wiperf" TO "wiperf_probe"```
25 | - Create and assign a user who can read from the wiperf database (i.e. the Grafana program) using the following CLI commands (note the single and double quotes are signifcant for the user & pwd fields):
26 | - ```CREATE USER "grafana" WITH PASSWORD 'R34dth3DB'```
27 | - ```GRANT read ON "wiperf" TO "grafana"```
28 | - Exit the InfluxDB shell with the command ```exit``` t return to the Linux CLI
29 |
30 | At this point, the InfluxDB service is ready to receive data from a probe. If you have any probes ready to go, make sure they use the "wiperf_probe" user credentials in their configuration file so that they can add their data to the database.
31 |
32 | If you believe you have a probe that has successfully sent data, you can check the database contents using the following commands in the InfluxDB shell:
33 |
34 | - ```USE wiperf```
35 | - ```SHOW SERIES```
36 | - ```SELECT * FROM "wiperf-speedtest"```
37 | - ```SHOW FIELD KEYS ON "wiperf" FROM "wiperf-speedtest"```
38 |
39 | To find out more details, please checkout the official getting started guide: [https://docs.influxdata.com/influxdb/v1.8/introduction/get-started/](https://docs.influxdata.com/influxdb/v1.8/introduction/get-started/){target=_blank}
40 |
41 | For more information about adding users, check out: [https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#user-management-commands){target=_blank}
42 |
43 |
44 | __Note:__ *You are advised to use your own passwords for the password fields shown in this document to ensure they are secured.*
--------------------------------------------------------------------------------
/mkdocs/docs/influx_install.md:
--------------------------------------------------------------------------------
1 | Title: Influx Installation
2 | Authors: Nigel Bowden
3 |
4 | # Influx Installation
5 | 
Obtaining and installing the InfluxDB software is very straightforward. here is a high-level overview of the steps required:
6 |
7 | - On your laptop, open a browser and obtain the required commands to download & install the software by visiting the following web page and selecting the v1.8 download option: [https://portal.influxdata.com/downloads/](https://portal.influxdata.com/downloads/){target=_blank}
8 | - Copy the install commands provided for your OS
9 | - Make sure your InfluxDB server has Internet connectivity (as it will need to pull down the required software)
10 | - SSH to the server that will be used to host InfluxDB
11 | - On the CLI of your server (your SSH session), paste in the copied commands to kick-off the software download & install
12 | - Once installation is complete, start the InfluxDB processes with the server CLI command: ```sudo systemctl start influxdb```
13 | - Make sure the InfluxDB service starts after a platform reboot: ```sudo systemctl enable influxdb```
14 | - Check the software is installed and running by executing the following command on the server CLI: ```sudo systemctl status influxdb``` (ensure the process is "active (running)" )
15 |
16 | The next step is to [create a database](influx_configure.md) to drop our incoming data (from wiperf probes) into.
17 |
18 |
--------------------------------------------------------------------------------
/mkdocs/docs/influx_platform.md:
--------------------------------------------------------------------------------
1 | Title: InfluxDB Platform
2 | Authors: Nigel Bowden
3 |
4 | # InfluxDB Platform
5 | 
InfluxDB is a time-series database that is used to store the network performance data that is collected by wiperf probes. It has many other uses and is used by many organizations as a back-end store for use-cases involving large amounts of timestamped data, including DevOps monitoring, application metrics, IoT sensor data, and real-time analytics.
6 |
7 | InfluxDB does not report on network performance report data, but is used as a data repository source for Grafana in our use-case. Details about Grafana are provide later in this documentation. Note that for our use-case, we are using InfluxDB v1.8 (not v2.0).
8 |
9 | Influx can be installed on a wide variety of Linux-based platforms that can be viewed [here](https://docs.influxdata.com/influxdb/v1.8/introduction/install/){target=_blank}. These include Ubuntu, Debian and macOS (no Windows)
10 |
11 | This guide does not cover all installation details of the software package, as these may be obtained when downloading and installing the software.
12 |
13 | To install InfluxDB and use it with a handful of probes, a modest server may be built (e.g. I use a low-end Intel NUC running Ubuntu), so for testing purposes, don’t get too hung up on sourcing a high-end server. If you'd like to look into server requirements further, then [check out this page](https://docs.influxdata.com/influxdb/v1.8/guides/hardware_sizing/){target=_blank}.
14 |
15 | Note that InfluxDB is an open-source product. There is no cost for downloading and installing your own instance of the software.
16 |
17 | ## Connectivity Planning
18 | One area to consider is connectivity between the wiperf probe and the InfluxDB instance. The wiperf probe needs to be able to access the InfluxDB server to send its results data. If the wiperf probe probe is being deployed on a network, how is the performance data generated by the probe going to get back to the InfluxDB server?
19 |
20 | If the probe is being deployed on a customer network to perform temporary monitoring, it will need to join the wireless network under test (or be plugged in to an ethernet switch port if testing a wired connection). But how is the wiperf probe going to send its data to the InfluxDB server ? Many environments may not be comfortable with hooking up the wiperf probe to their wired network, potentially bridging wired and wireless networks. In some instances an alternative is required (e.g. send the results data over the wireless network itself out to the Internet to a cloud instance or via a VPN solution such as Zerotier.)
21 |
22 | Three topology deployment options are supported:
23 |
24 | - Results data over wireless
25 | - Results data over Ethernet
26 | - Results data over VPN/wireless
27 |
28 | The method used is configured on the wiperf probe probe in its config.ini file. It is important to understand the (viable) connectivity path prior to deploying both the probe and the InfluxDB server.
29 |
30 | The 3 connectivity options are discussed below.
31 |
32 | ### Results Data Over Wireless
33 |
34 | 
35 |
36 | In this topology the wiperf probe is configured to join an SSID that has the InfluxDB server accessible via its WLAN interface. Typically, the InfluxDB server will reside in a cloud or perhaps on a publicly accessible VPS. The wiperf probe will continually run the performance tests over the wireless connection and then upload the results directly to the InfluxDB server over the WLAN connection.
37 |
38 | !!! note "config.ini settings:"
39 | ```
40 | mgt_if: wlan0
41 | data_host:
42 | ```
43 |
44 | ### Results data over Ethernet
45 |
46 | 
47 |
48 | If the InfluxDB server is being run on the inside of a network environment, it may be preferable to return results data via the Ethernet port of the wiperf probe. This topology also has the advantage of results data not being impacted if there are wireless connectivity issues on the wiperf probe WLAN connection. To achieve the correct traffic flow, a static route for management traffic is automatically injected into the route table of the wiperf probe to force results data over the Ethernet port.
49 |
50 | !!! note "config.ini settings:"
51 | ```
52 | mgt_if: eth0
53 | data_host:
54 | ```
55 |
56 |
57 | ### Results data over Zerotier/wireless
58 |
59 | 
60 |
61 | A simple way of getting the wiperf probe talking with your Splunk server, if it has no direct access, is to use the [Zerotier](https://zerotier.com/) service to create a virtual overlay network via the Internet.
62 |
63 | In summary, both the InfluxDB server and wiperf probe have the [Zerotier](https://zerotier.com/){target=_blank} client installed. Both are then added to your Zerotier dashboard (by you) and they start talking! Under the hood, both devices have a new virtual network interface created and they connect to the [Zerotier](https://zerotier.com/){target=_blank} cloud-based network service so that they can communicate on the same virtual network in the cloud. As they are on the same subnet from a networking perspective, there are no routing issues to worry about to get results data from the wiperf probe to the InfluxDB server.
64 |
65 | [Zerotier](https://zerotier.com/){target=_blank} has a free subscription tier which allows up to 100 devices to be hooked up without having to pay any fees. It’s very easy to use, plus your InfluxDB server can be anywhere! (e.g. on your laptop at home). Both devices need access to the Internet for this solution to work.
66 |
67 | You can sign up for free, create a virtual network and then just add the IDs that are created by the InfluxDB server and wiperf probe when the client is installed.
68 |
69 | !!! note "config.ini settings:"
70 | ```
71 | mgt_if: ztxxxxxx (check your local ZeroTier interface designation using ```ifconfig```)
72 | data_host:
73 | ```
74 |
75 | !!! info "Install ZeroTier"
76 |
77 | To install Zerotier on the wiperf probe (or an Ubuntu server), enter the following:
78 |
79 | ```
80 | curl -s https://install.zerotier.com | sudo bash
81 | sudo zerotier-cli join
82 | sudo zerotier-cli status
83 |
84 | # To remove at a later date:
85 | sudo apt remove zerotier-one
86 | ```
87 |
88 |
89 |
--------------------------------------------------------------------------------
/mkdocs/docs/operation.md:
--------------------------------------------------------------------------------
1 | Title: Operation Overview
2 |
3 | # Overview of Operation
4 |
5 | 
6 |
7 | Wiperf is an open source utility that runs on a Raspberry Pi or a WLAN Pi hardware device. It provides network probe functionality to gather performance data to give an indication of how a network looks from an end user perspective.
8 |
9 | It runs a series of tests to gather metrics on network connectivity and performance through the execution of tests such ICMP ping, DNS lookups and iperf. These are fully configurable by editing a local configuration file on the probe device at the time of deployment.
10 |
11 | ## Configuration
12 | To configure the details of the tests to be run on a probe, a local configuration file on the probe needs to be updated. This will provide information to the probe about items such as the required network connectivity (e.g. wireless/ethernet), IP and credential information for the data server and test details.
13 |
14 | The configuration file can be updated by accessing the CLI of the probe (usually via SSH) and editing the file ```/etc/wiperf/config.ini```.
15 |
16 | In addition, configuration of a number of other Linux-OS files (e.g. `/etc/network/interfaces`) is also required to connect the probed to the network under test, and run wiperf tests on a regular basis. More details about the probe configuration can be found on [this page](probe_configure.md).
17 |
18 | ## Logging
19 | Following the completion of the configuration steps, wiperf will run every 5 minutes, performing the configured network tests and sending results data to a reporting server.
20 |
21 | A number of logs are generated to provide support information about the status and operation of the wiperf process. For more information about the logs created, please visit our [troubleshooting page](troubleshooting.md#logging).
22 |
23 | ## Reporting
24 | Gathering the data with a probe is only half of the story when using wiperf. The gathered data must be sent to a data collection server to allow it to be visualized to allow analysis of network performance. The data server must be an instance of either:
25 |
26 | - Splunk, or
27 | - InfluxDB with Grafana
28 |
29 | ### Splunk
30 |
31 | 
32 |
33 | The graphic above outlines the collection of network performance data and how this is sent to Splunk by the wiperf probe. The Splunk instance may be provided anywhere that is convenient (e.g. on a server locally, via VPN, cloud etc.)
34 |
35 | In summary, the steps for data collection are as follows:
36 |
37 | 1. A wiperf probe (i.e. a WLAN Pi or Raspberry Pi) is configured to perform tests and send results to a Splunk server
38 | 2. The probe performs the configured tests (e.g. speedtest, iperf, http etc.)
39 | 3. The results of each test are sent over https to the Splunk server for storage and later analysis
40 | 4. The data is analyzed by accessing the dashboard (a web GUI) of the Splunk server with a browser
41 |
42 | (*Note that the Splunk server acts as both the data repository and reporting platform for collected data*)
43 |
44 | ### Grafana/Influx
45 |
46 | 
47 |
48 | The graphic above outlines the collection of network performance data and how this is sent to Influx & Grafana by the wiperf probe.
49 |
50 | Grafana is a popular open-source data visualization tool. It is used to graph the performance data collected by wiperf. However, Grafana needs a data source from which to pull its network performance data. To meet this requirement, a InfluxDB database server is used. Like Grafana, InfluxDB is also an open-source package. (*Note that this setup contrasts with using Splunk, which allows us to use the same package to provide both the data storage and analysis/visualization functions*)
51 |
52 | For small-scale instances, Grafana & Influx may be installed on the same server platform and Grafana configured to use the local instance of InfluxDB as its data source.
53 |
54 | Grafana & Influx may be provided anywhere that is convenient (e.g. on a server locally, via VPN, cloud etc.). Note that wiperf only needs to be able to send data to InfluxDB - it requires no communication with the Grafana instance.
55 |
56 | In summary, the steps for data collection are as follows:
57 |
58 | 1. A wiperf probe (i.e. a WLAN Pi or Raspberry Pi) is configured to perform tests and send results to an InfluxDB server
59 | 2. The probe performs the configured tests (e.g. speedtest, iperf, http etc.)
60 | 3. The results of each test are sent over https to the InfluxDB server for storage
61 | 4. Grafana is configured to use InfluxDB as its data source to allow visualization of performance data
62 | 5. Data is analysed by accessing the dashboard (a web GUI) of the Grafana server, which pulls the required dashboard data from InfluxDB.
63 |
64 |
--------------------------------------------------------------------------------
/mkdocs/docs/probe_deploy.md:
--------------------------------------------------------------------------------
1 | Title: Probe Deployment
2 | Authors: Nigel Bowden
3 |
4 | # Probe Deployment
5 | Once the probe is configured and tested, it's time to deploy it out in the real world.
6 |
7 | When deploying, here are a few things to check and remember:
8 |
9 | 1. Verify that the probe has the network connectivity that you expect once it has been deployed. The following CLI commands will help to check connectivity:
10 | 1. Wireless NIC: ```iwconfig``` (is the probe joining the wireless network?)
11 | 2. IP address: ```ifconfig``` (do the interfaces being used have an IP address?)
12 | 3. Internet connectivity: ```ping google.com``` (can the probe get to the Internet, if that is expected?)
13 | 2. Is the probe deployed in the topology you originally intended? If the environment is not as you expected and you need to use a different interface for a particular operation, make sure you have updated ```config.ini``` so that wiperf knows where to send traffic (otherwise, you may hit routing issues)
14 | 3. Check the output of ```/var/log/wiperf_agent.log``` to make sure everything is working with no issues once deployed. If there are hitches, they will generally be highlighted in this file, with a detailed explanation of what has failed.
15 |
16 | If you run in to any deployment issues, check out the [troubleshooting](troubleshooting.md) and [FAQ](faq.md) sections of this site.
17 |
18 |
19 |
20 |
21 |
--------------------------------------------------------------------------------
/mkdocs/docs/probe_install.md:
--------------------------------------------------------------------------------
1 | Title: Probe Software Installation
2 | Authors: Nigel Bowden
3 |
4 | # Probe Software Installation
5 | This section takes a look at how we install various additional required software packages on to our probe. This includes any pre-requisite software packages and the wiperf software itself.
6 |
7 | ## WLAN Pi
8 | Good news! If you're using a WLAN Pi (v2.x image), you already have the software required (it's part of the WLAN Pi software image). Go to the [next section of this documentation site](probe_configure.md).
9 |
10 | !!! Note
11 | __New in V2.1:__ For SMB test support or to use Librespeed for speedtest, you will need to install a couple of optional extra packages as detailed in these reference documents:
12 |
13 | * [SMB test Support](reference_doc_smb.md)
14 | * [Librespeed Support](reference_doc_librespeed.md)
15 |
16 | ## Raspberry Pi
17 | The RPi requires a few pre-requisite Linux packages before we can install the wiperf software itself. Note that the probe must be connected to a network (via ethernet or wireless) that has access to the Internet to download the required code.
18 |
19 | You will need CLI access to the probe to perform the steps detailed below.
20 |
21 | ### Package Updates
22 | Before we start adding pre-requisite packages, it's always a good idea to update the existing Linux packages on our RPi to make sure we have the "latest and greatest". This may take a few minutes to complete as many files may be downloaded & updated, depending on when/if your RPi was last updated:
23 |
24 | ```
25 | # download & update latest Linux packages
26 | sudo apt-get update && sudo apt-get upgrade -y
27 | # Reboot if any new packages were installed
28 | sudo reboot
29 | ```
30 |
31 | ### Pre-requisite Packages
32 | Next, we need to install additional Linux packages that may not be included as part of the standard RPi distribution:
33 |
34 | - pip3
35 | - iperf3
36 | - git
37 | - curl
38 | - netcat
39 |
40 | These are installed with the following CLI commands:
41 |
42 | ```
43 | sudo apt-get update
44 | sudo apt-get install python3-pip iperf3 git curl netcat -y
45 | sudo reboot
46 | ```
47 |
48 | !!! Note
49 | __New in V2.1:__ For SMB test support or to use Librespeed for speedtest, you will need to install a couple of optional extra packages as detailed in these reference documents:
50 |
51 | * [SMB test Support](reference_doc_smb.md)
52 | * [Librespeed Support](reference_doc_librespeed.md)
53 |
54 | ### wiperf Software Installation
55 | To install the wiperf code itself on to the RPi, execute the following CLI command:
56 |
57 | ```
58 | curl -s https://raw.githubusercontent.com/wifinigel/wiperf/main/setup.sh | sudo bash -s install rpi
59 | ```
60 |
61 | This will initiate the download and installation of a number of python packages, together with the wiperf code itself. This will take a few minutes to complete.
62 |
63 |
64 | Once installation is complete, our final step is to [configure the wiperf probe](probe_configure.md) to perform the tests we'd like to run, and provide details of where the probe needs to send its data (i.e. our data server).
65 |
66 |
--------------------------------------------------------------------------------
/mkdocs/docs/probe_platform.md:
--------------------------------------------------------------------------------
1 | Title: Probe Platform
2 | Authors: Nigel Bowden
3 |
4 | # Probe Platform
5 |
6 | Wiperf has been primarily designed to work on the NEO2 version of the WLAN Pi platform and the Raspberry Pi platforms.
7 |
8 | ## WLAN Pi
9 |
10 | 
11 |
12 | Wiperf is baked in to the image of the WLAN Pi. It can be activated by switching in to wiperf mode on the WLAN Pi. Find out more details at the official documentation site for the WLAN Pi: [https://wlan-pi.github.io/wlanpi-documentation/](https://wlan-pi.github.io/wlanpi-documentation/){target=_blank}
13 |
14 | ## Raspberry Pi
15 |
16 | 
17 |
18 | Wiperf on the RPi has been tested on models that have an internal Wi-Fi NIC: 3b+, 3a+ and 4. It will likely work on most that have an internal NIC, but I don't have the resources or time to try them all.
19 |
20 | Earlier versions of the RPi that do not have a an internal NIC will need some type of USB wireless adapter, but as support for external wireless NICs is very poor and many tend to be 2.4GHz only, I've not explored this area in detail.
21 |
22 | Unfortunately, getting a 2 stream 802.11ac NIC going seems very difficult due to the lack of drivers available, so the internal, single stream NIC is often best we can generally do. However, the situation does seem to be improving with more recent kernels, so test out a few NICs and see how you do.
23 |
24 | Using a single stream NIC has its limitations as speed performance is very limited, but as the main aim of wiperf is to monitor user experience (particularly changes in that experience), then it's good enough for many use-cases where we are mainly interested in changes in relation to the usual baseline.
25 |
26 | __Note: __*Please use an RPi platform that is used only as a dedicated wiperf probe. Please do not install additional packages other than those recommended. Also, please use only one active Ethernet interface and one active wireless interface (as shown in the notes on this site). Multiple additional live adapters will likely cause operational issues.*
27 |
28 | ## Other Platforms
29 |
30 | In essence, wiperf is a series of python scripts & modules, together with a few supporting bash scripts to glue a few things together. It will likely work on other Debian-type systems, so it's worth giving it a go on other systems if you fancy tinkering around on another platform. When using the install script, install using the 'rpi' option. Let me know if you get it going on other platforms, as it will be interesting to share your experiences.
31 |
--------------------------------------------------------------------------------
/mkdocs/docs/probe_upgrade.md:
--------------------------------------------------------------------------------
1 | Title: Probe Software Upgrade
2 | Authors: Nigel Bowden
3 |
4 | # Probe Software Upgrade
5 | Periodically, new versions of wiperf code may be available to add bug-fixes and new features. The wiperf code must be upgraded from the CLI of the probe.
6 |
7 | For the WLAN Pi, it is generally recommend to use the version shipped with the WLAN Pi image, but there may be instances when there is a need to upgrade the wiperf code (e.g. in the case of a bug) before the next WLAN Pi image upgrade. The instructions for each probe type are provided below.
8 |
9 | Instructions are also provided for upgrading to the latest 'dev' release. This code will generally be "bleeding edge", so it's best to avoid this option unless directed by the code developers.
10 |
11 | ## WLAN Pi
12 |
13 | ### Upgrade To Latest Stable Release
14 |
15 | !!! Attention
16 | __Make sure your WLAN Pi is in "Classic" mode before upgrading (not wiperf mode)__
17 |
18 | To perform an upgrade of wiperf, execute the following commands on the WLAN Pi CLI:
19 |
20 | ```
21 | # perform the upgrade (probe must be connected to Internet)
22 | curl -s https://raw.githubusercontent.com/wifinigel/wiperf/main/setup.sh | sudo bash -s upgrade wlanpi
23 | ```
24 |
25 | !!! Attention
26 | __Ensure that you re-create your config.ini file using the new config.default.ini file supplied during the upgrade__
27 |
28 | ### Upgrade To Latest Dev Release
29 | Execute the following commands on the WLAN Pi CLI:
30 |
31 | ```
32 | # perform the upgrade (probe must be connected to Internet)
33 | curl -s https://raw.githubusercontent.com/wifinigel/wiperf/dev/setup.sh | sudo bash -s upgrade wlanpi
34 | ```
35 |
36 | ## Raspberry Pi
37 |
38 | ### Upgrade To Latest Stable Release
39 | Execute the following commands on the RPi CLI:
40 |
41 | ```
42 | # check the curent installed version and latest available version:
43 | sudo /usr/share/wiperf/setup.sh check_ver
44 | ```
45 |
46 | ```
47 | # perform the upgrade (probe must be connected to Internet)
48 | curl -s https://raw.githubusercontent.com/wifinigel/wiperf/main/setup.sh | sudo bash -s upgrade rpi
49 | ```
50 |
51 | !!! Attention
52 | __Ensure that you re-create your config.ini file using the new config.default.ini file supplied during the upgrade__
53 |
54 | ### Upgrade To Latest Dev Release
55 | Execute the following commands on the RPi CLI:
56 |
57 | ```
58 | # perform the upgrade (probe must be connected to Internet)
59 | curl -s https://raw.githubusercontent.com/wifinigel/wiperf/dev/setup.sh | sudo bash -s upgrade rpi
60 | ```
--------------------------------------------------------------------------------
/mkdocs/docs/quickstart.md:
--------------------------------------------------------------------------------
1 | Title: Quickstart
2 | Authors: Nigel Bowden
3 |
4 | # Quickstart Guide
5 |
6 | 
7 |
8 | Wiperf is a utility that can be installed on a [WLAN Pi](https://wlan-pi.github.io/wlanpi-documentation/) or a Raspberry Pi to act as a network probe that runs a series of network performance tests. It is primarily intended to provide an indication of the end-user experience on a wireless network, but may also be used as an ethernet-connected probe.
9 |
10 | Wiperf is a powerful solution, but it is not trivial to setup and configure. Here is a quickstart guide to outline the component parts and knowledge you'll need to get wiperf going.
11 |
12 | __What it is:__
13 |
14 | - an open source engineering tool that runs a set of network tests and reports in to a separate reporting tool (Splunk or Grafana) that is not part of the wiperf project.
15 | - Wiperf is *only* a probe that runs a series of network tests and makes data available to other tools.
16 |
17 | __What it isn't:__
18 |
19 | - An Enterprise quality/scale network monitoring tool
20 | - A reporting tool
21 | - A cheap way of providing Enterprise-wide UX monitoring
22 |
23 | __Skills You'll Need:__
24 | You will need to be comfortable with the following items to get wiperf going:
25 |
26 | - Using SBC devices like the RPi and WLAN Pi (including burning images & getting on their CLI)
27 | - Basic Linux administration skills (including editing files on the CLI, running scripts, updating/adding packages)
28 |
29 | __Building a Probe:__
30 | You'll need to build the probe from scratch, which may include burning images on to an SD card, a variety of Linux operations such as adding new packages and performing administrative tasks such as setting the hostname, network configuration details and the timezone.
31 |
32 | Once the basic probe is built, you will then download the wiperf code using an automated script and configure its operation using a CLI text editor.
33 |
34 | __Reporting:__
35 | As stated previously, wiperf __is not__ a reporting platform. It has been designed to send data to a reporting platform (that you build yourself, separately) such as Splunk or Grafana.
36 |
37 | Details are provided to "get you going" with the reporting platform, but these platforms are not part of this project and detailed customization of these platforms and supporting them is outside of the wiperf project. No support will be provided for these platforms besides the basic report templates that are provided on a best-efforts basis.
38 |
39 | Remember, wiperf is a UX network probe - analyzing the data it provides is your responsibility.
40 |
41 | __Documentation:__
42 | I have created a wide range of documentation to help you to get your wiperf probe going, together with the basics of setting up a suitable reporting platform. Please take time to read through this documentation before reaching out for support.
43 |
44 | I recommend that you start [here](operation.md) and work sequentially though the [documentation provided](operation.md).
45 |
46 |
--------------------------------------------------------------------------------
/mkdocs/docs/reference_doc_caching.md:
--------------------------------------------------------------------------------
1 | Title: Results Data Caching
2 | Authors: Nigel Bowden
3 |
4 | # Results Data Caching
5 |
6 | !!! Note
7 | __New in V2.1__
8 |
9 | There were a number of requests from folks for results data to be made available on the local file system of the wiperf probe, in addition to being forwarded to a reporting platform. To meet these requests, results caching has been implemented.
10 |
11 | This feature is disabled by default, but when enabled all test results are stored on the local file system in either CSV or JSON format. To limit the amount of local file storage consumed, a maximum age limit is configured to age-out older date and prevent the local file system filling up. Note that test results are still sent to the configured reporting platform when caching is enabled.
12 |
13 | The data files are stored in the local directory `/var/cache/wiperf` for a configurable period of time (*3 days by default*).
14 |
15 | A new day-specific directory is created each day, with a data file for each test type being run (example folder listing below):
16 |
17 | ```
18 | root@rpi3a:/var/cache/wiperf/2021-01-15# ls -l
19 | total 40
20 | -rw-r--r-- 1 root root 98 Jan 15 21:12 wiperf-dhcp.csv
21 | -rw-r--r-- 1 root root 279 Jan 15 21:11 wiperf-dns.csv
22 | -rw-r--r-- 1 root root 472 Jan 15 21:11 wiperf-http.csv
23 | -rw-r--r-- 1 root root 252 Jan 15 21:12 wiperf-iperf3-tcp.csv
24 | -rw-r--r-- 1 root root 255 Jan 15 21:12 wiperf-iperf3-udp.csv
25 | -rw-r--r-- 1 root root 512 Jan 15 21:11 wiperf-network.csv
26 | -rw-r--r-- 1 root root 616 Jan 15 21:11 wiperf-ping.csv
27 | -rw-r--r-- 1 root root 634 Jan 15 21:12 wiperf-poll-status.csv
28 | -rw-r--r-- 1 root root 451 Jan 15 21:12 wiperf-smb.csv
29 | -rw-r--r-- 1 root root 484 Jan 15 21:11 wiperf-speedtest.csv
30 | ```
31 |
32 | The day-specific folder (and all of its data) is removed once its age exceeds the defined age-out threshold.
33 |
34 | If only subset of results need to be cached, then they can be filtered using the `cache_filter` [configuration field](config.ini.md#cache_filter).
35 |
36 | ## Configuration
37 |
38 | This feature is enabled and configured via the usual wiperf configuration file: `/etc/wiperf/config.ini`. The relevant section of the file is shown below:
39 |
40 | ```
41 | ; ====================================================================
42 | ; General settings - any changes to this section should only be
43 | ; made when in classic mode (not while in wiperf mode) on the WLAN Pi
44 | ; ====================================================================
45 | [General]
46 | ;
47 | ; !!!!!!!!!!!!!!!!! SNIP !!!!!!!!!!!!!!!!!!!!!!!!!!!
48 | ;
49 | ; ----------- Caching Parameters -------------
50 | ; Results data may be cached in the local file system
51 | ; of the probe for later inspection or retrieval by
52 | ; user defined methods. By default, files are stored
53 | ; in: /var/cache/wiperf
54 | ;
55 | ; Enable/disable local file caching (yes or no)
56 | cache_enabled: no
57 | ; Format of local cache files (csv or json)
58 | cache_data_format: csv
59 | ; Number of days of data that will be retained
60 | ; local cache files
61 | cache_retention_period: 3
62 | ; data source filter (e.g. to cache only http & ping data: wiperf-http, wiperf-ping)
63 | cache_filter:
64 | ;---------------------------------------------
65 | ```
66 |
67 | Each of the configuration parameters are detailed in the [config.ini reference document](config.ini.md#cache_enabled).
68 |
69 | Note that this data cannot be exported to a reporting server, it is only provided for local inspection or remote retrieval by some other user-defined method.
70 |
71 | ## Example Output
72 |
73 | Here is a very brief sample of output data in CSV format for ping tests:
74 | ```
75 | root@rpi3a:/var/cache/wiperf/2021-01-15# cat wiperf-ping.csv
76 | time,ping_index,ping_host,pkts_tx,pkts_rx,percent_loss,test_time_ms,rtt_min_ms,rtt_avg_ms,rtt_max_ms,rtt_mdev_ms
77 | 1610744198240,1,google.com,10,10,0,21,16.4,22.12,35.05,5.25
78 | 1610744207526,2,cisco.com,10,10,0,22,132.56,139.05,157.93,7.84
79 | 1610744497522,1,google.com,10,10,0,22,17.2,21.42,37.68,5.86
80 | 1610744506813,2,cisco.com,10,10,0,22,132.64,155.31,297.98,47.96
81 | 1610744798459,1,google.com,10,10,0,22,18.2,22.38,33.54,4.92
82 | 1610744807743,2,cisco.com,10,10,0,22,132.23,138.41,158.16,8.22
83 | ```
84 |
--------------------------------------------------------------------------------
/mkdocs/docs/reference_doc_librespeed.md:
--------------------------------------------------------------------------------
1 | Title: Librespeed Speedtest
2 | Authors: Nigel Bowden
3 |
4 | # Librespeed Speedtest
5 |
6 | !!! Note
7 | __New in V2.1__
8 |
9 | !!! Attention
10 | Make sure you checkout the ["Known Issues"](#known-issues) section at the end of this page
11 |
12 | In addition to performing a speedtest using the public Ookla service, it is now possible to add support for performing speedtesting to [Librespeed](https://librespeed.org/) servers.
13 |
14 | One useful point to note is that in addition to testing against public Librespeed servers,it is also possible to test against your own instance of the Librespeed server. This allows testing within your own environment, without hitting the Internet (and associated bottlenecks)
15 |
16 | Switching between using Ookla and Librespeed is achieved by modifying the `provider` parameter in the [Speedtest] section of config.ini:
17 |
18 | ```
19 | ; ====================================================================
20 | ; Speedtest test settings
21 | ; (Changes made in this section will be used in next test cycle
22 | ; and may be made while in Wiperf mode on the WLANPi)
23 | ; ====================================================================
24 | [Speedtest]
25 | ; yes = enabled, no = disabled
26 | enabled: yes
27 | ;
28 | ; Speedtest provider valid options: ookla or librespeed
29 | provider: librespeed
30 | ;
31 | ; Ookla:
32 | ; The server ID of a specific Ookla server taken from : https://c.speedtest.net/speedtest-servers-static.php
33 | ; Note this must be the number (NOT url!) taken from the field id="xxxxx". If not specified, best server used (default)
34 | ;
35 | ; Librespeed:
36 | ; The numeric server ID of the server listed in the avaiable servers seen by running the Librespeed CLI
37 | ; command: librespeed-cli --list
38 | ;
39 | server_id:
40 | ;
41 | ; Additional args to pass to Librespeed CLI command (e.g. --local-json /etc/wipef/localserver.json --duration 20) - Note: Librespeed only
42 | librespeed_args:
43 | ;
44 | ; If proxy server access is required to run a speedtest, enter the proxy server details here for https & https
45 | ; e.g. https_proxy: http://10.1.1.1:8080
46 | ;
47 | ; For sites that are not accessed via proxy, use no_proxy (make sure value enclosed in quotes & comma separated for mutiple values)
48 | ; e.g. no_proxy: "mail.local, intranet.local"
49 | http_proxy:
50 | https_proxy:
51 | no_proxy:
52 | ;
53 | ; ------------- Advanced settings for Speedtest section, do not change --------------
54 | ; Name used for speedtest file/data group/data source
55 | speedtest_data_file: wiperf-speedtest
56 | ;------------------------------ Speedtest Section End -------------------------------
57 | ```
58 |
59 | In addition to choosing the speedtest provider, it is also possible to choose the specific server ID that is to be used for testing, together with the option of passing additional arguments to the Librespeed test client to control its behaviour. See the inline comments in the config file extract above for more details.
60 |
61 | ## Pre-requisites - Librespeed Client
62 | The Librespeed speedtest is performed by using the client available from the client GitHub site: [client binaries](https://github.com/librespeed/speedtest-cli/releases){target=_blank}
63 |
64 | The Librespeed client is not installed by default on the WLAN Pi or RPi, so must be downloaded and installed before it can be selected as an option for use by wiperf. To install the client, you will need to SSH to the probe and perform the following steps on the CLI:
65 |
66 | ### RPi
67 | To download and install the Librespeed client on the Raspberry Pi, follow these instructions:
68 |
69 | ```
70 | # RPi librespeed install
71 | # go to your home dir
72 | cd ~
73 |
74 | # get the librespeed-cli binary for RPi
75 | wget https://github.com/librespeed/speedtest-cli/releases/download/v1.0.7/librespeed-cli_1.0.7_linux_armv7.tar.gz
76 |
77 | # extract the files
78 | tar xvzf librespeed-cli_1.0.7_linux_armv7.tar.gz
79 |
80 | # change the owner of the cli utility to root
81 | sudo chown root:root librespeed-cli
82 |
83 | # copy the cli utility to its final destination
84 | sudo cp ./librespeed-cli /usr/local/bin/
85 |
86 | # verify librespeed cli is ready to go
87 | librespeed-cli --version
88 | ```
89 |
90 | ### WLAN Pi
91 | To download and install the Librespeed client on the WLAN Pi, follow these instructions:
92 |
93 | ```
94 | # WLAN Pi librespeed install
95 | # go to your home dir
96 | cd ~
97 |
98 | # get the librespeed-cli binary for RPi
99 | wget https://github.com/librespeed/speedtest-cli/releases/download/v1.0.7/librespeed-cli_1.0.7_linux_arm64.tar.gz
100 |
101 | # extract the files
102 | tar xvzf librespeed-cli_1.0.7_linux_arm64.tar.gz
103 |
104 | # change the owner of the cli utility to root
105 | sudo chown root:root librespeed-cli
106 |
107 | # copy the cli utility to its final destination
108 | sudo cp ./librespeed-cli /usr/local/bin/
109 |
110 | # verify librespeed cli is ready to go
111 | librespeed-cli --version
112 | ```
113 |
114 | ## Known Issues
115 |
116 | There is a known issue on some platforms where librespeed will not run without specifying a specific server ID - this seems to be an issue with ping in Go (the language the client is written in). (*This has been seen on the WLAN Pi*)
117 |
118 | To see a list of servers to pick an ID to test against, run the following command to get a list of available servers:
119 |
120 | ```
121 | librespeed-cli --list
122 | ```
123 | Enter the chosen server numeric ID in the `server_id:` field of config.ini
--------------------------------------------------------------------------------
/mkdocs/docs/reference_doc_smb.md:
--------------------------------------------------------------------------------
1 | Title: SMB/CIFS Test
2 | Authors: Nigel Bowden
3 |
4 | # SMB/CIFS Test
5 |
6 | !!! Note
7 | __New in V2.1__
8 |
9 | The SMB/CIFS benchmarking test performs a simple copy of a file from a server to the local wiperf host. This may be useful to simulate a standard Windows file copy from a server.
10 |
11 | Once each test is completed, data is reported that shows the file copied, the transfer time and the data rate achieved. Note that transfers that take longer than one minute will time out, so please consider this when setting up tests.
12 |
13 | Up to 5 tests may be performed during each wiperf poll cycle. For each test, the following information must be configured:
14 |
15 | * smb_host: name of IP of he remote server
16 | * smb_username: username for login credentials on remote server
17 | * smb_password: password for login credentials on remote server
18 | * smb_path: the shared remote server path
19 | * smb_filename: the remote file to be copied during the test
20 |
21 | (See the following reference document for more detailed configuration information: [config.ini](config.ini.md#smb_test-section)
22 |
23 | ## Pre-requisites
24 |
25 | As the SMB/CIFS test suite is an optional test module, some prerequisite linux packages may be missing from your wiper probe software (both WLAN Pi and RPi).
26 |
27 | To ensure that you have the required packages on your wiper probe, please run the following commands:
28 |
29 | ```
30 | sudo apt-get update
31 | sudo apt-get install cifs-utils
32 | ```
33 |
34 | If you get a message advising that `cifs-utils` is already installed, do not worry.
35 |
36 | ## Configuration
37 |
38 | Once the pre-requisite packages are installed, as with all other wiperf tests, please configure the relevant section of the wiperf probe `/etc/wiperf/config.ini` file. Please visit this document for detail information about the configuration options: [config.ini](config.ini.md#smb_test-section))
39 |
40 |
41 | ## General SMB Testing (Supplementary Info)
42 | If you are not too familiar with using SMB/CIFS file shares and would like to set up and perform your own testing (e.g. in your lab), here are some useful notes on setting up a basic SMB server and client using some test Linux devices. __Note:__ *these are unsupported reference notes which may/may not be helpful to you.*
43 |
44 | __Server side (Linux server):__
45 |
46 | 1. Install samba: sudo apt-get update && sudo apt-get install samba
47 | 2. Create samba account to access share:
48 | ```
49 | sudo userdd smbuser
50 | sudo smbpasswd -a smbuser
51 | ```
52 | 3. Create dir to be shared (adjust this for your user account - 'wlanpi' usr account used in this example)
53 | ```
54 | sudo mkdir /home/wlanpi/share
55 | sudo chown wlanpi:wlanpi /home/wlanpi/share
56 | ```
57 | 4. Edit smb.conf to add share:
58 | ```
59 | sudo nano /etc/samba/smb.conf
60 |
61 | # Add this to end of smb.conf - adjust path for your instance
62 | [shared]
63 | path = /home/wlanpi/share
64 | available = yes
65 | valid users = smbuser
66 | read only = no
67 | create mask = 0755
68 | browsable = yes
69 | public = yes
70 | writable = yes
71 | ```
72 | 5. Restart samba:
73 | ```
74 | systemctl restart smbd
75 | systemctl status smbd
76 | # make sure our firewall doesn't get in the way (if installed)
77 | # ** do not leave firewall disabled!!! **
78 | ufw disable
79 | ```
80 | __Client side (WLAN Pi/RPi):__
81 |
82 | 1. Install cifs-utils: : sudo apt-get update && sudo apt-get install cifs-utils
83 |
84 | 2. Create local mount point:
85 | ```
86 | mkdir /tmp/share
87 | ```
88 | 3. Mount the remote volume - adjust IP address for your remote server(s):
89 | ```
90 | /sbin/mount.cifs //192.168.0.52/shared /tmp/share -o user=smbuser,pass='smbuser'
91 | /sbin/mount.cifs //192.168.0.193/shared /tmp/share -o user=smbuser,pass='smbuser'
92 | ```
93 | 4. Copy a file from the remote mount:
94 | ```
95 | /bin/cp -f /tmp/share/file.txt ~/.
96 | ```
97 | 5. Unmount volume:
98 | ```
99 | /bin/umount /tmp/share
100 | ```
101 |
--------------------------------------------------------------------------------
/mkdocs/docs/splunk_configure.md:
--------------------------------------------------------------------------------
1 | Title: Splunk Configuration
2 | Authors: Nigel Bowden
3 |
4 | # Splunk Configuration
5 | 
Now that we have a Splunk server setup, we need to customize it to report our probe data. The steps required are all via the Splunk web GUI and are the same for all OS flavours.
6 |
7 | ## Configure Data Input To Splunk
8 | We need to tell Splunk how we’ll be sending the data from our probe in to Splunk. We need to configure a data input that will prepare Splunk to receive the data, and to generate an authorization key to be used by the probe when sending its results data.
9 |
10 | ### Log In To Splunk
11 | The first step is to login to Splunk using the credentials created during the Splunk install. The URL to use is:
12 |
13 | ```
14 | http://:8000
15 | ```
16 |
17 | ### Configure HTTP Event Collector Global Options
18 | After login, the following page will be seen:
19 |
20 | 
21 |
22 | Follow the “Settings > Data > Data Inputs” menu options :
23 |
24 | 
25 |
26 | Click on the HTTP Event Collector link in the Data Inputs page shown:
27 |
28 | 
29 |
30 | 
31 |
32 |
33 | Click on the “Global Settings” button as indicated in the graphic above to reveal the global configuration panel for the HTTP Event Collector:
34 |
35 | 
36 |
37 | Ensure the panel is configured to look like the example shown above. This should require the following steps:
38 |
39 | - __Make sure you hit the All Tokens > Enabled button__ (this is disabled by default which stops everything working)
40 | - Default Source Type: Structured > _json
41 | - Hit: Save to take you back to the HTTP Event Collector page
42 |
43 | ###Create a HEC Token
44 | After returning to the HTTP Event Collector page, hit the __New Token__ button. This will start a token creation wizard.
45 |
46 | 
47 |
48 | Enter a name for the token (probe HEC Token) then hit __Next__ > :
49 |
50 | 
51 |
52 | In the next wizard panel select Source type: __Select > Structured > _json__ :
53 |
54 | 
55 |
56 | Scroll down to the indexes and make the following selections:
57 |
58 | - Select Allowed Indexes > __add all__
59 | - Default Index : __main__
60 |
61 | Next, hit the __Review__ > button:
62 |
63 | 
64 |
65 | The token review panel is now should and should look like the graphic below. Finally hit the __Submit>__ button:
66 |
67 | 
68 |
69 | A final confirmation message will be provided as shown below:
70 |
71 | 
72 |
73 | If you return to __Settings > Data Input > HTTPS Event Collector__, you will now see the token your probe will need to communicate with the Splunk server:
74 |
75 | 
76 |
77 | At this point, the Splunk server is ready to receive data from the probe. Ensure that your probe has been configured with the correct server IP address, port number and the token we have just created above (copy and paste the “Token Value” in to your probe config.ini file).
78 |
79 | If using the WLAN Pi, ensure that it is flipped in to wiperf mode. On the RPI, ensure that the required cron job has been configured to start polling.
80 |
81 | ### Perform a Test Search
82 | After a few minutes, when the probe has run a test cycle, data should start to appear in Splunk. The quickest way to check is to do a general search for data in Splunk and see what is being received. Go to __“Apps : Search & Reporting > Search & Reporting”__ (top menu bar) and enter a “*” in the __“New Search”__ text box. Results data should be seen as shown below:
83 |
84 | 
85 |
86 | If your search result looks like this (no results found message), then you need to wait a little longer for data to arrive, or there is likely a comms problem between your probe and Splunk:
87 |
88 | 
89 |
90 | ## Create a Dashboard
91 | Now that we have data arriving at our Splunk server, we need to view the data in an interesting format. Splunk allows us to create reporting dashboards to visualize our data. We will now create a simple dashboard to demonstrate the visualization capabilities.
92 |
93 | In the probe’s ```/usr/share/wiperf/dashboards``` directory, a number of pre-canned dashboard files have been provided to allow a simple copy & paste operation to create a dashboard. These files are also available on the GitHub page of the wiperf project:
94 |
95 | - [https://github.com/wifinigel/wiperf/tree/main/dashboards](https://github.com/wifinigel/wiperf/tree/main/dashboards){target=_blank}
96 |
97 | Use an SFTP client to pull the __“01 - probe_summary.xml”__ file from your probe, or open the file on the GitHub page and select “Raw” to copy and paste the code in to a local file on your laptop.
98 |
99 | In the Splunk GUI, go to __“Apps : Search & Reporting > Search & Reporting”__ (top menu bar) and hit the __“Dashboards”__ link:
100 |
101 | 
102 |
103 | Hit the __"Create New Dashboard"__ button:
104 |
105 | 
106 |
107 | In the pop-up panel, enter a dashboard name and hit the __"Create Dashboard"__ button:
108 |
109 | 
110 |
111 | In the __“Edit Dashboard”__ panel that opens, hit the __“Source”__ button:
112 |
113 | 
114 |
115 | By default, some basic XML configuration will exist in the dashboard definition:
116 |
117 | 
118 |
119 | Open up the dashboard definition file previously downloaded from your probe or the GitHub site in a text editor. Then simply paste in the code as shown below (make sure the original code was all removed):
120 |
121 | 
122 |
123 | After hitting the __Save__ button, the dashboard will now be shown:
124 |
125 | 
126 |
127 | Using the hostname and time period selector above the graphs, different probes and reporting periods may be viewed.
128 |
129 | The process above may be repeated using each of the xml files found in the dashboards folder to create a series of separate dashboards that focus on different aspects of data available using wiperf.
130 |
--------------------------------------------------------------------------------
/mkdocs/docs/splunk_install.md:
--------------------------------------------------------------------------------
1 | Title: Splunk Installation
2 | Authors: Nigel Bowden
3 |
4 | # Splunk Installation
5 | 
Once the software is downloaded, follow the instructions that are appropriate for your OS in the Splunk installation manual:
6 |
7 | [https://docs.splunk.com/Documentation/Splunk/latest/Installation/Chooseyourplatform](https://docs.splunk.com/Documentation/Splunk/latest/Installation/Chooseyourplatform)
8 |
9 | The installation process for all platforms is very straightforward and is detailed in the official install guides, so will not be covered in detail here.
10 |
11 | !!! note Debian Linux
12 |
13 | When installing the Linux flavour of Splunk, make sure you do not miss the additional step required to ensure that Splunk starts after a server reboot. The following command needs to be executred after the software is installed (but please verify this isn the official installation documents):
14 |
15 | ```
16 | sudo /opt/splunk/bin/splunk enable boot-start
17 | ```
18 |
19 | Once installation has been completed, it should be possible to access the web dashboard of Splunk at the URL:
20 |
21 | ```
22 | http://:8000
23 | ```
24 |
25 | 
--------------------------------------------------------------------------------
/mkdocs/docs/splunk_platform.md:
--------------------------------------------------------------------------------
1 | Title: Splunk Platform
2 | Authors: Nigel Bowden
3 |
4 | # Splunk Platform
5 | 
To collect and view the test results data, an instance of Splunk is required (unless you choose to use [InfluxDB/Grafana](influx_platform.md)). Splunk is a flexible data collection and reporting package that can take data sent by the wiperf probe and present it in a nice report format. Splunk can be installed on a wide variety of platforms that can be viewed at : [https://www.splunk.com/en_us/download/splunk-enterprise.html](https://www.splunk.com/en_us/download/splunk-enterprise.html)
6 |
7 | This guide does not cover all installation details of the software package, these may be obtained when downloading and installing the software. Note that a free account sign-up is required when downloading the software from the link listed above.
8 |
9 | To install Splunk and use it with a handful of probes, a modest server may be built (e.g. I use a low-end Intel NUC running Ubuntu), so for testing purposes, don’t get too hung up on sourcing a high end server. If you'd like to look into server requirements further, then [check out this page](https://docs.splunk.com/Documentation/Splunk/latest/Installation/Systemrequirements).
10 |
11 | The product being installed is Splunk Enterprise. This is a paid-for product, but it has a free-tier for low data volumes (500Mbytes per day). Install initially with all the licensing defaults and then drop back to the free-tier by selecting Settings > Licensing and selecting the free tier. The free tier is plenty for the low volume rates that the wiperf probe generates when deploying probes at small-scale.
12 |
13 | !!! attention
14 |
15 | If you forget to select the free tier and your trial license expires, you may become locked out of the GUI with a “license expired” message. If this happens, from the CLI of your Splunk server, find the file “server.conf” and add the following line to the bottom of the file:
16 |
17 | ```
18 | [license]
19 | active_group = Lite_Free
20 | ```
21 |
22 | Then, restart the Splunk server and the login issue should be fixed.
23 | (The file is /opt/splunk/etc/system/local/server.conf on Linux)
24 |
25 | ## Connectivity Planning
26 | One area to consider is network connectivity between the wiperf probe and the Splunk instance. The wiperf probe needs to be able to access the Splunk server to send its results data. If the wiperf probe probe is being deployed on a wireless network, how is the results data generated going to get back to the Splunk server?
27 |
28 | If the probe is being deployed on a customer network to perform temporary monitoring, it will need to join the wireless network under test (or be plugged in to an ethernet switch port if testing a wired connection). But, how is the wiperf probe going to send its data to the Splunk server ? Many environments may not be comfortable with hooking up the wiperf probe to their internal wired network, potentially bridging wired and wireless networks. In some instances an alternative is required (e.g. send the results data over the wireless network itself out to the Internet to a cloud instance or via a VPN solution such as Zerotier.)
29 |
30 | Three topology deployment options are supported:
31 |
32 | - Results data over wireless
33 | - Results data over Ethernet
34 | - Results data over VPN/wireless
35 |
36 | The method used is configured on the wiperf probe in its config.ini file. It is important to understand the (viable) connectivity path prior to deploying both the probe and the Splunk server.
37 |
38 | The 3 connectivity options are discussed below.
39 |
40 | ### Results Data Over Wireless
41 |
42 | 
43 |
44 | In this topology the wiperf probe is configured to join an SSID that has the Splunk server accessible via its WLAN interface. Typically, the Splunk server will reside in a cloud or perhaps on a publicly accessible VPS. The wiperf probe will continually run the performance tests over the wireless connection and then upload the results directly to the Splunk server over the WLAN connection.
45 |
46 | !!! note "config.ini settings:"
47 | ```
48 | mgt_if: wlan0
49 | data_host:
50 | ```
51 |
52 | ### Results data over Ethernet
53 |
54 | 
55 |
56 | If the Splunk server is being run on the inside of a network environment, it may be preferable to return results data via the Ethernet port of the wiperf probe. This topology also has the advantage of results data not being impacted if there are wireless connectivity issues on the wiperf probe WLAN connection. To achieve the correct traffic flow, a static route for management traffic is automatically injected into the route table of the wiperf probe to force results data over the Ethernet port.
57 |
58 | !!! note "config.ini settings:"
59 | ```
60 | mgt_if: eth0
61 | data_host:
62 | ```
63 |
64 |
65 | ### Results data over Zerotier/wireless
66 |
67 | 
68 |
69 | A simple way of getting the wiperf probe talking with your Splunk server, if it has no direct access, is to use the [Zerotier](https://zerotier.com/) service to create a virtual overlay network via the Internet.
70 |
71 | In summary, both the Splunk server and wiperf probe have a [Zerotier](https://zerotier.com/) client installed. Both are then added to your Zerotier dashboard (by you) and they start talking! Under the hood, both devices have a new virtual network interface created and they connect to the [Zerotier](https://zerotier.com/) cloud-based network service so that they can communicate on the same virtual network in the cloud. As they are on the same subnet from a networking perspective, there are no routing issues to worry about to get results data from the wiperf probe to the Splunk server.
72 |
73 | [Zerotier](https://zerotier.com/) has a free subscription tier which allows up to 100 devices to be hooked up without having to pay any fees. It’s very easy to use, plus your Splunk server can be anywhere! (e.g. on your laptop at home). Both devices need access to the Internet for this solution to work.
74 |
75 | You can sign up for free, create a virtual network and then just add the IDs that are created by the Splunk server and wiperf probe when the client is installed.
76 |
77 | !!! note "config.ini settings:"
78 | ```
79 | mgt_if: ztxxxxxx (check your local ZeroTier interface designation using ```ifconfig```)
80 | data_host:
81 | ```
82 |
83 | !!! info "Install ZeroTier"
84 |
85 | To install Zerotier on the wiperf probe (or an Ubuntu server), enter the following:
86 |
87 | ```
88 | curl -s https://install.zerotier.com | sudo bash
89 | sudo zerotier-cli join
90 | sudo zerotier-cli status
91 |
92 | # To remove at a later date:
93 | sudo apt remove zerotier-one
94 | ```
95 |
--------------------------------------------------------------------------------
/mkdocs/docs/splunk_software.md:
--------------------------------------------------------------------------------
1 | Title: Splunk Software
2 | Authors: Nigel Bowden
3 |
4 | # Splunk Software
5 | 
To obtain the Splunk software for your data server, get along to the Splunk web site and sign up for an account if you don’t already have one: [https://www.splunk.com/en_us/download/splunk-enterprise.html](https://www.splunk.com/en_us/download/splunk-enterprise.html)
6 |
7 | Once you’re logged in to the Splunk site, you’ll have a number of OS options to choose from ([supported platforms can be viewed here](https://docs.splunk.com/Documentation/Splunk/latest/Installation/Systemrequirements)). There are options for Windows, Linux & Mac OS:
8 |
9 | *(Note: the version of Splunk you can download will likely be different to the version shown below - choose the latest version of 8.x)*
10 |
11 | 
12 |
13 | Once you've hit the download button for your OS choice, the Splunk Enterprise software chosen will start to download to your local machine, ready for installation.
14 |
15 | It’s worth checking the download page to see if there are further download options. If you check the graphic below, you can see there is a “Download via Command Line (wget)” option, which can be a much easier way to get the code directly on to your server.
16 |
17 | The options you will see here will vary between OS selections:
18 |
19 | *(Note: the version of Splunk you can download will likely be different to the version shown below - choose the latest version of 8.x)*
20 |
21 | 
22 |
23 |
24 |
--------------------------------------------------------------------------------
/mkdocs/docs/troubleshooting.md:
--------------------------------------------------------------------------------
1 |
2 | # Troubleshooting
3 |
4 | If things seem to be going wrong, here are a few tips to guide you in your diagnosis of the issue.
5 |
6 | ## Network Connectivity
7 |
8 | If you suspect network connectivity issues, your best course of action is to check the status of any interfaces being used by the probe. This can be done by accessing the CLI of the probe and running some of the commands provided below.
9 |
10 | Once interfaces have been verified, trying to access specific targets via network connectivity checks can also be useful.
11 |
12 | 1. The following CLI commands will help to check the status of probe interfaces:
13 | 1. Wireless NIC: ```iwconfig``` (Is the probe joining the wireless network? The SSID to which is is joined should be shown in the "ESSID" field)
14 | 2. IP address: ```ifconfig eth0```, ```ifconfig wlan0``` (Are the interfaces up? Do they have an IP address?)
15 | 2. Network connectivity to a specific host: ```ping 192.168.0.254```
16 | 3. Internet connectivity: ```ping google.com``` (Can the probe get to the Internet, if that is expected?)
17 | 4. DNS connectivity: ```apt-get install dnsutils``` (install required commands), ```nslookup google.com```
18 | 5. Web connectivity: ```wget https://google.com``` (check if the required website target can be reached from the probe)
19 | 6. iperf3 server connectivity: ```iperf3 -c 192.168.0.1 -t 10 -i 1``` (run 10 sec tcp test to 192.168.0.1 server...alter for your iperf server address)
20 | 7. Another useful source of information for connectivity issues in the syslog logging system of the probe. Take a look through the syslog file to see if there are any issues being reported that may be impacting your connectivity: ```tail -f /var/log/syslog```
21 |
22 | ## Wiperf Configuration
23 | The wiperf configuration file is quite a complex file, so it's well worth checking for typos or critical fields that have been missed. The key fields worth double checking are:
24 |
25 | - probe_mode
26 | - mgt_if
27 | - exporter_type
28 | - (splunk)
29 | - splunk_host
30 | - splunk_port
31 | - splunk_token
32 | - (influxdb)
33 | - influx_host
34 | - influx_port
35 | - influx_username
36 | - influx_password
37 | - influx_database
38 |
39 | One question to consider when deploying a probe is : Is the probe deployed in the topology you originally intended? If the environment is not as you expected and you need to use a different interface, make sure you have updated ```config.ini``` so that wiperf knows where to send test and management traffic (otherwise, you may hit routing issues)
40 |
41 | ## Logging
42 | Wiperf has extensive logging to help diagnose issues that may be causing operational issues.
43 |
44 | SSH to the probe and monitor the output of the log file ```/var/log/wiperf_agent.log```. This file is created the first time that wiperf runs. If the file is not created after 5 minutes, then check the log file ```/var/log/wiperf_cron.log``` for error messages, as something fundamental is wrong with the installation.
45 |
46 | To watch the output of ```/var/log/wiperf_agent.log``` in real-time and view activity as data is collected every 5 minutes, run the following command on the CLI of the probe:
47 |
48 | ```
49 | tail -f /var/log/wiperf_agent.log
50 | ```
51 |
52 | Every 5 minutes, new log output will be seen that look similar to this:
53 |
54 | ```
55 | 2020-07-11 11:47:04,214 - Probe_Log - INFO - *****************************************************
56 | 2020-07-11 11:47:04,215 - Probe_Log - INFO - Starting logging...
57 | 2020-07-11 11:47:04,216 - Probe_Log - INFO - *****************************************************
58 | 2020-07-11 11:47:04,240 - Probe_Log - INFO - Checking if we use remote cfg file...
59 | 2020-07-11 11:47:04,241 - Probe_Log - INFO - No remote cfg file confgured...using current local ini file.
60 | 2020-07-11 11:47:04,242 - Probe_Log - INFO - No lock file found. Creating lock file.
61 | 2020-07-11 11:47:04,243 - Probe_Log - INFO - ########## Network connection checks ##########
62 | 2020-07-11 11:47:05,245 - Probe_Log - INFO - Checking wireless connection is good...(layer 1 &2)
63 | 2020-07-11 11:47:05,246 - Probe_Log - INFO - Checking wireless connection available.
64 | 2020-07-11 11:47:05,355 - Probe_Log - INFO - Checking we're connected to the network (layer3)
65 | 2020-07-11 11:47:05,356 - Probe_Log - INFO - Checking we have an IP address.
66 | 2020-07-11 11:47:05,379 - Probe_Log - INFO - Checking we can do a DNS lookup to google.com
67 | 2020-07-11 11:47:05,406 - Probe_Log - INFO - Checking we are going to Internet on correct interface as we are in 'wireless' mode.
68 | 2020-07-11 11:47:05,430 - Probe_Log - INFO - Checked interface route to : 216.58.212.238. Result: 216.58.212.238 via 192.168.0.1 dev wlan0 src 192.168.0.48 uid 0
69 | 2020-07-11 11:47:05,431 - Probe_Log - INFO - Checking we can get to the management platform...
70 | 2020-07-11 11:47:05,432 - Probe_Log - INFO - Checking we will send mgt traffic over configured interface 'lo' mode.
71 | 2020-07-11 11:47:05,455 - Probe_Log - INFO - Checked interface route to : 127.0.0.1. Result: local 127.0.0.1 dev lo src 127.0.0.1 uid 0
72 | 2020-07-11 11:47:05,456 - Probe_Log - INFO - Interface mgt interface route looks good.
73 | 2020-07-11 11:47:05,457 - Probe_Log - INFO - Checking port connection to InfluxDB server 127.0.0.1, port: 8086
74 | 2020-07-11 11:47:05,484 - Probe_Log - INFO - Port connection to server 127.0.0.1, port: 8086 checked OK.
75 | 2020-07-11 11:47:05,485 - Probe_Log - INFO - ########## Wireless Connection ##########
76 | 2020-07-11 11:47:05,486 - Probe_Log - INFO - Wireless connection data: SSID:BNL, BSSID:5C:5B:35:C8:4D:C2, Freq:5.5, Center Freq:5.51, Channel: 100, Channel Width: 40, Tx Phy rate:200.0, Rx Phy rate:135.0, Tx MCS: 0, Rx MCS: 0, RSSI:-42.0, Tx retries:187, IP address:192.168.0.48
77 | 2020-07-11 11:47:05,486 - Probe_Log - INFO - InfluxDB update: wiperf-network, source=Network Tests
78 | 2020-07-11 11:47:05,487 - Probe_Log - INFO - Sending data to Influx host: 127.0.0.1, port: 8086, database: wiperf)
79 | 2020-07-11 11:47:05,573 - Probe_Log - INFO - Data sent to influx OK
80 | 2020-07-11 11:47:05,574 - Probe_Log - INFO - Connection results sent OK.
81 | 2020-07-11 11:47:05,595 - Probe_Log - INFO - ########## speedtest ##########
82 | 2020-07-11 11:47:05,597 - Probe_Log - INFO - Starting speedtest...
83 | 2020-07-11 11:47:06,599 - Probe_Log - INFO - Checking we are going to Internet on correct interface as we are in 'wireless' mode.
84 | 2020-07-11 11:47:06,623 - Probe_Log - INFO - Checked interface route to : 8.8.8.8. Result: 8.8.8.8 via 192.168.0.1 dev wlan0 src 192.168.0.48 uid 0
85 | 2020-07-11 11:47:06,624 - Probe_Log - INFO - Speedtest in progress....please wait.
86 | 2020-07-11 11:47:28,761 - Probe_Log - INFO - ping_time: 31, download_rate: 41.56, upload_rate: 9.74, server_name: speedtest-net5.rapidswitch.co.uk:8080
87 | 2020-07-11 11:47:28,766 - Probe_Log - INFO - Speedtest ended.
88 | 2020-07-11 11:47:28,767 - Probe_Log - INFO - InfluxDB update: wiperf-speedtest, source=Speedtest
89 | 2020-07-11 11:47:28,768 - Probe_Log - INFO - Sending data to Influx host: 127.0.0.1, port: 8086, database: wiperf)
90 | 2020-07-11 11:47:28,858 - Probe_Log - INFO - Data sent to influx OK
91 | 2020-07-11 11:47:28,860 - Probe_Log - INFO - Speedtest results sent OK.
92 | ```
93 |
94 | The output is quite verbose and detailed, but it will provide a good indication of where wiperf is having difficulties.
95 |
96 | ## Miscellaneous Checks
97 |
98 | ### NTP / Time Sync
99 | Make sure your probe and reporting server are time synchronized and are showing the same data and time. Check the time and date of the probe using the CLI command `date`. If your probe and reporting server are in different timezones, check the UTC time on both to make sure you are comparing apples with apples: `date -u`
100 |
101 | The WLAN Pi and RPi will generally synchronized to a time source out of the box using a process such as Chrony or NTP, so will not need any specific intervention. However, if they do not have access to the Internet, the synchronization process may be compromised and may need you to [manually configure time sources](https://pimylifeup.com/using-ntp-on-linux-with-chrony/){target=_blank}.
102 |
103 | ### Hostname
104 | If you have changed the probe hostname from its default, make sure you have updated both the `/etc/hosts` **AND** the `/etc/hostname` files with the new name (if done incorrectly, this can cause some very weird issues!)
105 |
106 |
107 |
--------------------------------------------------------------------------------
/mkdocs/docs/whats_new_v2.1.md:
--------------------------------------------------------------------------------
1 | Title: What's New in version 2.1
2 | Authors: Nigel Bowden
3 |
4 | # What's New in version 2.1
5 |
6 | 
7 |
8 | *17th January 2021 - Author: Nigel Bowden*
9 | Version 2.1 of the wiperf probe code introduces a number of bug-fixes and features. These are outlined below:
10 |
11 | ## New Features
12 |
13 | ### SMB Tests
14 | Thanks to the kind contribution of [Mario Gingras](https://twitter.com/gingmar){target=_blank}, wiperf now supports performance testing of SMB/CIFS file transfers.
15 |
16 | Up to 5 tests may be defined to be run in each wiperf poll cycle. Each test instance will mount a remote volume and then transfer a file from the remote server to the wiperf probe. The transfer rate and time are then reported to the management platform for reporting.
17 |
18 | A new dashboard is also provided to display the SMB data in report format.
19 |
20 | If using the SMB tests, note that there are a small number of additional Linux packages that you may need to install to provide the SMB connectivity. Please check out the link provided below for more details.
21 |
22 | Further information: [SMB Tests Reference Document](reference_doc_smb.md)
23 |
24 | ### Librespeed Speedtest Support
25 | An idea for Librespeed speedtest support by wiperf was submitted by Oscar Leal. This has now been added, meaning that wiperf can now run a speedtest to either Ookla or Librespeed for performance testing.
26 |
27 | In addition to testing against public Librespeed servers,it is also possible to test against your own instance of the Librespeed server, allowing testing within your own environment, without hitting the Internet (and associated bottlenecks)
28 |
29 | If using the Librespeed speedtest, note that there an additional Linux package that you will need to install to enable the test to work. Please check out the link provided below for more details.
30 |
31 | Further information: [Librespeed Reference Document](reference_doc_librespeed.md)
32 |
33 | ### Results Spooling
34 | Tris Kipling is a keen supporter of the wiperf project and, based on is experience of using wiperf probes, suggested that some mechanism be created to allow a degree of "survivability" for instances when communications between the probe and management platform are down.
35 |
36 | To address this request, a spooling mechanism for results data is now provided. Previously, if the probe was unable to communicate with the management server, no tests would be attempted during the current poll cycle. With the new spooling feature, tests will still be performed by the probe and results data will be locally stored. The data will be forwarded by the probe when communications with the management platform is re-established (and any local data spool files removed).
37 |
38 | This feature is enabled by default so required no additional configuration. It may be disabled if required.
39 |
40 | ### Results Data Caching
41 | Due to a couple of requests for local storage of results data, local results caching has been implemented.
42 |
43 | When this is enabled, all results data is stored in either CSV or JSON format in local storage on the wiperf probe (in addition to being sent to the reporting server). The data files are stored in the local directory `/var/cache/wiperf` for a configurable period of time (3 days by default).
44 |
45 | This feature allows for other methods of data inspection or retrieval that users may choose to perform. It is disabled by default.
46 |
47 | (Note: This is a completely separate feature from the data spooling feature mentioned previously))
48 |
49 | Further information: [Results Caching Reference Document](reference_doc_caching.md)
50 |
51 | ### Error Reporting
52 | Diagnosing issues with probe tests may be difficult without remote access to a probe for further investigation. To assist with looking at issues, error messages generated by the probe during its test cycle are now available for reporting back to the reporting platform.
53 |
54 | This feature is enabled by default, but may be disabled if there are concerns about volumes of management traffic from the probe. There is also a configuration setting to allow the number of error messages per poll cycle to be capped (5 by default).
55 |
56 | A new "Probe Health" dashboard has been provided to allow viewing of error messages.
57 |
58 | ## Installing
59 | Installation is not required for the WLAN Pi as wiperf is included in the WLAN Pi packages. To upgrade, see the next section.
60 |
61 | To install on to an RPi (or other platform), see our [installation document](probe_install.md).
62 |
63 | ## Upgrading
64 | To upgrade from a previous release of wiperf, please consult these instructions in our [upgrade document](probe_upgrade.md).
65 |
66 | !!! Attention
67 | * Don't forget to also update your management platform dashboard files to make sure you have the latest & greatest that are compatible with this release
68 | * [Splunk link](splunk_configure.md#create-a-dashboard)
69 | * [Grafana link](grafana_configure.md#adding-wiperf-dashboards)
70 | * When upgrading on the WLAN Pi *make sure your WLAN Pi is in classic mode prior to upgrading*
71 | * Make sure you are aware of [this advisory](#ping-issue) about existing ping test results when moving to version 2.1
72 | * Several new options have been added to config.ini - see the note below to make sure you don't miss out on them.
73 |
74 |
75 | !!! Attention
76 | __Ensure that you re-create your config.ini file using the new config.default.ini file supplied during the upgrade__
77 |
78 | Several new options have been added to the `config.ini` configuration file. Use the new `config.default.ini` file in `/etc/wiperf` as a template to create a new copy of `config.ini`. Wiperf will not run if some of the new configuration sections are missing.
79 |
80 | Copy across your existing settings in to the new copy of `config.ini`. For example:
81 |
82 | ```
83 | # after upgrade
84 | cd /etc/wiperf
85 |
86 | # backup existing config file
87 | sudo cp config.ini config.ini.orig
88 |
89 | # create new config file from template
90 | sudo cp config.defaut.ini config.ini
91 |
92 | # view old config file
93 | cat config.ini.orig
94 |
95 | # edit new file to transpose old config settings
96 | sudo nano config.ini
97 | ```
98 |
99 | ## Release Notes
100 |
101 | 1. Added fix for bad read of remote config file when downloaded (thanks Ben Roeder)
102 | 2. Fixed bad config variable names for InfluxDB2 in config.py (thanks Konstantin - issue #1)
103 | 3. Added SMB tests provided by Mario Gingras
104 | 4. Improved route injection for tests when required interface not selected by default routing
105 | 5. Fixed issue with incorrect data types in Influx DB for ping tests (some numeric values were created
106 | as strings, preventing calculations on their values.)
107 |
108 | __This fixed issue will cause failures for ping test results on existing data. To correct the issue,
109 | existing ping test data in the Influx DB must be dropped using the following command in the InfluxDB
110 | CLI utility:__
111 | ```
112 | sudo influx -username admin -password letmein
113 | use wiperf
114 | drop series from "wiperf-ping"
115 | ```
116 |
117 | 6. Added support for librespeed to speedtest in addition to existing Ookla support. Also
118 | made more data points available to reports including latency, jitter & data volume for
119 | upload/download
120 | 7. Added support for cached data : data may now be cached locally for retrieval and inspection
121 | by user-defined means (e.g. SSH to probe & inspect data). Data may be stored in VSC or JSON
122 | format.
123 | 8. Added result spooling support. If connectivity between the probe and reporting platform is
124 | lost, results may be spooled to a local directory and automatically forwarded when connectivity
125 | is re-established.
126 | 9. Added support for forwarding of probe error messages to reporting platform to allow diagnosis
127 | of test related issues on the probe.
128 | 10. Fixed DHCP test errors on RPi reported/fixed by Ben Roeder (Issue #39)
129 | 11. Fixed re-read of config file from github reported/fixed by Ben Roeder (PR #7)
130 | 12. Added new dashboard for SMB tests
131 | 13. Updated summary dashboard to support new SMB tests
132 | 14. Updated speedtest dashboard to support librespeed and additional data points
133 | 15. Added dashboard for probe health, which include probe poll error messages
134 | 16. Miscellaneous minor dashboard improvements/fixes
135 |
136 |
137 |
138 |
139 |
--------------------------------------------------------------------------------
/mkdocs/docs/whats_new_v2.2.md:
--------------------------------------------------------------------------------
1 | Title: What's New in version 2.2
2 | Authors: Nigel Bowden
3 |
4 | # What's New in version 2.2
5 |
6 | 
7 |
8 | *27th January 2021 - Author: Nigel Bowden*
9 | Version 2.2 of the wiperf probe code follows hot on the heels of v2.1, following several requests from the community for removal of limitations on the number of test targets for several of the tests performed by wiperf. Previously, the Ping, HTTP, DNS and SMB tests were limited to 5 test targets. In v2.2, these limits are removed and the number of test targets is now user defined.
10 |
11 | ---
12 |
13 | __Note: Please make sure you review the [v2.1 release notes](whats_new_v2.1.md) if you're jumping straight from v2.0 to v2.2__
14 |
15 | ---
16 |
17 | ## Ping Tests
18 |
19 | The ping tests section of config.ini is now structured as shown below:
20 |
21 | ```
22 | ; ====================================================================
23 | ; Ping tests settings
24 | ; (Changes made in this section will be used in next test cycle
25 | ; and may be made while in Wiperf mode on the WLANPi)
26 | ; ====================================================================
27 | [Ping_Test]
28 | ; yes = enabled, no = disabled
29 | enabled: yes
30 | ;
31 | ; Number of targets we'd like to ping
32 | ping_targets_count: 2
33 | ; first host we'd like to ping
34 | ping_host1: google.com
35 | ;
36 | ; second host we'd like to ping
37 | ping_host2: cisco.com
38 | ;
39 | ; add more ping targets to match your "ping_targets_count" value
40 | ; ping_host3:
41 | ; ping_host4:
42 | ; ping_host5:
43 | ; ping_host6:
44 | ;....etc
45 | ;
46 | ; number of pings to send per test
47 | ping_count: 10
48 | ;
49 | ; Timeout value for pings (in secs)
50 | ping_timeout: 1
51 | ;
52 | ; Interval between pings (in secs)
53 | ping_interval: 0.2
54 | ;
55 | ; ------------ Advanced settings for Ping tests section, do not change -------------
56 | ; Name used for ping_test file/data group/data source
57 | ping_data_file: wiperf-ping
58 | ;-------------------------------- Ping Section End ---------------------------------
59 | ```
60 |
61 | Note the new `ping_targets_count` field which allows the number of ping targets to be user-defined. Note that additional `ping_host` entries need to be added to correspond with the number of targets specified.
62 |
63 | Also new for v2.2 are the `ping_timeout` and `ping_interval` fields. These allow for the optimization of ping testing and prevent long delays when pinging large numbers, or poorly performing targets.
64 |
65 | ## DNS Tests
66 |
67 | The number of DNS tests that are performed during a poll cycle may now be user-defined, rather than being limited to 5 test entries. A new field within config.ini : `dns_targets_count` provides the count of the number of tests to be performed.
68 |
69 | Additionally, as many `dns_target` entries as required may be added to match up with the number of targets defined.
70 |
71 | See the extract from the new config.ini template file below showing the new options:
72 |
73 | ```
74 | ; ====================================================================
75 | ; DNS tests settings
76 | ; (Changes made in this section will be used in next test cycle
77 | ; and may be made while in Wiperf mode on the WLANPi)
78 | ; ====================================================================
79 | [DNS_test]
80 | ; yes = enabled, no = disabled
81 | enabled: yes
82 | ;
83 | ; Number of DNS targets we'd like to test
84 | dns_targets_count: 2
85 | ;
86 | ; First DNS target
87 | dns_target1: google.com
88 | ;
89 | ; Second DNS target
90 | dns_target2: cisco.com
91 | ;
92 | ; add more DNS targets to match your "dns_targets_count" value
93 | ; dns_target3:
94 | ; dns_target4:
95 | ; dns_target5:
96 | ; dns_target6:
97 | ;....etc
98 | ;
99 | ; ------------ Advanced settings for DNS tests section, do not change --------------
100 | ; Name used for dns_test file/data group/data source
101 | dns_data_file: wiperf-dns
102 | ;-------------------------------- DNS Section End ----------------------------------
103 | ```
104 |
105 | ## HTTP Tests
106 |
107 | The number of HTTP tests that are performed during a poll cycle may now be user-defined, rather than being limited to 5 test entries. A new field within config.ini : `http_targets_count` provides the count of the number of tests to be performed.
108 |
109 | Additionally, as many `http_target` entries as required may be added to match up with the number of targets defined.
110 |
111 | See the extract from the new config.ini template file below showing the new options:
112 |
113 | ```
114 | ; ====================================================================
115 | ; HTTP tests settings
116 | ; (Changes made in this section will be used in next test cycle
117 | ; and may be made while in Wiperf mode on the WLANPi)
118 | ; ====================================================================
119 | [HTTP_test]
120 | ; yes = enabled, no = disabled
121 | enabled: yes
122 | ;
123 | ; Number of HTTP targets we'd like to test
124 | http_targets_count: 2
125 | ;
126 | ; First HTTP target
127 | http_target1: https://google.com
128 | ;
129 | ; Second HTTP target
130 | http_target2: https://cisco.com
131 | ;
132 | ; add more HTTP targets to match your "http_targets_count" value
133 | ; http_target3:
134 | ; http_target4:
135 | ; http_target5:
136 | ; http_target6:
137 | ;....etc
138 | ;
139 | ; -------------- Advanced settings for HTTP tests section, do not change ----------------
140 | ; Name used for http_test file/data group/data source
141 | http_data_file: wiperf-http
142 | ;-------------------------------- HTTP Section End ---------------------------------
143 | ```
144 |
145 | ## SMB Tests
146 |
147 | The number of SMB tests that are performed during a poll cycle may now be user-defined, rather than being limited to 5 test entries. A new field within config.ini : `smb_targets_count` provides the count of the number of tests to be performed.
148 |
149 | Additionally, as many SMB entries as required may be added to match up with the number of targets defined. This will require the creation of an `smb_host1`,
150 | `smb_username`, `smb_password`, `smb_path` and `smb_filename` field for each target (see examples below)
151 |
152 | See the extract from the new config.ini template file below showing the new options:
153 |
154 | ```
155 | ; ====================================================================
156 | ; SMB tests settings
157 | ; (Changes made in this section will be used in next test cycle
158 | ; and may be made while in Wiperf mode on the WLANPi)
159 | ; ====================================================================
160 | [SMB_test]
161 | ; yes = enabled, no = disabled
162 | enabled: no
163 | ;
164 | ; Number of SMB targets we'd like to test
165 | smb_targets_count: 2
166 | ;
167 | ; username and password to be used for all tests if all
168 | ; tests use same credentials
169 | smb_global_username:
170 | smb_global_password:
171 | ;
172 | ; first host we'd like to test
173 | smb_host1:
174 | smb_username1:
175 | smb_password1:
176 | smb_path1:
177 | smb_filename1:
178 | ;
179 | ; second host we'd like to test
180 | smb_host2:
181 | smb_username2:
182 | smb_password2:
183 | smb_path2:
184 | smb_filename2:
185 | ;
186 | ; add more SMB targets to match your "smb_targets_count" value
187 | ;smb_host3:
188 | ;smb_username3:
189 | ;smb_password3:
190 | ;smb_path3:
191 | ;smb_filename3:
192 | ;
193 | ;smb_host4:
194 | ;smb_username4:
195 | ;smb_password4:
196 | ;smb_path4:
197 | ;smb_filename4:
198 | ; ...etc
199 | ;
200 | ; ------------ Advanced settings for SMB tests section, do not change --------------
201 | ; Name used for SMB file/data group/data source
202 | smb_data_file: wiperf-smb
203 | ;-------------------------------- SMB Section End ----------------------------------
204 | ```
205 |
206 | ## Dashboards
207 |
208 | There are no new dashboards in this release. As the number of test targets is now variable, with no upper limit, it is up to individual users to customize the supplied dashboards for their own use.
209 |
210 | Going forwards, it is likely I will continue to support the existing 5 instances of each target in any dashboards made available.
211 |
212 | ## Caveats
213 |
214 | Creating a large number of tests may be desirable for certain use-cases, but comes with a few caveats.
215 |
216 | Remember that each test is performed sequentially (i.e. no test is started until the previous test completes). The total time taken to finish all tests may become quite long for high numbers of tests, or for tests measuring demanding or poorly performing targets (e.g. large file transfers or targets that time-out).
217 |
218 | By default, the poll cycle defined for wiperf is 5 minutes. This can be modified by re-configuring the system cron job used by wiperf to initiate regular polls.
219 |
220 | If tests run for longer than the configured poll cycle (e.g. 6 minutes of testing time for a 5 minute poll interval), then a new poll cycle will attempt to start after 5 minutes even though a poll cycle is already in progress. However, the new poll process will detect that a poll cycle is already in progress and exit without performing any tests. This means that you will achieve only half the poll cycles expected, as every 2nd poll cycle will exit without running.
221 |
222 | The wiperf poller also has a fail-safe mechanism to try to fix issues in the event of many test failures being detected. It has a watchdog function that will count various system errors and will reboot the probe if they become too high. In the event that many tests are configured that fail in high numbers, then you many observe the probe rebooting periodically due to the watchdog counter being exceeded. This is not an error - this is built in by design to try to fix issues such as being stuck to a remote access point or other network level issues that require a full reboot to clear unknown issues.
223 |
224 | ## Upgrading
225 | To upgrade from a previous release of wiperf, please consult these instructions in our [upgrade document](probe_upgrade.md).
226 |
227 | ## Related
228 |
229 | Check out this related article: [What's New in version 2.1 ?](whats_new_v2.1.md)
230 |
231 |
232 |
233 |
--------------------------------------------------------------------------------
/mkdocs/mkdocs.yml:
--------------------------------------------------------------------------------
1 | site_name: Wiperf V2 Documentation
2 | nav:
3 | - Home: index.md
4 | - What's New in V2.2: whats_new_v2.2.md
5 | - Quickstart: quickstart.md
6 | - Operation Overview: operation.md
7 | - Probe:
8 | - probe_platform.md
9 | - probe_prepare.md
10 | - probe_install.md
11 | - probe_configure.md
12 | - probe_deploy.md
13 | - probe_upgrade.md
14 | - Data Server:
15 | - Splunk:
16 | - splunk_platform.md
17 | - splunk_software.md
18 | - splunk_install.md
19 | - splunk_configure.md
20 | - Influx/Grafana:
21 | - influx_platform.md
22 | - influx_install.md
23 | - influx_configure.md
24 | - grafana_platform.md
25 | - grafana_install.md
26 | - grafana_configure.md
27 | - Blog Posts:
28 | - blog_neo3.md
29 | - whats_new_v2.1.md
30 | - Troubleshooting: troubleshooting.md
31 | - Advanced Configuration:
32 | - adv_proxy.md
33 | - adv_remote_cfg.md
34 | - adv_rpi_standalone.md
35 | - adv_secure.md
36 | - adv_fixed_bssid.md
37 | - FAQ: faq.md
38 | - Reference Docs:
39 | - config.ini.md
40 | - data_points.md
41 | - reference_doc_smb.md
42 | - reference_doc_librespeed.md
43 | - reference_doc_caching.md
44 | - Dashboards:
45 | - db_probe_summary.md
46 | - db_speedtest.md
47 | - db_udp_iperf3.md
48 | - db_tcp_iperf3.md
49 | - db_http.md
50 | - db_smb.md
51 | - db_wireless.md
52 | - db_health.md
53 | - Contact: https://github.com/wifinigel/wiperf/discussions
54 | - About: about.md
55 | theme:
56 | name: 'material'
57 | custom_dir: overrides
58 | icon:
59 | logo: material/wifi
60 | language: en
61 | palette:
62 | primary: green
63 | accent: green
64 | extra_css:
65 | - extra.css
66 | markdown_extensions:
67 | - markdown.extensions.admonition
68 | - pymdownx.details
69 | - pymdownx.superfences
70 | - attr_list
71 | plugins:
72 | - search
73 | - git-revision-date-localized
74 |
--------------------------------------------------------------------------------
/mkdocs/overrides/404.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | Oops - sorry, we hit an unknown page
8 | Please follow this link.
9 |
10 | window.location.href = "https://wifinigel.github.io/wiperf/404/";
11 |
12 |
13 |
--------------------------------------------------------------------------------
/release_notes.txt:
--------------------------------------------------------------------------------
1 | v2.2.4
2 | 1. Allow use of hostname for mgt platform in config.ini
3 | 2. Fix static route addition for mgt platform to include interface GW address
4 |
5 | v2.2.3
6 | 1. Merged PR with influx2 https & utctime fixes. Thanks jyoung15!
7 |
8 | v2.2.2
9 | 1. Fix influx2 data port naming issue
10 |
11 | v2.2.1
12 | 1. Added fix for influxdb ssl support
13 |
14 | v2.2
15 | 1. Added support for user-defined number of ping tests
16 |
17 | New config.ini parameter to define number of targets, eg.: ping_targets_total: 10
18 |
19 | Added support for timeout and ping interval parameters in config.ini to optimise
20 | ping tests (`ping_timeout` & `ping_interval`)
21 |
22 | Hosts for all required targets must be defined in config.ini too, e.g.
23 |
24 | ping_targets_count: 7
25 | ping_host1: google.com
26 | ping_host2: cisco.com
27 | ping_host3: bbc.co.uk
28 | ping_host4: 8.8.8.8
29 | ping_host5: 8.8.4.4
30 | ping_host6: my_site.command
31 | ping_host7: my_other_site.com
32 |
33 | ping_count: 10
34 | ping_timeout: 1
35 | ping_interval: 0.2
36 |
37 | 2. Added support for user-defined number of dns tests (no longer has max limit of 5)
38 |
39 | New config.ini parameter: `dns_targets_count`
40 |
41 | 3. Added support for user-define number of http tests (no longer has max limit of 5)
42 |
43 | New config.ini parameter: `http_targets_count`
44 |
45 | 4. Add support for user-defined number of smb tests (no longer has max limit of 5)
46 |
47 | New config.ini parameter: `smb_targets_count`
48 |
49 | v2.1
50 |
51 | 1. Added new dashboard for SMB tests
52 | 2. Updated summary dashboard to support new SMB tests
53 | 3. Updated speedtest dashboard to support librespeed and additional data points
54 | 4. Added dashboard for probe health, which include probe poll error messages
55 | 5. Miscellaneous minor dashboard improvements/fixes
56 |
57 | v2.0.0-beta 6
58 | 1. Using timeout_decorator module to timeout iperf3 sessions that hang whole poller process
59 |
60 | v2.0.0-beta 5
61 | 1. Move to using iperf3 python module to fix ongoing iperf3 test issues
62 | 2. Poller module v0.1.24
63 |
64 | v2.0.0-beta 4
65 | 1. Added network connectivity files restore during upgrade
66 | 2. Added initial ipv6 support for mgt traffic
67 |
68 | v2.0.0-beta 3
69 | 1. Added checks for sudo operation
70 | 2. Added check for python version
71 | 3. Added searches for missing prog files (for platforms using non-std locations)
72 |
73 |
74 | v2.0.0-beta2
75 |
76 | 1. Fixed bad URL in setup.sh
77 | 2. Removed legacy data location, format & transport settings from config.ini
78 |
79 | v2.0.0-beta1
80 |
81 | 1. Initial commit of v2 code
82 |
83 |
84 |
--------------------------------------------------------------------------------
/version.txt:
--------------------------------------------------------------------------------
1 | 2.2.4
--------------------------------------------------------------------------------
/wiperf_run.py:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env python3
2 | # -*- coding: utf-8 -*-
3 |
4 | import wiperf_poller.__main__ as agent
5 |
6 | # run wiperf agent
7 | agent.run()
8 |
9 |
--------------------------------------------------------------------------------