Custom Query (24215 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 24215)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#23959 invalid Задолбало ваше пидарство! avn
Description

Доброе время суток!

У меня складывается стойкое впечатление, что вы и ваша анонимная сеть TOR работаете на мировые спецслужбы, т. к.:

  1. Происходит очевидный перехват трафика TOR, что проявляется в

длительном первоначальном установлении соединений, длительность ожидания может быть несколько минут, а также в периодических частых сбросах соединений!!!

  1. Для Ubuntu 16.04 снова не работают obfs4proxy и обычные мосты для

сборки TOR daemon!!! Как же вы заебали с вашим пидарством, уроды!!! У вас кривые руки или вы сознательно это делаете? А может вы предоставляете исходные тексты спецслужбам и они мне подсовывают сборку TORa, собранную спецслужбами, а не вами? Я, если честно, больше объяснений не нахожу.

  1. Когда у вас начнут расти руки не из вашей жопы, а из нужного места?

Или вам за это хорошо платят мировые спецслужбы?

Жду от вас, хитрожопые, ответа!

Никитушкин Андрей.

#6816 fixed {connection_or,channel}_flush_from_first_active_circuit() should pick a new circuit for each cell andrea
Description

Before channels, this function was always called with max == 1; during the course of testing channels I discovered that it is broken with max > 1.

We pick cell_ewma once per invocation:

https://gitweb.torproject.org/tor.git/blob/75c9ccd4f851bac6d32cb08ded557ac207bc8002:/src/or/relay.c#l2412

Then once per cell, we pop the head of the pqueue and re-add it (to get it to its new correct position):

https://gitweb.torproject.org/tor.git/blob/75c9ccd4f851bac6d32cb08ded557ac207bc8002:/src/or/relay.c#l2479

... but if the new position is not the head of the queue, we don't change cell_ewma and we continue sending from the same circuit - and then the assert fails the next time around.

This function should be refactored to not do this and to separate the policy choice of what priority order to impose on circuits from the mechanism of picking a circuit, pulling cells off it and sending them down the wire.

#19191 fixed {BUG} directory_send_command: Bug: Squid does not like URLs longer than 4095 bytes, and this one is 20515 bytes long nickm fk
Description

After upgrading the relay 40A60D1F1E8AFBED22FCB30B3FBE2E275A14CF99 to Tor v0.2.8.3-alpha I got the following warning after starting:

May 27 14:02:26.111 [warn] {BUG} directory_send_command: Bug: Squid does not like URLs longer than 4095 bytes, and this one is 20515 bytes long: /tor/server/d/0E2ED00342161B68622BDF90623068BD9FF56890+0E3A7F3C5F[...]

It was repeated a couple of times with slightly different paths.

This relay was previously running 0.2.7.6, but I'm also using 0.2.8.2-alpha on other systems and haven't seen the warnings there.

I'm not sure if there's a connection, but bootstrapping did not make it beyond 80%.

Enabling debug logging resulted in lots of messages like:

May 27 14:27:16.604 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.605 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.605 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.606 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.606 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.607 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.607 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.608 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:27.346 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:30.560 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:33.302 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:33.717 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.

Tor is running in an ElectroBSD jail without raw socket access (which is probably required for the UDP socket magic to work).

After adding the Address directive bootstrapping worked and the relay is currently serving traffic.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.