mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
e3546cfa12
In some cases we were obvserving that connections between clients and
gateways couldn't be established.
This happened even when candidates where being found on both ends.
This usually was obvserved when ipv6 isn't working on the relays and
it's still used as one of the viable candidates.
To reproduce this more easily I created an iface with 50 ips using this
script:
```bash
#!/bin/bash
# Generate 10 IPv6 addresses
for i in {1..10}
do
for j in {1..5}
do
# Generate a random IPv6 address
ipv6_address=$(openssl rand -hex 5 | sed 's/\(..\)/\1:/g; s/.$//' | awk '{print "fd00::"$1}')
# Add IPv6 address to lo0
sudo ifconfig lo0 inet6 alias $ipv6_address
echo "Added IPv6 address $ipv6_address to lo0"
done
done
```
This behavior was almost consistently obvserved, as it depended on the
order candidates were used.
I tried modifying timeouts and the limits to channel binding requests
that are internal to webrtc but the connections were still not
consistent, the only thing that worked was limiting the number of host
candidates.
This is okay since even if we can't stablish the local connection (no
hairpin nat) relayed connection will still happen.
But this is not a good long-term solution. In the future we should be
smarter how we sort and ping candidates, prioritizing srflx to srflx or
srflx to relay and leave host candidates for last. Will be easier to
improve on after refactoring webrtc out.