#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
 turnutils_stunclient] program. I ran it and got the following output. I
 changed my actual IP address to ``.
 > {{{
 > $ turnutils_stunclient -f
 > ========================================
 > RFC 5780 response 1
 > 0: IPv4. Response origin: :
 > 0: IPv4. Other addr: :
 > 0: IPv4. UDP reflexive addr:
 > }}}
 > turnutils_stunclient then hangs until I ctrl-C it.
 > Looking at a packet capture, there are 2 outgoing packets and 1 incoming
 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

 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

Reply via email to