--ack-timeout and --conn-timeout do not seem to work

[jpmzometa]

Starting the TFTP server as follows does not change the default timeouts:
py3tftp -p 9069 --ack-timeout 5 --conn-timeout 10 -v

using Wireshark, I can see the timeouts are still ack-timeout=0.5 and conn-timeout=5.0.

The debug output of py3tftp shows the following:
2018-01-12 14:49:40,987 [INFO] Starting TFTP server on 0.0.0.0:9069
2018-01-12 14:49:40,988 [DEBUG] Using selector: KqueueSelector
2018-01-12 14:49:40,988 [INFO] Listening...
2018-01-12 14:50:02,492 [DEBUG] received: test.txtoctettsize0blksize508
2018-01-12 14:50:02,492 [DEBUG] Request: b'test.txt\x00octet\x00tsize\x000\x00blksize\x00508\x00'
2018-01-12 14:50:02,492 [DEBUG] b'tsize'
2018-01-12 14:50:02,493 [DEBUG] b'blksize'
2018-01-12 14:50:02,493 [DEBUG] packet type: RRQ
2018-01-12 14:50:02,493 [DEBUG] Request: b'test.txt\x00octet\x00tsize\x000\x00blksize\x00508\x00'
2018-01-12 14:50:02,494 [DEBUG] b'tsize'
2018-01-12 14:50:02,494 [DEBUG] b'blksize'
2018-01-12 14:50:02,494 [DEBUG] b'blksize'
2018-01-12 14:50:02,494 [INFO] Initiating RRQProtocol with ('127.0.0.1', 9997)
2018-01-12 14:50:02,495 [DEBUG] {b'blksize': 508}
2018-01-12 14:50:02,495 [DEBUG] {b'ack_timeout': 0.5, b'timeout': 5.0, b'blksize': 508, 'ack_timeout': 5.0, 'timeout': 10.0}
[DEBUG] {b'ack_timeout': 0.5, b'timeout': 5.0, b'blksize': 508, 'ack_timeout': 5.0, 'timeout': 10.0}
...

Any idea where the problem might be?
Regards,

[sirMackk]

Hi @jpmzometa, thanks for catching this bug. I think I messed up how strings/bytes are handled in a specific spot.

I've created a possible fix on a different branch: https://github.com/sirMackk/py3tftp/tree/issue_3_fix, would it be possible for you to run the code from that branch and see if your issue is fixed? If you're not comfortable with the python toolchain, I can help out a bit and guide you.

[sirMackk]

Hi @jpmzometa, can you confirm if the patch fixes the problem?

[jpmzometa]

Hi. I tested it and it seems to work, but not as I expected. I guess the documentation is not clear on the meaning of --conn-timeout:

Timeout before the server gives up on a transfer and closes the connection.

As it now is, this timer seems to be reset every time a packet arrives at the server. I thought it was a sort of "global" timer, that starts as soon as a transfer is requested, and if the full transfer is not finished before the timer expires, the connection should be closed. Anyways, the current implementation of --conn-timeout is fine as it is, just the documentation is not very clear.

[sirMackk]

Great, many thanks @jpmzometa! I'll expand the readme to include that bit of information and I'll create a new release for pypi this weekend.