Opened 3 years ago

Last modified 2 years ago

#18154 new defect

attempt to open a socket after DisableNetwork=1 transition

Reported by: mcs Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client disablenetwork needs-diagnosis
Cc: gk, brade Actual Points:
Parent ID: Points: small/medium
Reviewer: Sponsor:

Description

Tor Browser 6.0a1 includes a change that was made as part of #11773 that causes Tor Launcher to immediately issue a SETCONF DisableNetwork=1 command when the user cancels the bootstrapping process. Unfortunately, this causes tor to sometimes emit an error like this one:

650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=25 TAG=loading_status SUMMARY="Loading networkstatus consensus" WARNING="Network is unreachable" REASON=NOROUTE COUNT=1 RECOMMENDATION=warn HOSTID="0AD3FA884D18F89EEA2D89C019379E0E7FD94417" HOSTADDR="208.83.223.34:80"

And Tor Launcher displays an error alert.

I cannot reproduce this when I enable debug logging in tor, but I can when info logging is enabled. In the tor log I see:

Jan 26 13:40:08.000 [warn] connection_connect_sockaddr(): Bug: Tried to open a socket with DisableNetwork set. (on Tor 0.2.7.6 7a489a6389110120)

I will attach a trace from Tor Launcher as well as the tor info log.

Is this a tor bug? Or is there a better way for Tor Launcher to stop the bootstrapping process?

Child Tickets

Attachments (2)

tl-log.txt (2.9 KB) - added by mcs 3 years ago.
Tor Launcher debug log
tor-log.txt (184.1 KB) - added by mcs 3 years ago.
tor info log

Download all attachments as: .zip

Change History (14)

Changed 3 years ago by mcs

Attachment: tl-log.txt added

Tor Launcher debug log

Changed 3 years ago by mcs

Attachment: tor-log.txt added

tor info log

comment:1 Changed 3 years ago by mcs

Cc: gk brade added

comment:2 Changed 3 years ago by teor

This could be due to a race condition where Tor starts a network connection attempt before you issue the SETCONF, then the SETCONF completes, then the socket connection attempt occurs.

I'm not sure what we can do to fix this, but we might be able to make the race harder to trigger.

Are you using 0.2.8.0-alpha-dev in 6.0a1?
We refactored periodic events in 0.2.8, which might have made this race easier to trigger.

comment:3 in reply to:  2 Changed 3 years ago by mcs

Replying to teor:

This could be due to a race condition where Tor starts a network connection attempt before you issue the SETCONF, then the SETCONF completes, then the socket connection attempt occurs.

I'm not sure what we can do to fix this, but we might be able to make the race harder to trigger.

I am not very familiar with the tor internals, but I wonder how difficult it would be to gracefully shutdown/cleanup "in progress" connections during a transition to the "network disabled" state? In other words, during some short period of transition tor would not report an error but just close the socket, etc.

Are you using 0.2.8.0-alpha-dev in 6.0a1?
We refactored periodic events in 0.2.8, which might have made this race easier to trigger.

TB 6.0a1 still uses 0.2.7.6:

Jan 26 13:32:54.055 [notice] Tor v0.2.7.6 (git-7a489a6389110120) running on Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.1q and Zlib 1.2.5.

comment:4 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-final

comment:5 Changed 3 years ago by nickm

Priority: MediumLow

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

Throw most 0.2.8 "NEW" tickets into 0.2.9. I expect that many of them will subsequently get triaged out.

comment:7 Changed 3 years ago by nickm

Points: small/medium

comment:8 Changed 3 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:9 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:10 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:11 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 2 years ago by nickm

Keywords: tor-client disablenetwork needs-diagnosis added

If this comes up again, the tor_fragile_assert() immediately after that log message should make a stack trace get displayed.

Note: See TracTickets for help on using tickets.