[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #11211 [Core Tor/Tor]: Multiple ServerTransportListenAddr entries should be allowed per transport.
#11211: Multiple ServerTransportListenAddr entries should be allowed per transport.
-------------------------------------------------+-------------------------
Reporter: yawning | Owner:
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version: Tor:
| unspecified
Severity: Normal | Resolution:
Keywords: tor-bridge, pt, needs-proposal, | Actual Points:
tor-pt, bridgedb-parsers, 028-triage, ipv6, |
tor-03-unspecified-201612 |
Parent ID: #10629 | Points:
Reviewer: | Sponsor: T/U
-------------------------------------------------+-------------------------
Comment (by kaie):
I'm trying to contribute a fix for this issue.
Would it be acceptable to use a different configuration syntax, that uses
only a single line for each transport type, and allows multiple
address:port combinations to be listed on the line, separated by space, as
in the following example?
ServerTransportListenAddr obfs3 0.0.0.0:443 [::]:443
I discovered that the obfs4proxy tool already supports multiple addresses
for the same transport type, as it already parses a comma separated list
of type-address:port entries, which are passed to it by Tor in an
environment variable.
Looking at the Tor C code, it seems that many places assume that only a
single configuration line (and state line) is used for any given transport
type. My impression is, implementing the syntax I'm suggesting requires a
much smaller amount of code changes.
I'll attach an initial attempt to implement the above. It parses the above
syntax, it passes the extended list to the external transport tool. It
also saves extended TransportProxy lines into the state file, using the
same approach that keeps a single line and allows multiple addresses.
So far I've only tested with a test network, and only tested that the
listeners are created. I haven't done real world testing yet.
The code that loads and validates the state file only checks the first
stored address:port, and will use the additional saved entries without
validation. I've ran out of time today, this is a TODO.
Looking forward to your feedback.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11211#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs