[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #20348 [Metrics/Censorship analysis]: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
#20348: Kazakhstan blocking of vanilla Tor and obfs4, 2016-06
-----------------------------------------+--------------------------
Reporter: dcf | Owner:
Type: project | Status: reopened
Priority: Medium | Milestone:
Component: Metrics/Censorship analysis | Version:
Severity: Normal | Resolution:
Keywords: censorship block kz | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------------------+--------------------------
Comment (by dcf):
Replying to [comment:35 cypherpunks]:
> > It sounds like kzblocked has actually gotten it to happen, maybe on a
slow link.
>
> This is something about conn.Conn.Write(frameBuf.Bytes()), if frameBuf
is too long (say 4-7 frames) then everything broken. Can't reproduce short
write exactly, as log and tcpdump show everything goes to wire, but server
dislikes result anyway. If to conn.Conn.Write every frame separately then
server dislike data anyway, but if to delay every conn.Conn.Write then
everything works ok. I'm lost
It might be a race condition... Can you try compiling the obfs4proxy code
with the race detector?
https://blog.golang.org/race-detector
https://golang.org/doc/articles/race_detector.html
I think you can just do `go build -race` in the obfs4proxy directory. Then
export the environment variable
`GORACE='log_path=/tmp/obfs4proxyrace.txt'` before you run anything.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20348#comment:37>
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