Opened 10 months ago

Last modified 10 months ago

#24640 assigned defect

improve meek behavior when target server is down

Reported by: brade Owned by: dcf
Priority: Medium Milestone:
Component: Obfuscation/meek Version:
Severity: Normal Keywords:
Cc: mcs Actual Points:
Parent ID: #24689 Points:
Reviewer: Sponsor:

Description

As part of our testing of Tor Launcher / Moat functionality, Mark and I ran our own meek-server but intentionally stopped the BridgeDB/moat server to which it was supposed to talk. This caused a 5 minute hang within Tor Launcher before an error was generated.

On the meek-client side, we see a series of messages like these:

status code was 500, not 200; trying again after 30 seconds (9)

On the meek-server side, we see these messages:

dial tcp 192.168.1.xx:6790: getsockopt: connection refused

Because this is part of the Moat client implementation inside Tor Launcher, if BridgeDB is down a real person will be waiting a long time without receiving any feedback. It does not look like the retry interval or count is configurable within meek-client.

Do you have any suggestions for minimizing or eliminating the 5 minutes? We could implement a different maximum timeout inside Tor Launcher, although knowing that the underlying error is "connection refused" vs. "the network is just really slow" would make things more robust.

Child Tickets

Change History (1)

comment:1 Changed 10 months ago by mcs

Parent ID: #24689
Note: See TracTickets for help on using tickets.