#34129: Use STUN to determine NAT behaviour of peers -------------------------------------+--------------------------- Reporter: cohosh | Owner: cohosh Type: enhancement | Status: assigned Priority: Medium | Milestone: Component: Circumvention/Snowflake | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: Sponsor28 -------------------------------------+---------------------------
Comment (by cohosh): Replying to [comment:7 dcf]: > I did `apt install coturn` to use the [https://github.com/coturn/coturn/wiki/turnutils_stunclient turnutils_stunclient] program. I ran it and got the following output. I changed my actual IP address to `192.0.2.3`. > > {{{ > $ turnutils_stunclient -f 174.138.112.125 > > ======================================== > RFC 5780 response 1 > 0: IPv4. Response origin: : 10.20.0.7:3478 > 0: IPv4. Other addr: : 68.183.200.83:3479 > 0: IPv4. UDP reflexive addr: 192.0.2.3:32960 > }}} > > turnutils_stunclient then hangs until I ctrl-C it. > > Looking at a packet capture, there are 2 outgoing packets and 1 incoming packet. I just tried this myself and got the same thing. It also when I tried other STUN servers that advertize the `OTHER-ADDRESS` attribute. I wonder if this is a bug in the coturn server (or at the very least the set up instructions). From reading RFC 5780, the `CHANGE-REQUEST` attribute is used to determine the type of NAT '''filtering''', and is not needed for determining the type of NAT mapping, but of course both are important to know. Also, now that I'm looking at this. It seems there's a typo here in the advertized attribute from the client. I think it should be `CHANGE- REQUEST`, not `CHANGE_REQUEST`. That might be causing problems. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/34129#comment:8> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs