Version 3 Feature List

[wifinigel]

I'm planning version 3 of wiperf and would be interested in feedback on your thoughts of what should be in there.

My top 2 priority items are:

1. A local admin GUI - the config.ini file is becoming too unwieldly to work with, so an admin interface would be preferable
2. Some type of modular structure to allow people to add their own test modules to a wiperf framework

[busysignal]

My current HomeLab Environment uses Gravwell as a data aggregate where all of my NetFlow traffic is sent there and then monitored for port/data/source/dest details are then reported on for the entire network (brief review here:https://www.busysignal.io/gravwell-a-place-for-all-your-stuff-netflow-focus/) and here is a link to their docs section - https://docs.gravwell.io/#!ingesters/ingesters.md -- I use their Community Edition for a 2GB a day ingestion limit but its been more than enough for most of my taks...

I have multiple RasPi devices around the house monitoring temperature reporting back to the Gravwell server the Temp/Humidity every 60 seconds via their HTTP post - simple python service sending this data.

I would love to have to have multiple RasPi's run the WiPerf process and report data from multiple locations in the house and forward it to the Gravwell instance.

[wifinigel]

Hi Dustin (@busysignal) , is it the HTTP ingester you are looking to try and utilize?

If so, which auth methods would be most useful? The none, basic & token would be easiest to implement.

Also, what format does the actual post data need to be? Would JSON be OK, as are currently used for the Influx & Splunk exporters?

Nigel.

[busysignal]

Sorry for the delay in response - I believe just post data would be fine with either none or basic auth methods. The Gravwell docs on their ingestors are solid.

[lealog]

Hi @wifinigel.

I have some ideas :)

• Add an API to connect wiperf to an automation framework cloud be something interesting,
• Add some type of ARP test (we know that sometimes L2 issues are a big problem in our networks).
• Add IPv6 Neighbour Discovery Protocol tests.
• Possibility to control more that one wiperf node at the same time (ex. have 2 wiperf nodes connected on 2.4GHz/5GHz bands, and trigger some concurrent tests at the same time. If an API is available the nodes can be triggered remotely).
• Add a test as optional to disconnect/connect the Wi-Fi connection every x min. To goal is to evaluate the stability of Wi-Fi AP adding and removing STA's in a long term and record the time needed to have Wi-Fi connection and IP.
• Any possibility to have iperf2 and speedtest on the same cycle using IPv4 and IPv6 tests? Today I can only select one of the IP versions.
• IPv6- Some type of test to evaluate "Stateless" or "Stateful" (similar to what is doing today on DHCP test).
• Control the Wi-Fi connection based on BSSID and not only on SSID. I'm doing this today on wpa_supplicant.conf.
• Possibility to configure other types of DNS queries - NAPTR, AAAA, etc

Thanks for your effort and help.

[wifinigel]

Oscar,

Some good suggestions here. I'll spin off a few of these as separate issues/requests to focus on them individually and ping you via the individual tickets, as I may need some help in defining them.

Really appreciate the ideas !

[lealog]

Ok :)

[Blazerfi]

What about an endpoint dashboard, kind of like this:

https://grafana.com/grafana/dashboards/3288

https://geeksops.com/?p=310

[wifinigel]

@Blazerfi I'm embarrassed to admit I'd never heard of MTR! It's always great to learn new stuff from clever folks :)

After digging around and taking a look, I see that it looks like a very powerful tool.

I need to spend some time looking at it and see how it could be incorporated in to wiperf - I really like the idea, as it provides more information about the user experience and looks to be a valuable diagnostics tool.

Thank you very much for raising this - I can't wait to play with it!

[Blazerfi]

My pleasure! I use it a lot when checking for any latency to our cloud services.