Closed ChristofKaufmann closed 5 years ago
Does it help with your use case of two NATs? We would definitely need to make it a command line option for twamp (-Z for example).
Yes, this simple fix makes it work.
OK, I will add another commit for the command line option. (Or should I just amend and force-push?)
Great, you can just make a new commit on the same branch.
I have used it now for some days and it works. Once I used it even with two chained NATs on client side and one NAT on server side. So from my side it is finished and you can merge it.
Thanks for the discussion in issue #49 to make this possible!
On Fri, Feb 01, 2019 at 04:44:48AM -0800, ChristofKaufmann wrote:
I have used it now for some days and it works. Once I used it even with two chained NATs on client side and one NAT on server side. So from my side it is finished and you can merge it.
Thanks for the discussion in issue #49 to make this possible!
Thanks for the patch. I will give it a try and merge if everything looks good.
-- Valentin
Confirm that the patch works for a client behind Linux NAT:
$ twping -Z pstest2.geant.carnet.hr
Approximately 13.0 seconds until results available
--- twping statistics from [192.168.122.195]:9383 to [pstest2.geant.carnet.hr]:19173 ---
SID: c1c6f11ee00544919ae0a876b5d5276e
first: 2019-02-06T12:33:38.763
last: 2019-02-06T12:33:49.527
100 sent, 0 lost (0.000%), 0 send duplicates, 0 reflect duplicates
round-trip time min/median/max = 1.38/1.6/1.78 ms, (err=5.05 ms)
send time min/median/max = 0.476/0.6/0.717 ms, (err=2.53 ms)
reflect time min/median/max = 0.818/1.1/1.1 ms, (err=2.53 ms)
reflector processing time min/max = 0.00668/0.093 ms
two-way jitter = 0.2 ms (P95-P50)
send jitter = 0.1 ms (P95-P50)
reflect jitter = 0 ms (P95-P50)
send hops = 6 (consistently)
reflect hops = 4 (consistently)
Checked the TWAMP protocol with wireshark, everything looks as before if -Z is not used.
Merged for 4.2.0 release after a bit of cleanup and updating the manpage.
This pull request fixes #49 by sending zero-addresses for sender and receiver in the test session request sent by twping. The server application twampd handles this request already by using the control session addresses. This allows to use twping with a client behind a NAT and the server behind a NAT. The server's NAT must forward the TCP control port and UDP test ports to the server to make it work.
Sending zero-addresses is allowed according to RFC 5357 section 3.5.
The PR is marked as WIP, since with it twping will always send zero-addresses in its test session request. This might not be desired. Other possibilities would be:
Maybe some discussion about implications is required.