search

nitred / nr-wg-mtu-finder

MIT License
211 stars 23 forks source link

KeyError: 'streams' #1

Closed ghost closed 3 years ago

ghost commented 3 years ago

SERVER: nr-wg-mtu-finder --mode server --mtu-min 1280 --mtu-max 1420 --mtu-step 2 --server-ip 10.10.10.1

CLIENT: nr-wg-mtu-finder --mode peer --mtu-min 1280 --mtu-max 1420 --mtu-step 2 --server-ip 10.10.10.1

After running the test for a while, I receive the following error:

WG Interface Down                                 : SUCCESS
Setting MTU to 1344 in /etc/wireguard/wg0.conf    : SUCCESS
WG Interface Up                                   : SUCCESS
Running peer upload                               : SUCCESS
Running peer download                             : SUCCESS
Appending log for MTU: 1344                       : SUCCESS
--------------------------------------------------------------------------------
WG Interface Down                                 : SUCCESS
Setting MTU to 1346 in /etc/wireguard/wg0.conf    : SUCCESS
WG Interface Up                                   : SUCCESS
Running peer upload                               : SUCCESS
Running peer download                             : SUCCESS
Appending log for MTU: 1346                       : SUCCESS
--------------------------------------------------------------------------------
WG Interface Down                                 : SUCCESS
Setting MTU to 1348 in /etc/wireguard/wg0.conf    : SUCCESS
WG Interface Up                                   : SUCCESS
Running peer upload                               : FAILED with code 1
Running peer download                             : FAILED with code 1
Traceback (most recent call last):
  File "/etc/miniforge3/envs/wireguard-mtu/bin/nr-wg-mtu-finder", line 8, in <module>
    sys.exit(run())
  File "/etc/miniforge3/envs/wireguard-mtu/lib/python3.9/site-packages/nr_wg_mtu_finder/main.py", line 105, in run
    MTUFinder(**args.dict())
  File "/etc/miniforge3/envs/wireguard-mtu/lib/python3.9/site-packages/nr_wg_mtu_finder/mtu_finder.py", line 43, in __init__
    self.run_peer_mode()
  File "/etc/miniforge3/envs/wireguard-mtu/lib/python3.9/site-packages/nr_wg_mtu_finder/mtu_finder.py", line 296, in run_peer_mode
    down_rcv_bps, down_snd_bps = self.run_iperf3_download_test()
  File "/etc/miniforge3/envs/wireguard-mtu/lib/python3.9/site-packages/nr_wg_mtu_finder/mtu_finder.py", line 183, in run_iperf3_download_test
    output["end"]["streams"][0]["receiver"]["bits_per_second"],
KeyError: 'streams'

If I restart the client from a mtu-min of 1346 then it continues as normal and passes where the error occurred previously.

Using:

SERVER: nr-wg-mtu-finder --mode server --mtu-min 1280 --mtu-max 1340 --mtu-step 2 --server-ip 10.10.10.1

CLIENT: nr-wg-mtu-finder --mode peer --mtu-min 1280 --mtu-max 1340 --mtu-step 2 --server-ip 10.10.10.1

I can run the test successfully without any errors.

nitred commented 3 years ago

I really appreciate you trying it out and I'm glad you were able to fully go through all the MTUs even though it was with some difficulties.

As for the KeyError: 'streams' error, it occurs when peer upload or peer download fails and the output json from the iperf3 -c command doesn't contain the streams key. I faced this issue very often but only when the server MTU was changed. That's why when the server MTU changes, I added the additional ping and flask-server checks.

However I never faced an issue like you did, where the peer upload and peer download failed during the loop. It could have failed due to several reasons. Some I can think of are:

I will attempt to make one or more of the following fixes for this problem:

  1. Provide a --skip-errors flag that will let the peer script continue with testing other MTUs if one of the test fails.
  2. Provide a --peer-pre-ping flag that will let the peer script ping the server before attempting to run iperf3 -c commands. The ping command always helped me re-establish the server peer connection and the handshake time was refreshed.
  3. Print out the error from the peer upload and peer download tests in case there was a failure. This should have already been there.
nitred commented 3 years ago

I pushed some changes

  1. Added --peer-skip-errors True option that is True by default and can be set to False by --peer-skip-errors False
  2. Peer will now always ping the server each time after the peer MTU has been changed
  3. Prints out stdout and stderr messages if ever a command fails