[tor-relays] obfs4 bridge management

[Christopher Sheats]

Hello,

I've has published a shell script for deploying and managing obfs4 
bridges, I hope its useful to others.


https://github.com/emeraldonion/bridge-management/

Feedback welcome!

--
yawnbox
https://disobey.net/@yawnbox
https://digitalcourage.social/@EmeraldOnion



OpenPGP_0x4D3394A723A57C0A.asc
Description: OpenPGP public key


OpenPGP_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] obfs4 bridge current setup is not entirely clear

[meskio]

Quoting s7r (2023-11-08 17:42:46)
> 1. The page at 
> https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs a 
> small revision.

Feel free to send a merge request to improve it:
https://gitlab.torproject.org/tpo/web/community/-/blob/main/content/relay/setup/bridge/debian-ubuntu/contents.lr?ref_type=heads

> 2. It was recommended on the mail list that obfs4 bridges should not open 
> their ORPorts publicly to prevent scanning the entire 1-65536 port range and 
> determine it's a Tor bridge. OK.
> 
> But if you try:
> 
> ORPort 127.0.0.1:auto
> ORPort [::1]:auto
> AssumeReachable 1 # needed to skip ORPort reachability test
> 
> Tor will start but it will constantly complain in the log with:
> 
> [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor 
> address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 
> 'Address ' and 'OutboundBindAddress '. If you are behind a 
> NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
>  NoAdvertise'.
> 
> [warn] The IPv6 ORPort address ::1 does not match the descriptor address 
> REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 
> 'Address ' and 'OutboundBindAddress '. If you are behind a 
> NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
>  NoAdvertise'.
> 
> I guess it's OK to continue to run it even with this as I do understand 
> the log messages and it's the desired effect, but isn't it confusing for 
> less experienced users? They might think something is wrong when it is not.

We are still working on supporting no publishing the ORPort. Is not bad to do 
it, but there are some quircks that we need to fix.

> 3. ServerTransportListenAddr can be used just once and it's difficult for 
> dual-stack which is now the vast majority.
> 
> It's known for many years that each pluggable transport supports just 
> one ServerTransportListenAddr line, the second one is simply ignored. 
> Tickets for this exist.
> 
> So what is the best way to for an user to open both IPv4 and IPv6 
> pluggable transport ports?

This is not currently supported, but there is some work done in that direction:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40885
.

-- 
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4 bridge current setup is not entirely clear

[boldsuck]

On Mittwoch, 8. November 2023 20:35:56 CET s7r wrote:
> boldsuck wrote:
> 
> > 
> > Not recommended, but rather a request to try it out.
> > 
> 
> 
> So I tried, and besides the log messages that I have a descriptor 
> mismatch I also get the status of my bridge as not running when ORPort 
> is not exposed. The minute I switched ORPort to `localhost` the BridgeDB 
> reported the bridge as not running, regardless it was actually running 
> with the pluggable transport port open.
> 

That is unfortunately the case. I checked whether they are online at:
https://bridges.torproject.org/status?id=[hashed_identity_key]
On Tor metrics you can also see that the history continues.

> > Some info in the old thread
> > https://lists.torproject.org/pipermail/tor-relays/2023-August/021259.html
> > 
> > Relevant tiket from meskio:
> > https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
> > 
> 
> 
> Thank you, yes.
> But unfortunately I think we are going to need a proposal for this, to 
> document various use cases and maybe clone the code that does the ORPort 
> reachability check to do pluggable transport port reachability test, 
> then build descriptor and then publish, but this needs ORPort like 
> behavior like NoListen, etc.
> 
That'd be good

> > I've gradually reconfigured _all_ bridges over the last 2 months:
> > The number of connections/users has stayed pretty much the same.
> > Bridges with setting "BridgeDistribution any" the distribution method has
> > not changed.
> > 
> > OrPort must forwarded or should not firewalled otherwise the status will
> > be dysfunctional on https://bridges.torproject.org/status
> > 
> 
> I don't care to use BridgeDistribution param, I let BridgeDB decide this 
> randomly

Me too. "BridgeDistribution any" is tor default setting.

> but configured without public open ORPort I don't get the 
> running flag, I get that bridge is down, while it's not actually.
> 
> 
> >> So what is the best way to for an user to open both IPv4 and IPv6
> >> pluggable transport ports?
> > 
> > 
> > The ServerTransportListenAddr line is dual stack friendly.
> > ServerTransportListenAddr obfs4 [::]:8443
> > 
> 
> 
> So I saw yes, I was able to use [::]:80 to bind to all interfaces in 
> dual stack mode but I am not sure the clients are served both the IPv6 
> line and the IPv4 line, I think it's just one of them and I was curious 
> which one and what logic is applied to determine it.
> This means that currently one cannot setup a dual stack pluggable 
> transport bridge, it must be either IPv4 either IPv6, right?
> 

If I use my dual stack bridges with TorBrowser or HS clients, I can use IP and 
IPv6.

2023-11-08 21:15:20.815 [NOTICE] Bridge 'ForPrivacyNET' has both an IPv4 and an 
IPv6 address.  Will prefer using its IPv6 address ([2001:db8:1::228]:11228) 
based on the configured Bridge address.
2023-11-08 21:15:21.712 [NOTICE] Bridge 'ForPrivacyNET' has both an IPv4 and an 
IPv6 address.  Will prefer using its IPv4 address (203.0.113.228:11228) based 
on the configured Bridge address.

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4 bridge current setup is not entirely clear

[s7r]

boldsuck wrote:


Not recommended, but rather a request to try it out.



So I tried, and besides the log messages that I have a descriptor 
mismatch I also get the status of my bridge as not running when ORPort 
is not exposed. The minute I switched ORPort to `localhost` the BridgeDB 
reported the bridge as not running, regardless it was actually running 
with the pluggable transport port open.



Some info in the old thread
https://lists.torproject.org/pipermail/tor-relays/2023-August/021259.html

Relevant tiket from meskio:
https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129



Thank you, yes.
But unfortunately I think we are going to need a proposal for this, to 
document various use cases and maybe clone the code that does the ORPort 
reachability check to do pluggable transport port reachability test, 
then build descriptor and then publish, but this needs ORPort like 
behavior like NoListen, etc.



[warn] The IPv6 ORPort address ::1 does not match the descriptor address
REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use
'Address ' and 'OutboundBindAddress '. If you are behind a
NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort
 NoAdvertise'.


Yes you can ignore the logs. Not exposing OrPort for bridges is still
experimental feature.

I've gradually reconfigured _all_ bridges over the last 2 months:
The number of connections/users has stayed pretty much the same.
Bridges with setting "BridgeDistribution any" the distribution method has not
changed.

OrPort must forwarded or should not firewalled otherwise the status will be
dysfunctional on https://bridges.torproject.org/status



I don't care to use BridgeDistribution param, I let BridgeDB decide this 
randomly but configured without public open ORPort I don't get the 
running flag, I get that bridge is down, while it's not actually.



So what is the best way to for an user to open both IPv4 and IPv6
pluggable transport ports?


The ServerTransportListenAddr line is dual stack friendly.
ServerTransportListenAddr obfs4 [::]:8443



So I saw yes, I was able to use [::]:80 to bind to all interfaces in 
dual stack mode but I am not sure the clients are served both the IPv6 
line and the IPv4 line, I think it's just one of them and I was curious 
which one and what logic is applied to determine it.


This means that currently one cannot setup a dual stack pluggable 
transport bridge, it must be either IPv4 either IPv6, right?




OpenPGP_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] obfs4 bridge current setup is not entirely clear

[boldsuck]

On Mittwoch, 8. November 2023 17:42:46 CET s7r wrote:

> 2. It was recommended on the mail list that obfs4 bridges should not 
> open their ORPorts publicly to prevent scanning the entire 1-65536 port 
> range and determine it's a Tor bridge. OK.

Not recommended, but rather a request to try it out.

Some info in the old thread
https://lists.torproject.org/pipermail/tor-relays/2023-August/021259.html

Relevant tiket from meskio:
https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129

> But if you try:
> 
> ORPort 127.0.0.1:auto
> ORPort [::1]:auto
> AssumeReachable 1 # needed to skip ORPort reachability test
> 
> Tor will start but it will constantly complain in the log with:
> 
> [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor 
> address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 
> 'Address ' and 'OutboundBindAddress '. If you are behind a 
> NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
>  NoAdvertise'.
> 
> [warn] The IPv6 ORPort address ::1 does not match the descriptor address 
> REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 
> 'Address ' and 'OutboundBindAddress '. If you are behind a 
> NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
>  NoAdvertise'.

Yes you can ignore the logs. Not exposing OrPort for bridges is still 
experimental feature.

I've gradually reconfigured _all_ bridges over the last 2 months:
The number of connections/users has stayed pretty much the same.
Bridges with setting "BridgeDistribution any" the distribution method has not 
changed.

OrPort must forwarded or should not firewalled otherwise the status will be 
dysfunctional on https://bridges.torproject.org/status

> So what is the best way to for an user to open both IPv4 and IPv6 
> pluggable transport ports?

The ServerTransportListenAddr line is dual stack friendly.
ServerTransportListenAddr obfs4 [::]:8443


-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] obfs4 bridge current setup is not entirely clear

[s7r]

Hi,

I ran into some new IP space and I decided to change a cluster of obfs4 
bridges that are more than 4 year old. When I set them up I don't 
remember spending so much time.


So, Debian latest and Tor latest from deb.torproject.org nightly.

GoLang from the official website (as it's the latest version) and 
obfs4proxy cloned from its default git repository.


1. The page at 
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs 
a small revision.


This page must be changed, for Debian it doesn't work simply $ edit 
tor@.service tor@default.service , change to NoNewPrivileges=no, save 
and quit.


For me it only worked by editing
/lib/systemd/system/tor@.service and 
/lib/systemd/system/tor@default.service with NoNewPrivileges=no and then:


$ sudo systemctl daemon-reload.

Setcap command is ok but it also need to mention to install the package 
in Debian libcap2-bin as well as an additional step:


Under Debian, if obfs4proxy is installed in a different place, for 
example like in its git documentation /usr/local/bin/obfs4proxy then you 
also need to edit this file:


/etc/apparmor.d/abstractions/tor

and add one line (or change the default obfs4proxy line to):

  /usr/local/bin/obfs4proxy Pix,

Substitute path if different and then:
$ sudo systemctl restart apparmor.



2. It was recommended on the mail list that obfs4 bridges should not 
open their ORPorts publicly to prevent scanning the entire 1-65536 port 
range and determine it's a Tor bridge. OK.


But if you try:

ORPort 127.0.0.1:auto
ORPort [::1]:auto
AssumeReachable 1 # needed to skip ORPort reachability test

Tor will start but it will constantly complain in the log with:

[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor 
address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 
'Address ' and 'OutboundBindAddress '. If you are behind a 
NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
 NoAdvertise'.


[warn] The IPv6 ORPort address ::1 does not match the descriptor address 
REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 
'Address ' and 'OutboundBindAddress '. If you are behind a 
NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
 NoAdvertise'.


I guess it's OK to continue to run it even with this as I do understand 
the log messages and it's the desired effect, but isn't it confusing for 
less experienced users? They might think something is wrong when it is not.


The recommended way is to add a simple logic to skip that check, because 
we can't remove it, it's vital necessary for relays (not bridges) behind 
NAT or dynDNS or whatever. So if BridgeRelay 1 is set and 
$some_transport enabled, ignore the ORPort and descriptor check / log. 
and instead check the pluggable transport if port open and listening.


Or even better, code a pluggable transport port reachability test before 
building and uploading the descriptor, by cloning the code that does 
this for ORPorts to the pluggable transport ports. This would need a 
proposal that covers all use cases.



3. ServerTransportListenAddr can be used just once and it's difficult 
for dual-stack which is now the vast majority.


It's known for many years that each pluggable transport supports just 
one ServerTransportListenAddr line, the second one is simply ignored. 
Tickets for this exist.


So what is the best way to for an user to open both IPv4 and IPv6 
pluggable transport ports?


In Debian I have achieved it by using as wildcard 
ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian 
binds to all IPv4 and IPv6 addresses on all interfaces, but this might 
not be the same for all operating systems.


Also, how does BridgeDB determine in case wildcard [::] is used if the 
pluggable transport is IPv4, IPv6 or both? Which one is used when 
BridgeDB sends this bridge to clients?




OpenPGP_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] obfs4 bridge port question

[torix]

Thank you all for your helpful replies.  Now that I know, RTFMx3 makes it seem 
obvious, but I was stumped.  --Torix


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, May 10, 2020 2:07 AM, Roger Dingledine  wrote:

> On Sat, May 09, 2020 at 01:15:46PM -0700, Eddie wrote:
>
> > > Bridge obfs4 :  cert= 
> > > iat-mode=0
> > > I have all the parts mentioned in the text except for .
> >
> > It's the port from this line:  ServerTransportListenAddr obfs4
> > 0.0.0.0: where the odfs4 is listening.
>
> Right. Or if you didn't set a ServerTransportListenAddr line in your
> torrc file, then you can get it either from the log line:
>
> [notice] Registered server transport 'obfs4' at '[::]:46396'
>
> or from a corresponding line the 'state' file in your DataDirectory.
>
> But really, if you didn't choose it via ServerTransportListenAddr, you
> probably haven't set up port forwarding for it, or made a hole for it
> in your firewall, or whatever you will need to do to make it reachable
> from the outside.
>
> You can test reachability for it using this tool that Philipp set up:
> https://bridges.torproject.org/scan/
>
> Bridges don't yet automatically test reachability for their obfs4 port
> (sad but true).
>
> Thanks!
> --Roger
>
> 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] obfs4 bridge port question

[teor]

Hi,

> On 10 May 2020, at 12:07, Roger Dingledine  wrote:
> 
> On Sat, May 09, 2020 at 01:15:46PM -0700, Eddie wrote:
>>> Bridge obfs4 :  cert= iat-mode=0
>>> I have all the parts mentioned in the text except for .
>>> 
>> It's the port from this line:  ServerTransportListenAddr obfs4
>> 0.0.0.0: where the odfs4 is listening.
> 
> Right. Or if you didn't set a ServerTransportListenAddr line in your
> torrc file, then you can get it either from the log line:
> 
> [notice] Registered server transport 'obfs4' at '[::]:46396'
> 
> or from a corresponding line the 'state' file in your DataDirectory.

Or you should be able to find the complete bridge line in:
DataDir/pt_state/obfs4_bridgeline.txt

https://github.com/Yawning/obfs4#tips-and-tricks

T

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

Re: [tor-relays] obfs4 bridge port question

[Roger Dingledine]

On Sat, May 09, 2020 at 01:15:46PM -0700, Eddie wrote:
> > Bridge obfs4 :  cert= iat-mode=0
> > I have all the parts mentioned in the text except for .
> >
> It's the port from this line:  ServerTransportListenAddr obfs4
> 0.0.0.0: where the odfs4 is listening.

Right. Or if you didn't set a ServerTransportListenAddr line in your
torrc file, then you can get it either from the log line:

[notice] Registered server transport 'obfs4' at '[::]:46396'

or from a corresponding line the 'state' file in your DataDirectory.

But really, if you didn't choose it via ServerTransportListenAddr, you
probably haven't set up port forwarding for it, or made a hole for it
in your firewall, or whatever you will need to do to make it reachable
from the outside.

You can test reachability for it using this tool that Philipp set up:
https://bridges.torproject.org/scan/

Bridges don't yet automatically test reachability for their obfs4 port
(sad but true).

Thanks!
--Roger

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

[tor-relays] obfs4 bridge port question

[torix]

I am looking at the post install instructions here after putting up my first 
bridge:
https://community.torproject.org/relay/setup/bridge/post-install/
and thought I would try out the bridgeline for it.

Bridge obfs4 :  cert= iat-mode=0

I have all the parts mentioned in the text except for .  I have ExtORPort 
set to auto, so I never picked a port in my torrc.
How do I get there from here?

TIA,

--Torix

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4 bridge port question

[Eddie]

On 5/9/2020 1:06 PM, to...@protonmail.com wrote:
I am looking at the post install instructions here after putting up my 
first bridge:

https://community.torproject.org/relay/setup/bridge/post-install/
and thought I would try out the bridgeline for it.
|Bridge obfs4 :  cert= 
iat-mode=0|
I have all the parts mentioned in the text except for .  I have 
ExtORPort set to auto, so I never picked a port in my torrc.

How do I get there from here?

TIA,

--Torix

It's the port from this line:  ServerTransportListenAddr obfs4 
0.0.0.0: where the odfs4 is listening.


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

[tor-relays] Obfs4 Bridge/Relay Issue

[texasbuckeye]

I have been trying to run a relay/obfs4 bridge from my Macbook (macOS Catalina 
10.15.1) for some time now. I want to do it to help out the Tor network - 
getting a Tor t-shirt would be a nice bonus. I've already donated to help out 
until I can get my bridge/relay up & running. I've been starting out with 
trying to run an obfs4 bridge with the intent to move to a full relay 
(non-exit) at a later date. I've tried setting up my ORPorts to 80, 443, 9050, 
auto, and many others. I use Bitdefender as my antivirus software (which 
doesn't really show open/closed/used ports; nor does the built-in firewall in 
System Preferences in macOS. Below is my torrc file and log files (from 
Console). If you see any mistakes or any reasons why I cannot get the obsf4 
bridge or relay to run please let me know. I have been trying to get this to 
work for a few months now. I upgraded to Tor 0.4.1.6 to see if that makes a 
difference and so far nothing has changed. Any assistance that you could give 
would be greatly appreciated. Thank you in advance for your assistance.


**

*_Torrc_:*

#Bridge config
RunAsDaemon 1
ORPort 80
ORPort 443
ORPort 9050
ORPort auto
BridgeRelay 1
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
# For a fixed obfs4 port (i.e. 9002), uncomment the following line.
#ServerTransportListenAddr obfs4 0.0.0.0:9002
# Local communication port between Tor and obfs4. Always set this to
"auto". "Ext" means
# "extended", not "external". Don't try to set a specific port number,
nor listen on 127.0.0.1
ExtORPort auto
ExitRelay 0
ExitPolicy reject *:* # no exits allowed

## Send all messages of level 'notice' or higher to
/opt/local/var/log/tor/notices.log
Log notice file /usr/local/var/log/tor/notices.log

# Contact information that allows us to get in touch with you in case of
# critical updates or problems with your bridge.  This is optional, so you
# don't have to provide an email address if you don't want to.
ContactInfo 0x4DD6289CAD37F299 
# Pick a nickname that you like for your bridge.
Nickname texasbuckeye

## Define these to limit how much relayed traffic you will allow. Your
## own traffic is still unthrottled. Note that RelayBandwidthRate must
## be at least 75 kilobytes per second.
## Note that units for these config options are bytes (per second), not
## bits (per second), and that prefixes are binary prefixes, i.e. 2^10,
## 2^20, etc.
RelayBandwidthRate 1000 KBytes  # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB (1600Kb)

--

*_Console_:*

Nov 23 17:34:12.000 [notice] Tor 0.4.1.6 opening log file.
Nov 23 17:34:12.475 [notice] Tor 0.4.1.6 running on Darwin with Libevent
2.1.11-stable, OpenSSL 1.0.2s, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Nov 23 17:34:12.476 [notice] Tor can't help you if you use it wrong!
Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 23 17:34:12.477 [notice] Read configuration file
"/usr/local/etc/tor/torrc".
Nov 23 17:34:12.481 [notice] Based on detected system memory,
MaxMemInQueues is set to 6553 MB. You can override this by setting
MaxMemInQueues by hand.
Nov 23 17:34:12.483 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 23 17:34:12.484 [notice] Opened Socks listener on 127.0.0.1:9050
Nov 23 17:34:12.484 [notice] Opening OR listener on 0.0.0.0:0
Nov 23 17:34:12.484 [notice] OR listener listening on port 57054.
Nov 23 17:34:12.484 [notice] Opened OR listener on 0.0.0.0:57054
Nov 23 17:34:12.485 [notice] Opening OR listener on 0.0.0.0:9050
Nov 23 17:34:12.485 [notice] Opened OR listener on 0.0.0.0:9050
Nov 23 17:34:12.485 [notice] Opening OR listener on 0.0.0.0:443
Nov 23 17:34:12.485 [notice] Opened OR listener on 0.0.0.0:443
Nov 23 17:34:12.485 [notice] Opening Extended OR listener on 127.0.0.1:0
Nov 23 17:34:12.486 [notice] Extended OR listener listening on port 57055.
Nov 23 17:34:12.486 [notice] Opened Extended OR listener on 127.0.0.1:57055
Nov 23 17:34:14.000 [notice] Parsing GEOIP IPv4 file
/usr/local/Cellar/tor/0.4.0.5_1/share/tor/geoip.
Nov 23 17:34:14.000 [notice] Parsing GEOIP IPv6 file
/usr/local/Cellar/tor/0.4.0.5_1/share/tor/geoip6.
Nov 23 17:34:14.000 [notice] Configured to measure statistics. Look for
the *-stats files that will first be written to the data directory in 24
hours from now.
Nov 23 17:34:14.000 [notice] Your Tor server's identity key fingerprint
is //
Nov 23 17:34:14.000 [notice] Your Tor bridge's hashed identity key
fingerprint is //
Nov 23 17:34:14.000 [notice] Bootstrapped 0% (starting): Starting
Nov 23 17:34:20.000 [notice] Starting with guard context "default"
Nov 23 17:34:20.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Nov 23 17:34:21.000 [notice] Bootstrapped 10% (conn_done): Connected to
a relay
Nov 23 

Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap

[skarz]

When I was running a bridge on my Raspberry Pi the only success I had was when 
I compiled from source. Don’t be overwhelmed, the instructions are very easy to 
follow.

https://2019.www.torproject.org/docs/debian.html.en

On Tue, Oct 8, 2019 at 4:16 AM, Alexander Dietrich  
wrote:

> You can use "deb.torproject.org" in Raspbian:
> https://support.torproject.org/apt/tor-deb-repo/
>
>> Volker Mink  hat am 8. Oktober 2019 um 08:29 geschrieben:
>>
>> Could be, i am not so deep into this whole linux-magic.
>> Its raspian stretch with kernel 4.19.66 on a PI2B, which is -as far as i 
>> know- from august 2019.
>>
>> apt install tor offers me tor version 2.9.6.xx, enabling the experimental 
>> from debian-stack offers 0.3.4.x
>>
>> Any idea how to get a newer version?
>>
>> Gesendet: Dienstag, 08. Oktober 2019 um 01:09 Uhr
>> Von: "Roger Dingledine" 
>> An: tor-relays@lists.torproject.org
>> Betreff: Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap
>> On Mon, Oct 07, 2019 at 11:09:53PM +0200, Volker Mink wrote:
>>> After a fresh installation syslog is full with entries like this:
>> [...]
>>> Oct 7 23:05:09 pi-hole systemd[1]: Failed to start Anonymizing 
>>> overlay network for TCP.
>>
>> My next guess is that you have an old-style raspbian, with an old
>> arm-based cpu architecture that is not compatible with modern Debian, but
>> you have installed the modern Debian tor deb. If that's what's happening,
>> the binary won't run because it's for a different arch.
>>
>> Now your quest has simplified to "get Tor running at all, by figuring
>> out what operating system you're actually running, and finding an
>> up-to-date Tor package that is intended for that operating system." :)
>>
>> --Roger
>>
>> ___
>> 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___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap

[Alexander Dietrich]

You can use "deb.torproject.org" in Raspbian:
https://support.torproject.org/apt/tor-deb-repo/


> Volker Mink  hat am 8. Oktober 2019 um 08:29 geschrieben:
> 
> Could be, i am not so deep into this whole linux-magic.
> Its raspian stretch with kernel 4.19.66 on a PI2B, which is -as far as i 
> know- from august 2019.
> 
> apt install tor offers me tor version 2.9.6.xx, enabling the experimental 
> from debian-stack offers 0.3.4.x
> 
> Any idea how to get a newer version?
>  
> 
> 
>   Gesendet: Dienstag, 08. Oktober 2019 um 01:09 Uhr
>   Von: "Roger Dingledine" 
>   An: tor-relays@lists.torproject.org
>   Betreff: Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap
> 
>   On Mon, Oct 07, 2019 at 11:09:53PM +0200, Volker Mink wrote:
>   > After a fresh installation syslog is full with entries like 
> this:
>   [...]
>   > Oct 7 23:05:09 pi-hole systemd[1]: Failed to start Anonymizing 
> overlay network for TCP.
> 
>   My next guess is that you have an old-style raspbian, with an old
>   arm-based cpu architecture that is not compatible with modern Debian, 
> but
>   you have installed the modern Debian tor deb. If that's what's 
> happening,
>   the binary won't run because it's for a different arch.
> 
>   Now your quest has simplified to "get Tor running at all, by figuring
>   out what operating system you're actually running, and finding an
>   up-to-date Tor package that is intended for that operating system." :)
> 
>   --Roger
> 
>   ___
>   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
> 


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

Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap

[Volker Mink]

Could be, i am not so deep into this whole linux-magic.
Its raspian stretch with kernel 4.19.66 on a PI2B, which is -as far as i know- from august 2019.

 

apt install tor offers me tor version 2.9.6.xx, enabling the experimental from debian-stack offers 0.3.4.x

 

Any idea how to get a newer version?

 

Gesendet: Dienstag, 08. Oktober 2019 um 01:09 Uhr
Von: "Roger Dingledine" 
An: tor-relays@lists.torproject.org
Betreff: Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap

On Mon, Oct 07, 2019 at 11:09:53PM +0200, Volker Mink wrote:
> After a fresh installation syslog is full with entries like this:
[...]
> Oct 7 23:05:09 pi-hole systemd[1]: Failed to start Anonymizing overlay network for TCP.

My next guess is that you have an old-style raspbian, with an old
arm-based cpu architecture that is not compatible with modern Debian, but
you have installed the modern Debian tor deb. If that's what's happening,
the binary won't run because it's for a different arch.

Now your quest has simplified to "get Tor running at all, by figuring
out what operating system you're actually running, and finding an
up-to-date Tor package that is intended for that operating system." :)

--Roger

___
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] obfs4 bridge stuck at 0% bootstrap

[Roger Dingledine]

On Mon, Oct 07, 2019 at 11:09:53PM +0200, Volker Mink wrote:
> After a fresh installation syslog is full with entries like this:
[...]
> Oct 7 23:05:09 pi-hole systemd[1]: Failed to start Anonymizing overlay 
> network for TCP.

My next guess is that you have an old-style raspbian, with an old
arm-based cpu architecture that is not compatible with modern Debian, but
you have installed the modern Debian tor deb. If that's what's happening,
the binary won't run because it's for a different arch.

Now your quest has simplified to "get Tor running at all, by figuring
out what operating system you're actually running, and finding an
up-to-date Tor package that is intended for that operating system." :)

--Roger

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

Re: [tor-relays] obfs4 bridge stuck at 0% bootstrap

[Roger Dingledine]

On Mon, Oct 07, 2019 at 04:56:32PM +0200, Volker Mink wrote:
> I am running an OBFS4 Bridge at home for a while now.
> 
> But everytime im looking in the logs it says
> # [notice] Bootstrapped 0%: Starting

Hi Volker,

Three suggestions:

(A) Upgrade to a newer version of Tor. Tor 0.2.9.x is way way old
at this point, and it's missing a bunch of fixes.
https://community.torproject.org/relay/setup/

(B) Try bootstrapping it as a happy bridge without obfs4 first, to
make sure that part works. Then you can add obfs4 back in.

(C) You might want to discard the current bridge identity key, now that
you've sent it to the list. (With knowledge of your identity key, once
the bridge is working, people can go to the bridge directory authority
and fetch your descriptor, learning your IP address.)

Thanks!
--Roger

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

Re: [tor-relays] Obfs4 Bridge Advertised Bandwidth

[Aneesh Dogra]

Due to the data your relay provides. If your relay gets popular I think it
will get the speed it deserves.


On Fri, May 18, 2018 at 10:32 PM,  wrote:

> Hello,
> I am running a bridge and I have my RelayBandwidthRate set to 1024 KB (8
> Mbps). However, the Relay Search page never shows the full Advertised
> Bandwidth. Right now it is showing 259 KiB/s. Sometimes it creeps higher
> but not by much. Just wondering what the reason for that big of a
> difference would be. Thanks!
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>


-- 
Regardless, I hope you're well and happy -
Aneesh
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Obfs4 Bridge Advertised Bandwidth

[nottryingtobelame]

Hello,
I am running a bridge and I have my RelayBandwidthRate set to 1024 KB (8 Mbps). 
However, the Relay Search page never shows the full Advertised Bandwidth. Right 
now it is showing 259 KiB/s. Sometimes it creeps higher but not by much. Just 
wondering what the reason for that big of a difference would be. Thanks!___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] OBFS4 Bridge

[pvr6]

>
>> On 13 Oct 2016, at 10:53, p...@sigaint.org wrote:
>>
...
>>
>> ServerTransportPlugin obfs3 exec /usr/bin/obfs4proxy managed
>
> "teor"  wrote:
> Here, you ask obfs4proxy yo of obfs3 for you, but not obfs4.
> Try obfs3,obfs4 instead.
>
> And then give tor browser the full line from the bridge line
> file in the obfs4proxy directory (the exact file name is in
> the obfs4proxy readme).
>
Thank you! I did have obf3,obfs4 exec in there while testing but I was
trying to put the obfs4 bridge into the client the same way I always had
for obfs3 and that did not work. Putting in the right info of:
obfs4 :  cert=[certstring] iat-mode=0
got it working right away once I saw it wanted the server's ID key
fingerprint instead of the bridge's.
Left the obfs4 proxy running this time!


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

Re: [tor-relays] OBFS4 Bridge

[teor]

> On 13 Oct 2016, at 10:53, p...@sigaint.org wrote:
> 
> Have been running an obfs3 bridge for a while. Since I was building a new
> Debian server wanted to add obfs4, but when I configure TBB to point to
> the obfs4 port [Z] I get "general SOCKS failure" in the TBB log. Changing
> it back to use obfs3 and port [Y] works fine. How can I fix it so obfs4
> works too?
> 
> Here are the relevant lines from torrc:
> ---
> ORPort [X]
> 
> BridgeRelay 1
> PublishServerDescriptor bridge
> 
> ServerTransportPlugin obfs3 exec /usr/bin/obfs4proxy managed

Here, you ask obfs4proxy yo of obfs3 for you, but not obfs4.
Try obfs3,obfs4 instead.

And then give tor browser the full line from the bridge line
file in the obfs4proxy directory (the exact file name is in
the obfs4proxy readme).

T

> ServerTransportListenAddr obfs3 0.0.0.0:[Y]
> ServerTransportListenAddr obfs4 0.0.0.0:[Z]
> ExtORPort auto
> ---
> 
> If I do netstat -pan, I see obfs4proxy is listening on both ports on all
> interfaces. I tried to add "--log-file logfile" after /usr/bin/obfs4proxy
> in torrc but then it wouldn't start the proxy at all. I'm not finding any
> other log messages showing a problem. Tor's log is clean, just shows it
> starting both proxy instances (which netstat confirms.) Obfs4proxy is the
> packaged version 0.0.6.
> 
> Not sure where else to look or change. I'd like to get it working but have
> commented out the obfs4 line for now.
> 
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
--









signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] OBFS4 Bridge

[pvr6]

Have been running an obfs3 bridge for a while. Since I was building a new
Debian server wanted to add obfs4, but when I configure TBB to point to
the obfs4 port [Z] I get "general SOCKS failure" in the TBB log. Changing
it back to use obfs3 and port [Y] works fine. How can I fix it so obfs4
works too?

Here are the relevant lines from torrc:
---
ORPort [X]

BridgeRelay 1
PublishServerDescriptor bridge

ServerTransportPlugin obfs3 exec /usr/bin/obfs4proxy managed
ServerTransportListenAddr obfs3 0.0.0.0:[Y]
ServerTransportListenAddr obfs4 0.0.0.0:[Z]
ExtORPort auto
---

If I do netstat -pan, I see obfs4proxy is listening on both ports on all
interfaces. I tried to add "--log-file logfile" after /usr/bin/obfs4proxy
in torrc but then it wouldn't start the proxy at all. I'm not finding any
other log messages showing a problem. Tor's log is clean, just shows it
starting both proxy instances (which netstat confirms.) Obfs4proxy is the
packaged version 0.0.6.

Not sure where else to look or change. I'd like to get it working but have
commented out the obfs4 line for now.



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