I've been working on understanding the firewalls of the world (at least IPV6 compatible ones for the moment). Specifically I am trying to understand what the maximum/minimum/average time is required to keep UDP NAT traversal reliable for 95% of users.
The code I've got running does the following:
Start with delay = 1s
Send UDP packet to server
Wait for 1s
Did my packet return?
Then it doubles the time and tries again
Once it fails it then backtracks to binary chop the actual maximum delay time
The output looks something like this:
The port is just your outgoing port number
Test 2: P2P2O
This is a two second test, so send a packet and wait for two seconds until the server sends it back. Because NAT firewalls don't create an entry in their translation table until they've seen a packet in both directions then the server actually replies immediately, then waits two seconds and then replies again. So what you see in the above is:
Test 2: - means we send a packet to the server containing a value '2'
P2 - means we've received an immediate packet back from the server and it contained the delay value '2'
P2 - means we've received a second packet back from the server after a two second break which contained the delay value '2'
O - means it happened correctly and passed
P256X Means we sent a packet it returned one immediately with 256 in the packet. But after 256 ish seconds we still hadn't had a reply 'X' as this is a fail, it repeats the whole thing again, just in case the UDP packet just got dropped somewhere in between
It would be really useful if you would try running it on your Pi, wherever it is in the world to see whether your link supports IPV6, whether your firewall will allow through the UDP packet and whether it'll return the response.
https://github.com/ghollingworth/udpping
If you get E in the result, that means there was an error reply from somewhere along the line (it might be that I'm not actually running the server!!!
Gordon
The code I've got running does the following:
Start with delay = 1s
Send UDP packet to server
Wait for 1s
Did my packet return?
Then it doubles the time and tries again
Once it fails it then backtracks to binary chop the actual maximum delay time
The output looks something like this:
Code:
Port = 39724Test 2: P2P2OTest 4: P4P4OTest 8: P8P8OTest 16: P16P16OTest 32: P32P32OTest 64: P64P64OTest 128: P128P128OTest 256: P256XP256XTest 192: P192XP192XTest 160: P160P160OTest 176: P176P176OTest 184: P184P184OTest 188: P188P188OTest 190: P190P190OTest 191: P191XP191XTest 2: P2P2O
This is a two second test, so send a packet and wait for two seconds until the server sends it back. Because NAT firewalls don't create an entry in their translation table until they've seen a packet in both directions then the server actually replies immediately, then waits two seconds and then replies again. So what you see in the above is:
Test 2: - means we send a packet to the server containing a value '2'
P2 - means we've received an immediate packet back from the server and it contained the delay value '2'
P2 - means we've received a second packet back from the server after a two second break which contained the delay value '2'
O - means it happened correctly and passed
P256X Means we sent a packet it returned one immediately with 256 in the packet. But after 256 ish seconds we still hadn't had a reply 'X' as this is a fail, it repeats the whole thing again, just in case the UDP packet just got dropped somewhere in between
It would be really useful if you would try running it on your Pi, wherever it is in the world to see whether your link supports IPV6, whether your firewall will allow through the UDP packet and whether it'll return the response.
https://github.com/ghollingworth/udpping
Code:
git clone https://github.com/ghollingworth/udppingcd udppinggcc -o udp_test_client udp_test_client./udp_test_clientGordon
Statistics: Posted by gsh — Thu Dec 19, 2024 7:03 pm