[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Are 'StrictNodes 1' actually strict?



It was my error. I think the issue was that my 'torrc' file was taken from
an earlier version of the TBB.

Installing the latest version again (even though I was already using
9.0.4) with a new 'torrc' allows me to set ExitNodes 'whatever' and the
TBB does stick to that exitnode.

Thank you for your advice and time.


On Mon, February 3, 2020 4:31 am, Roger Dingledine wrote:
> On Mon, Feb 03, 2020 at 01:14:39AM -0000, mimble9@xxxxxxxxxxxxx wrote:
>
>> I don't want to come across as critical but ExitNodes with one node
>> just doesn't work.
>>
>> Looking at the Tor Circuits, it starts with 'hands' but then moves on
>> to other exit nodes.
>>
>> My torrc is simply:
>>
>>
>> ExitNodes hands
>>
>
> Your next step is to make a series of steps that are (a) as simple as
> possible, and (b) as consistently repeatable as possible, and that still
> show your bug.
>
> That is, try to remove as many variables as possible -- visit a very
> boring website that has only one IP address and doesn't pull in ads and
> other dynamic stuff. Definitely avoid Cloudflare-hosted sites, or
> CDN-hosted sites in general. Avoid onion services, because they don't
> exit. If possible, view the Tor controller events yourself (not just
> relying on Tor Launcher's visualization). If possible, reproduce the bug
> outside of Tor Browser entirely, with just your Tor client and making
> requests to it with curl or the like. Reproduce it on a variety of exit
> relays. Basically, you want to rule out as many other factors as
> possible, to get the simplest possible "if I do these steps, it breaks
> every time" test case. Once you have that very simple scenario, please
> file a ticket on trac.
>
> Or if it breaks on the complex scenarios, and doesn't break on the simple
>  scenarios, then that gives you a direction to investigate.
>
> The "hands" exit relay is indeed an exit relay, but it is heavily rate
> limited, so I would expect that requests that use it will take a long time,
> time out more frequently, etc. So maybe having it as a performance
> bottleneck is helping to expose some bug.
>
> --Roger
>
>
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or
> change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
>


-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk