Re: [tor-relays] tor_bug_occured_(): This line should not have been reached

2019-07-08 Thread David Goulet
On 07 Jul (01:16:07), Michael Gerstacker wrote:
> Hey guys,
> 
> my relay
> 79E683340B80676DCEB029E48FBD36BC66EBDA1E
> told me:
> 
> 
> Jul 06 15:22:34.000 [notice] DoS mitigation since startup: 0 circuits
> killed with too many cells. 150515 circuits rejected, 16 marked addresses.
> 0 connections closed. 104 single hop clients refused.
> 
> Jul 06 16:23:25.000 [warn] tor_bug_occurred_(): Bug:
> ../src/core/or/channeltls.c:: channel_tls_handle_cell: This line should
> not have been reached. (Future instances of this warning will be silenced.)
> (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: Line unexpectedly reached at
> channel_tls_handle_cell at ../src/core/or/channeltls.c:. Stack trace:
> (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x46)
> [0x562903c4faa6] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0)
> [0x562903c4b1c0] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug:
> /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x562903ad571a] (on Tor
> 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x9a16a) [0x562903af916a]
> (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug:
> /usr/bin/tor(connection_handle_read+0x99d) [0x562903ac318d] (on Tor 0.3.5.8
> )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x69ebe) [0x562903ac8ebe]
> (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug:
> /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f469cdbf9ba] (on
> Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug:
> /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7)
> [0x7f469cdc0537] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xb0)
> [0x562903aca290] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10e5)
> [0x562903ab80d5] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a)
> [0x562903ab530a] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(main+0x19)
> [0x562903ab4ec9] (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug:
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f469c6a109b]
> (on Tor 0.3.5.8 )
> 
> Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
> [0x562903ab4f1a] (on Tor 0.3.5.8 )
> 
> Jul 06 21:22:34.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00 hours,
> with 5113 circuits open. I've sent 2802.42 GB and received 2781.10 GB.
> 
> Jul 06 21:22:34.000 [notice] Circuit handshake stats since last time:
> 13801/13801 TAP, 169020/169020 NTor.
> 
> 
> Its anyway a little bit strange because this is the only relay i have which
> never deleted his logfiles since i set it up and where i can not change the
> language of the operating system.
> I think its related to the host system but i never really thought about
> because it seems to work fine.
> 
> Something i should do now?

Nothing much to do here. Fortunately, the relay recovers after that.

I've created this ticket about this issue:
https://trac.torproject.org/projects/tor/ticket/31107

I haven't had time to look into this just yet. However, thanks for the report!

Cheers!
David

-- 
fE4jqrcBXUKBv6iyHwOJ9X/7UU0f02CVPufALtF1L74=


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Call for setting up new obfs4 bridges

2019-07-08 Thread Philipp Winter
On Wed, Jul 03, 2019 at 03:45:23PM +, nottryingtobel...@protonmail.com 
wrote:
> While resetting my bridge, I discovered that setting OR Port to auto
> causes the port not to survive restarts. After the OR Port was
> randomized, I opened it on my router firewall. Then I restarted the
> tor service using "sudo service tor restart", and while watching logs
> I noticed the OR Port was now different, meaning I would need to
> update my firewall again.

You are correct, this was a mistake on my part.  For what it's worth, I
just filed  because of this.  Thanks
for bringing up this issue!

> Seems better to set a single port and leave it at that, doesn't it?

I agree, asking operators to choose their own OR and obfs4 port should
cause the least surprise.  It also serves as a reminder that both ports
need to be reachable for obfs4 to work.

I will update the obfs4 setup guide accordingly.

Cheers,
Philipp
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Call for setting up new obfs4 bridges

2019-07-08 Thread Philipp Winter
On Wed, Jul 03, 2019 at 02:38:03PM +, nottryingtobel...@protonmail.com 
wrote:
> Is it normal for bridges to see no traffic, and if they're not seeing
> any, should I keep them online?

A bit of background: When you set up a bridge, by default it reports
itself to BridgeDB, our system for bridge distribution.  Each bridge
falls in one of four BridgeDB "buckets": HTTPS, email, Moat, and
unallocated.  The unallocated bucket is the smallest of all four, and we
use it for manual distribution, meaning that we occasionally take these
bridges and hand them out to activists.  This doesn't happen often which
is why the unallocated bridges see the least use among all of BridgeDB's
bridges.  This is not ideal but it's the way things currently work.

There's a chance that your bridge ended up in the unallocated bucket but
it's unlikely that it did so four times in a row.  Since Tor version
0.3.2.3, you can express what bucket you want your bridge to be in, by
setting the BridgeDistribution option.

All that said, please feel free to send me your bridge info off-list.
I'll test it for you and check what bucket BridgeDB put it into, so
you'll see actual users this time.

Cheers,
Philipp
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Testing the accessibility of my obfs4 bridge

2019-07-08 Thread Philipp Winter
On Sat, Jul 06, 2019 at 04:31:10PM +, nottryingtobel...@protonmail.com 
wrote:
> I plugged my bridgeline into Tor Browser on Windows, and connected
> successfully. I put it into Orbot on Android and also connected
> successfully. But when I put it into the new Tor Browser for Android,
> I am unable to connect. The logs from Tor Browser are pasted here:
> https://pastebin.com/cF5bwRH1.

This seems related to the following bug:

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


[tor-relays] ExoneraTor results may be incomplete between April 25 and 30, 2019 and during other periods

2019-07-08 Thread Karsten Loesing
Hello relay operators,

it turns out that our exit scanner had an issue between April 25 and 29,
2019 and that ExoneraTor results may be incomplete during this time.

Some context, taken from the ExoneraTor page:

https://metrics.torproject.org/exonerator.html

"The ExoneraTor service maintains a database of IP addresses that have
been part of the Tor network. It answers the question whether there was
a Tor relay running on a given IP address on a given date. ExoneraTor
may store more than one IP address per relay if relays use a different
IP address for exiting to the Internet than for registering in the Tor
network, and it stores whether a relay permitted transit of Tor traffic
to the open Internet at that time."

Now, if somebody looks up their exit IP address during the time between
April 25 and 29, 2019, their relay won't be listed in the results. It
will still be included with the IP address that it used for registering
at the directory authorities, but not with its exit IP address.

I looked through the archive of exit lists and found similar downtimes
of 18 hours or longer which would have the same effect:

Gap of  19 hours between 2011-09-10T00:05:00 and 2011-09-10T19:28:46.
Gap of  23 hours between 2011-12-21T01:21:19 and 2011-12-22T00:23:36.
Gap of 111 hours between 2012-02-07T02:33:16 and 2012-02-11T18:07:47.
Gap of  26 hours between 2013-03-07T15:16:50 and 2013-03-08T17:17:55.
Gap of 156 hours between 2013-03-14T09:29:25 and 2013-03-20T22:03:41.
Gap of  19 hours between 2015-10-09T14:13:37 and 2015-10-10T09:57:26.
Gap of  18 hours between 2018-02-02T18:27:54 and 2018-02-03T13:06:09.
Gap of 122 hours between 2019-04-25T13:13:19 and 2019-04-30T15:40:21.
Gap of  21 hours between 2019-05-25T19:04:43 and 2019-05-26T16:09:23.

We're working on adding a notice to ExoneraTor results in case a lookup
falls into one of these periods, but that will take us some time.

https://trac.torproject.org/projects/tor/ticket/31071

Sorry for any confusions caused by this!

All the best,
Karsten



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays