A python project to help find the optimal MTU values that maximizes the upload or download speeds between a peer and server. It also helps find bandwidth dead zones caused due to a poor choice of MTUs.
I built the project to help myself find the right MTU values for my WG server and peer. I inadvertently found that the default MTU values for the server and peer in my case put my WG connection in a bandwidth dead zone. [Related reddit post](https://www.reddit.com/r/WireGuard/comments/plm8y7/finding_the_optimal_mtu_for_wg_server_and_wg_peer/).
You can have a look at the real-world heatmaps which are posted by users in the issue [Post your MTU heatmaps here!](https://github.com/nitred/nr-wg-mtu-finder/issues/4) If you happen to successfully use `nr-wg-mtu-finder` and are able to generate a heatmap, please post your heatmap in the issue if possible.
* Additionally the project only supports `python 3.8` and `python 3.9`. While it may work on `python 3.7` and `python 3.10`, you may have to resolve some issues with building dependencies, yourself.
1. Before running the following scripts, the WG interface is expected to be active/online such that the peer is able to ping the server. Use `wg-quick up INTERFACE` on both the WG server and WG peer to activate the connection.
* Two python scripts need to be running simultaneously, one of the WG server and one on the WG peer. Let's call them *server script* and *peer script*.
* Both scripts use `subprocess.Popen` to run shell commands. The following commands are used and expected to be pre-installed if not already available:
* The peer script gets the status and MTU of the server script from the `sync_server`.
* The peer script tells the `sync_server` that it is done with its looping through all of its MTUs and is ready for the server script to change its MTU so that it can start a fresh cycle.
* The `sync_server` informs the peer script that the server script is finished with looping through all MTUs and that it is going to shut itself down. The peer script uses this signal to shut itself down as well.
1. When the server script receives an `INITIALIZE` signal, it runs the following shell commands
1. If the server has finishing cycling through all of its MTUs and then receives a request from peer script that it is ready for a new cycle, then the server sends a `SHUTDOWN` signal to the peer script via the `sync_server`.
* On start, the peer script checks if the `sync_server` is reachable. Once it is reachable, it sends a `peer/ready` request to the server script.
* The peer script then waits for the `iperf3` server to start on the server side. Once it recognizes that the iperf3 server has started, and then the peer script starts cycling through each of its MTUs.
* For each MTU, the peer script runs an upload and download test using the following command
* Once the peer script is finished cycling through all of its MTU, it sends another `peer/ready` request to the server script and restarts the whole process again with the next server MTU.
* If the server script is finished cycling through all of its MTUs, then it sends a `SHUTDOWN` response to the peer script as a reply to the `peer/ready` request. The server shuts down after a short delay as does the peer script.
* Finally, the user can check the bandwidth log/csv file to see the results.
* If you successfully ran the server & peer script as described in the instructions, then a log file (csv file) which contains the MTU data like in this [example.csv](https://github.com/nitred/nr-wg-mtu-finder/blob/master/examples/example.csv) is generated by the ***peer script***.
* The filename for this log file looks like `wg_mtu_finder_peer_20220101T000000.csv` and is generated in the same directory where the ***peer script*** was run.
* Once the ***peer script*** is done or is shutting down, then the plot function is called which reads the contents of log csv file and generates a heatmap graph which is written to a png file like in this [example.png](https://github.com/nitred/nr-wg-mtu-finder/blob/master/examples/example.png).
* The filename for the heatmap png looks like `wg_mtu_finder_peer_20220101T000000.png` and is generated in the same directory where the ***peer script*** was run.
So if you successfully ran the server and peer script, you should find two new files (one csv and one png) generated in the same directory where you ran the ***peer script*** on the ***WG-peer*** server.