Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1 - 3.4.1 seems ok
On 10/23/21 12:41 AM, Felix wrote: Toralf, it would be super nice if you could check on your end, or somebody else can confirm? Hi, we here in Gentoo decided to stop supporting LibreSSL, so I cannot tell you if it would work here or not. -- Toralf ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1 - 3.4.1 seems ok
On 10/22/21 18:41, Felix wrote: Hi All Libressl 3.4.1 (devel) seems to run for us. I don't have the exact commit(s), but this LibreSSL issue was fixed many months ago in OpenBSD snapshots, which everyone is now seeing with the more recent LibreSSL releases and the release of OpenBSD 7.0 a few weeks ago. g Oct 22 21:06:26.894 [notice] Tor 0.4.6.7 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.4.1, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.5.0 and Unknown N/A as libc. Am 20.09.2020 um 14:32 schrieb Toralf Förster: On 9/20/20 12:57 PM, Felix wrote: Please somebody can _confirm_ this thing? Much more worse: The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%. I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1. Will roll back to 3.2.0 here Toralf, it would be super nice if you could check on your end, or somebody else can confirm? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1 - 3.4.1 seems ok
Hi All Libressl 3.4.1 (devel) seems to run for us. Oct 22 21:06:26.894 [notice] Tor 0.4.6.7 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.4.1, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.5.0 and Unknown N/A as libc. Am 20.09.2020 um 14:32 schrieb Toralf Förster: On 9/20/20 12:57 PM, Felix wrote: Please somebody can _confirm_ this thing? Much more worse: The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%. I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1. Will roll back to 3.2.0 here Toralf, it would be super nice if you could check on your end, or somebody else can confirm? -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
Hey, following up on my still persisting openbsd issue (https://lists.torproject.org/pipermail/tor-relays/2020-July/018717.html) I reckon this might also a libressl issue. I did as Roger suggested and set "usebridges 1 bridge ip:orport" > Tor[17665]: connection_or_init_conn_from_address(): init conn from address > 192.68.11.219: , (1) > Tor[17665]: connection_or_set_identity_digest(): Set identity digest for > 0x320be2f8110 ([scrubbed]): . > Tor[17665]: connection_or_set_identity_digest():(Previously: > ) > Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_state ( chan=1 proxy_type=0 state=1>) from orconn_event, on orconn. > Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_state ( chan=1 proxy_type=0 state=1>) from orconn_event, on orconn: > Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. > Tor[17665]: bto_state_rcvr(): ORCONN gid=4 chan=1 proxy_type=0 state=1 > Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_status ( status=0 reason=0>) from orconn_event, on orconn. > Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_status ( status=0 reason=0>) from orconn_event, on orconn: > Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. > Tor[17665]: connection_connect(): Connecting to [scrubbed]:443. > Tor[17665]: connection_connect_sockaddr(): Connection to socket in progress > (sock 9). > Tor[17665]: connection_add_impl(): new conn type OR, socket 9, address > 192.68.11.219, n_conns 4. > Tor[17665]: channel_tls_connect(): Got orconn 0x320be2f8110 for channel with > global id 1 > Tor[17665]: channel_register(): Registering channel 0x320be0a4ae0 (ID 1) in > state opening (1) with digest > Tor[17665]: channel_register(): Channel 0x320be0a4ae0 (global ID 1) in state > opening (1) registered with no identity digest > Tor[17665]: channel_set_cell_handlers(): Setting cell_handler callback for > channel 0x320be0a4ae0 to 0x320bca217e0 > Tor[17665]: dispatch_send_msg_unchecked(): Queued: ocirc_chan ( onehop=1>) from ocirc_event, on ocirc. > Tor[17665]: dispatcher_run_msg_cbs(): Delivering: ocirc_chan ( onehop=1>) from ocirc_event, on ocirc: > Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. > Tor[17665]: bto_chan_rcvr(): ORCONN LAUNCH chan=1 onehop=1 > Tor[17665]: bto_update_best(): ORCONN BEST_ANY state -1->1 gid=4 > Tor[17665]: Bootstrapped 5% (conn): Connecting to a relay > Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. > Tor[17665]: btc_chan_rcvr(): CIRC gid=1 chan=1 onehop=1 > Tor[17665]: circuit_handle_first_hop(): connecting in progress (or > finished). Good. > Tor[17665]: conn_read_callback(): socket -1 wants to read. > Tor[17665]: connection_edge_process_inbuf(): data from edge while in > 'waiting for circuit' state. Leaving it on buffer. > Tor[17665]: connection_edge_process_inbuf(): data from edge while in > 'waiting for circuit' state. Leaving it on buffer. > Tor[17665]: connection_dir_finished_flushing(): client finished sending > command. > Tor[17665]: conn_write_callback(): socket 9 wants to write. > Tor[17665]: connection_or_finished_connecting(): OR connect() to router at > 192.68.11.219:443 finished. > Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_state ( chan=1 proxy_type=0 state=3>) from orconn_event, on orconn. > Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_state ( chan=1 proxy_type=0 state=3>) from orconn_event, on orconn: > Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. > Tor[17665]: bto_state_rcvr(): ORCONN gid=4 chan=1 proxy_type=0 state=3 > Tor[17665]: bto_update_best(): ORCONN BEST_ANY state 1->3 gid=4 > Tor[17665]: Bootstrapped 10% (conn_done): Connected to a relay > Tor[17665]: connection_tls_start_handshake(): starting TLS handshake on fd 9 > Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 > (before SSL initialization) > Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in > state before SSL initialization [type=16,val=1]. > Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in > state before SSL initialization [type=4097,val=1]. > Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in > state SSLv3/TLS write client hello [type=4097,val=1]. > Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in > state SSLv3/TLS write client hello [type=4098,val=-1]. > Tor[17665]: tor_tls_handshake(): After call, 0x320be24e490 was in state > SSLv3/TLS write client hello > Tor[17665]: connection_tls_continue_handshake(): wanted read > Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 > (SSLv3/TLS write client hello) > Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in > state SSLv3/TLS write client hello
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
On 9/20/20 12:57 PM, Felix wrote: > > Please somebody can _confirm_ this thing? Much more worse: The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%. I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1. Will roll back to 3.2.0 here -- Toralf 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
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
On 9/20/20 12:57 PM, Felix wrote: >> > Libressl 321 is not compatible to what is needed to make the authorities > tor26, dizum, gabel., maatu. and longc. happy (let them not grant a > "Running"). What can that be? Just upgraded here 2 tor-0.4.5.0 (Gentoo Linux, same ip) from 3.2.0 to 3.2.1 Will see how it works by restarting one of the two Tor instances... -- Toralf 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
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
On Sun, Sep 20, 2020 at 12:57:46PM +0200, Felix wrote: > Libressl 321 is not compatible to what is needed to make the authorities > tor26, dizum, gabel., maatu. and longc. happy (let them not grant a > "Running"). What can that be? > > Please somebody can _confirm_ this thing? You're not crazy. We had a user on irc reporting a similar thing, and my guess at the time was also "libressl compatibility issue". You can see it also by using a Tor client and setting "usebridges 1 bridge ip:port" where ip:port is your ORPort. If it's like the user from irc, it will get almost through the TLS handshake but not quite. That is, the Tor client will fail to bootstrap. If you could open a gitlab issue for the mystery, that would be great! --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Dropped off consensus (0.4.4.5) - reason is Libressl 3.2.1
Hi everybody Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 2 hours after Libressl 321 -> 320 Sep 20 10:30:45.633 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.0, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 FastRun Stab V2Dir Valid bw=566 tor26 FastRun Stab V2Dir Valid dizum FastRun Stab V2Dir Valid gabel. FastRun Stab V2Dir Valid bw=1130 danne. Fast -Guard Run Stab V2Dir Valid maatu. FastRun Stab V2Dir Valid bw=1200 farav. Fast -Guard Run Stab V2Dir Valid bw=2970 longc. !Fast Run Stab V2Dir Valid bw=70 bastet Fast -Guard Run Stab V2Dir Valid bw=3520 OWNER :: bwauth=gabelmoo (Yeah, some Lib stuff is new too, hehe) Libressl 321 is not compatible to what is needed to make the authorities tor26, dizum, gabel., maatu. and longc. happy (let them not grant a "Running"). What can that be? Please somebody can _confirm_ this thing? PS: We had the same trouble with Libressl 292 when 28x worked well and 30x too. PPS: Is that a good reason to stay away from automated updates? Ok, Libressl 321 is -devel -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Dropped off consensus (0.4.4.5)
Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
