[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #23257 [Obfuscation/Snowflake]: Snowflake doesn't connect on the CalVisitor network
#23257: Snowflake doesn't connect on the CalVisitor network
---------------------------------------+--------------------
Reporter: dcf | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Obfuscation/Snowflake | Version:
Severity: Normal | Keywords:
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
---------------------------------------+--------------------
Snowflake doesn't work on [https://telecom.berkeley.edu/calvisitor one of
the wireless networks] at UC Berkeley. It sends an offer and receives an
answer, but then hangs here:
{{{
2017/08/16 13:56:38 ---- Handler: snowflake assigned ----
2017/08/16 13:56:38 Buffered 203 bytes --> WebRTC
2017/08/16 13:56:43 Traffic Bytes (in|out): 0 | 203 -- (0 OnMessages, 1
Sends)
}}}
I initially suspected that it had something to do with the network not
assigning a public IPv4 address, only a public IPv6 address. I moved our
existing proxy-go instances to a host with an IPv6 address, and that
didn't help.
Here's the part of the log where client gathers its candidates. Notice the
IPv6 address 2607:f140:6000:2:c53e:4d3e:19d5:d94c and the IPv4 address
10.105.136.190.
{{{
2017/08/16 13:55:58 WebRTC: DataChannel created.
2017/08/16 13:55:58 candidate:1109156821 1 udp 2122262783
2607:f140:6000:2:c53e:4d3e:19d5:d94c 56748 typ host generation 0 ufrag
3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:2027054270 1 udp 2122194687 10.105.136.190
61395 typ host generation 0 ufrag 3h4p network-id 1 network-cost 50
2017/08/16 13:55:58 candidate:211787557 1 tcp 1518283007
2607:f140:6000:2:c53e:4d3e:19d5:d94c 49259 typ host tcptype passive
generation 0 ufrag 3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:911317070 1 tcp 1518214911 10.105.136.190
49260 typ host tcptype passive generation 0 ufrag 3h4p network-id 1
network-cost 50
2017/08/16 13:55:59 SOCKS accepted: {0.0.3.0:1 map[]}
}}}
Here's an abridged form of the answer. Notice how the candidates
(`a=candidate:`) include both IPv6 2a00:c6c0:0:151:4:8f94:69f5:7c01 and
IPv4 37.218.242.151. However, the connection address (`c=`) is the IPv4
address.
{{{
o=- 5000276783403536546 2 IN IP4 127.0.0.1
m=application 41242 DTLS/SCTP 5000
c=IN IP4 37.218.242.151
a=candidate:836092752 1 udp 2122262783 2a00:c6c0:0:151:4:8f94:69f5:7c01
40571 typ host generation 0 network-id 1 network-cost 50
a=candidate:404726760 1 udp 2122194687 37.218.242.151 41242 typ host
generation 0 network-id 2 network-cost 50
a=candidate:2136358816 1 tcp 1518283007 2a00:c6c0:0:151:4:8f94:69f5:7c01
39103 typ host tcptype passive generation 0 network-id 1 network-cost 50
a=candidate:1453088536 1 tcp 1518214911 37.218.242.151 49703 typ host
tcptype passive generation 0 network-id 2 network-cost 50
}}}
Is this one of those weird NAT cases where a TURN server is needed? Is
that why it's not working? The CalVisitor does block some applications
like IMAP.
I tested this with Tor Browser 7.5a4 for mac.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23257>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs