Nathaniel Suchy wrote: > I switched over to a private obfs4 bridge on a VM I rented and the issue is resolved. Maybe the bridges were running an out of date Tor daemon? As for which services I tried to access: > > 1) A v3 service running Up1 on my Raspberry Pi (Didn't work), the v2 index page loads without an issue. > 2) A "chan" style website which used a v3 onion > > I think it's still worth investigating bugs with bridges and v3 services as when I'm not using bridges (or using my new private bridge) v3s work fine. > Cordially, > Nathaniel Suchy > We would investigate, but this provides no information that can help. 1. Why do you think the fault lied with that bridge you were using? Did you try any other v3 onion service using that bridge besides the ones hosted by you? Like one you know for sure it's up, like the one that was provided in an earlier reply to this thread? Was that not working also? 2. Do you have any log files from the Tor daemon when you were trying to access v3 onion services and you couldn't? 3. Give us the fingerprint of that bridge and obfs4 auth data so we can try to reproduce. Without any of these, this looks like just a simple mistake or something going wrong with your hosted v3 onion service at that particular moment. The Tor version that the bridge is using is irrelevant, v3 onion services need to be supported client <-> server side, so if your Tor version is recent enough as well as the server side (otherwise it cannot generate a v3 onion address at all, so the problem shouldn't even exist in this case) all the relays in the path do not matter as long as they are running a *supported* Tor version.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- 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