Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:41:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/30299Switch network interface2020-06-13T15:41:01ZTracSwitch network interfaceI have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set t...I have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set to redirect DNS packets to IP:
127.0.0.1
After following the standard OpenVPN configuration, I make a connection to the VPN server with:
openvpn --config /etc/openvpn/servers-conf/01.example.tcp.ovpn
The problem is Tor receives the DNS UDP packets, converts them to TCP packets and then attempts to send them through my main "naked" network interface to Tor relays, instead of using the secure tun0 interface. OpenVPN sees the TCP packet leaving the "naked" interface and thinks this is not safe and blocks them, which means I'm not able to resolve domain names as Tor's DNS TCP packets can't leave the system.
In order to fix this, I have to restart Tor using:
systemctl restart tor
This then updates Tor to connect to tun0 and everything works fine again however, it would make sense to have Tor update automatically or to have an option to specify a network interface order for Tor to connect to. Example:
InterfacePref: tun0, tun1, eth0
Similar to a bootloader selecting what to boot first, this means Tor would always try to connect to tun0 if available, if not it will try tun1 and else eth0. If at any time a better interface comes up Tor should switch to it automatically. A default value would still connect to the default interface as it does today.
**Trac**:
**Username**: enriquejr99Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26889torsocks: option to disable all network traffic2020-06-13T16:09:59ZTractorsocks: option to disable all network trafficI've already talked to dgoulet about this:
I would love an option to make torsocks disable all network traffic. There are many good use cases to run applications without Internet communication. For example, commands in mailcap(4) to dis...I've already talked to dgoulet about this:
I would love an option to make torsocks disable all network traffic. There are many good use cases to run applications without Internet communication. For example, commands in mailcap(4) to display non-text.
This is a classic job for (application) firewalls, but torsocks has all the functionality already, f.e. if used with an invalid --port where no Tor or proxy is actually listening. But this is an ugly hack.
A --disable-network option would be very easy for torsocks, and very useful. Of course, it's low priority.
**Trac**:
**Username**: ilfhttps://gitlab.torproject.org/legacy/trac/-/issues/23122anonbib: add Loopix paper2020-06-13T17:25:04Zdawuudanonbib: add Loopix paper
Dear Administrators of Anonbib,
Please add the Loopix paper to anonbib...
I see that you've got all the bibtex entries in a git repo... but i wasn't sure how to present a merge request and so instead here's the new bibtex entry :
``...
Dear Administrators of Anonbib,
Please add the Loopix paper to anonbib...
I see that you've got all the bibtex entries in a git repo... but i wasn't sure how to present a merge request and so instead here's the new bibtex entry :
```
@article{piotrowska2017loopix,
title={The Loopix Anonymity System},
author={Piotrowska, Ania and Hayes, Jamie and Elahi, Tariq and Meiser, Sebastian and Danezis, George},
journal={arXiv preprint arXiv:1703.00536},
url={https://arxiv.org/pdf/1703.00536},
year={2017},
www_section = comm,
www_pdf_url = "www0.cs.ucl.ac.uk/staff/G.Danezis/papers/loopix.pdf",
www_tags={selected}
}
```https://gitlab.torproject.org/legacy/trac/-/issues/17956Let tor handle disconnects better2020-06-13T14:53:07ZTracLet tor handle disconnects betterHi all
I noticed a problem with Tor over unstable WLan/Wifi.
Everytime my laptop takes more than 5 seconds to reconnect to the wireless, the tor client idles until the active cyrcle reaches its 10 minutes limit.
Workaround: restart or ...Hi all
I noticed a problem with Tor over unstable WLan/Wifi.
Everytime my laptop takes more than 5 seconds to reconnect to the wireless, the tor client idles until the active cyrcle reaches its 10 minutes limit.
Workaround: restart or reload the tor-deamon
Regards dns2utf8
OS: Arch Linux amd64
**Trac**:
**Username**: dns2utf8Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16120Detect if the network goes down2020-06-13T14:46:24ZDavid Gouletdgoulet@torproject.orgDetect if the network goes downImplement a way for tor to detect if the network went down. This has multiple use cases (see list of tickets), one for instance is being able to differenciate between "We couldn't connect to a Guard because the Guard is down" vs "We coul...Implement a way for tor to detect if the network went down. This has multiple use cases (see list of tickets), one for instance is being able to differenciate between "We couldn't connect to a Guard because the Guard is down" vs "We couldn't connect because the network is down". For a more thorough discussion about Guard and network connectivity: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
Furthermore, this also makes a difference when we want to either keep a circuit or kill it depending on if the network went down or not.
We can get this kind of information from the OS, we need an API generic enough that allows us to build a compat layer for each OS. Let's also make sure it's integrated with the latest control command `GETINFO network-liveness` and the event `NETWORK_LIVENESS`.
Tickets that could benefit from this: #8239, #12595Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15765Tor doesn't reconnect automatically when tun/tap device goes down.2020-06-13T14:45:29ZcypherpunksTor doesn't reconnect automatically when tun/tap device goes down.1. Tor is connecting via tun/tap's Internet(such as company VPN).
2. If tun/tap goes down, the Internet will fall back to ethX.
3. Tor doesn't reconnect automatically. <WTF>
4. After a few minutes later, tun/tap was enabled again.
5. Tor...1. Tor is connecting via tun/tap's Internet(such as company VPN).
2. If tun/tap goes down, the Internet will fall back to ethX.
3. Tor doesn't reconnect automatically. <WTF>
4. After a few minutes later, tun/tap was enabled again.
5. Tor doesn't reconnect automatically. <WTF>Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/10093network map not working on 0.2.4.17rc - geoip2020-06-13T02:39:47ZTracnetwork map not working on 0.2.4.17rc - geoipvidalia-relay-bundle-0.2.4.17-rc-0.2.21.exe on XP
on Tor Network Map:
No connections show in the panel under the map
no points or routes show on the map
The country flag column is all "?"
**Trac**:
**Username**: BugMagnetvidalia-relay-bundle-0.2.4.17-rc-0.2.21.exe on XP
on Tor Network Map:
No connections show in the panel under the map
no points or routes show on the map
The country flag column is all "?"
**Trac**:
**Username**: BugMagnetTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/10024Close and open sockets on IP change, tracking2020-06-13T14:32:44ZgrarpampClose and open sockets on IP change, trackingFor hosts that have dynamic/roaming/dhcp/manual IP changes, is there
a controller toggle that will cause Tor to shut down all external
TCP/UDP connections and state... and then start fresh ones upon the
user toggling Tor back up after an...For hosts that have dynamic/roaming/dhcp/manual IP changes, is there
a controller toggle that will cause Tor to shut down all external
TCP/UDP connections and state... and then start fresh ones upon the
user toggling Tor back up after an IP change? Seems that
without that, having TCP/UDP retransmit could lead to flow and finer
(seq num, etc) matching to the user's former IP. It wouldn't
necessarily have to change the guards, but that could be an extended
option.
eg: Is there anything to be done for the Tor instance itself to not
be trackable across an IP change?
If so, is monitoring the interface using some OS provided interface API
possible versus a dhcp/user driven controller toggle? Note multiple stacks,
multiple interfaces, secondary addresses, and vm's etc.
DHCP's unpredictable IP changes and complex state machine / scripts
would make dhcp hard for the typical user to hook into.
A controller toggle would still be needed anyway for those who
manually change their IP.
There may be some small network or client/server benefit to maintaining
things like descriptors in core as opposed to just restarting Tor.
And should this tie in to sighup actions?
I think this may have been discussed recently, if so just pull
from and close this.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7718Vidalia network settings: specified allowed ports disappear after editing torc2020-06-13T02:13:35ZTracVidalia network settings: specified allowed ports disappear after editing torcBug in Vidalia -> Settings -> Network tab:
If "My firewall only lets me connect to certain ports" is marked, the specified "Allowed ports:" often disappear after editing torc.
This bug is not consistent. When it occurs, the Vidalia Mes...Bug in Vidalia -> Settings -> Network tab:
If "My firewall only lets me connect to certain ports" is marked, the specified "Allowed ports:" often disappear after editing torc.
This bug is not consistent. When it occurs, the Vidalia Message Log then reports that the bridge becomes unreachable by our firewall policy (since its port disappears from the allowed list).
It takes multiple repeated attempts to specify the ports again before they are retained.
**Trac**:
**Username**: bugcatcherTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/6401Update Tor network models from CSET paper2020-06-13T17:47:38ZRob JansenUpdate Tor network models from CSET paperOur [CSET paper](https://www.usenix.org/conference/cset12/methodically-modeling-tor-network) explains techniques for modeling the Tor network. Our model is verified against data from server descriptors, etc., and compared in Shadow and E...Our [CSET paper](https://www.usenix.org/conference/cset12/methodically-modeling-tor-network) explains techniques for modeling the Tor network. Our model is verified against data from server descriptors, etc., and compared in Shadow and ExperimenTor. Because of exptor's limitations, we were restricted to 100 relays and 1000 clients.
We should update the model as follows:
1. Expand the client model to include **P2P-type** client swarms that both upload **and** download
1. Expand the client model to include small **IM-type** (ping-like) clients, to better measure expected performance for clients that don't ever download large amounts of data
1. ~~Expand the client model to use **browser-type** clients that are capable of downloading real html files, parse them, and fetch the various embedded objects~~
1. Re-adjust the ratios of the various client types so load and expected performance is similar to live Tor
1. Update Shadow's various sized topology files so we can run experiments beyond ~1000 nodes.
This is a blocker for much of the performance simulation work, such as #5336, #4086, #4486, #4487, #5190, #6341Rob JansenRob Jansenhttps://gitlab.torproject.org/legacy/trac/-/issues/4712Review and update any existing patches for proposal 182 ("credit buckets")2020-06-13T17:47:22ZKarsten LoesingReview and update any existing patches for proposal 182 ("credit buckets")We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.We should review any existing patches for proposal 182 and update them for merging them into master. This is part of #4682.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4696add OutboundBindInterface option to torrc2020-06-13T14:15:56ZTracadd OutboundBindInterface option to torrcFirst, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
...First, I am well-aware that there is OutboundBindAddress option in tor.
I am also aware that tor "automatically" chooses an IP address/interface to bind to (if OutboundBindAddress is not specified) based on the current routing table.
There are quite a few instances where OutboundBindAddress option is not suitable, particularly where the IP address changes frequently (vpn as well as most dhcp-dependant interfaces).
Whether I use OutboundBindAddress or just leave tor to make a decision which address to bind to is not suitable (at least) in the following two cases:
1. When I temporarily loose my IP address which tor has used up until now due to dhcp client renewing its lease (and receive a new IP address) and that doesn't happen - for whatever reason - instantly.
This results in one of two possible - wrong - outcomes: a) in case of absence of OutboundBindAddress option, Tor decides that my IP address "has changed" and tries to bind to the default interface, which may not be the one I have used previously; or b) when OutboundBindAddress is specified, tor just sits there trying to use the "old" address specified, resulting in a stall.
2. When I temporarily loose my current IP address due to vpn connection becoming (temporarily) unstable and it takes a bit of time for my machine to renew its IP address (this may take from a minute to up to 20+ minutes depending on the status of the vpn server at the other end) the outcome is exactly the same as I listed above - tor either tries to use the default interface (wrong!) or tries to bind to the IP address I specified with OutboundBindAddress (wrong again).
With the introduction of this new (OutboundBindInterface) option, tor can follow the IP address on the specified *interface* (regardless of what that might be) and the above - erroneous - outcome could be avoided.
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3011Some ideas for Vidalia's network graph2018-07-03T22:32:19ZTracSome ideas for Vidalia's network graphI had some ideas regarding the Network Graph, because currently it it lacks some useful information.
So, first off is totals. Totals like, **_all data**_ (down and up) in MB/GB/TB, and the **_total speed**_ in kB/s or MB/s.
Another one...I had some ideas regarding the Network Graph, because currently it it lacks some useful information.
So, first off is totals. Totals like, **_all data**_ (down and up) in MB/GB/TB, and the **_total speed**_ in kB/s or MB/s.
Another one is the automatic scale that is adjusting to the maximum speed that was reached. This produces a problem: when you reach 800 kB/s, your scale will ajust to such a range the 10 or 20 kB/s graph is almost flat.
Another cool thing: history.
* Data send last [day/hour/minute]
* Data received last [day/hour/minute]
* Total data last [day/hour/minute]
* Average up speed [day/hour/minute]
* Average down speed [day/hour/minute]
Random idea I just thought of: give graph a raster and use a drop down box that adjusts the graph scrolling speed. One block is _[1 minute]_, _[30 seconds]_, _[5 seconds]_ or _[1 second]_.
If more explanation is needed, ask it!
**Trac**:
**Username**: anaccountVidalia: 0.3.xTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/2266tor network map - frame resize fails2012-02-13T18:52:30ZTractor network map - frame resize failsclicking on the frame edge moves the frame.
**Trac**:
**Username**: grimpenclicking on the frame edge moves the frame.
**Trac**:
**Username**: grimpenTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/1391Can't see the Network Map2010-05-14T04:20:45ZTracCan't see the Network MapI downloaded tor a week ago, but since, the network map has never worked, i can see the names of the repeaters, but neither their nationalities nor their location in the map.
( I have vidalia 0.2.7)
**Trac**:
**Username**: volviendoa...I downloaded tor a week ago, but since, the network map has never worked, i can see the names of the repeaters, but neither their nationalities nor their location in the map.
( I have vidalia 0.2.7)
**Trac**:
**Username**: volviendoaca@yahoo.frhttps://gitlab.torproject.org/legacy/trac/-/issues/1374No connection anymore2020-06-12T23:42:00ZTracNo connection anymoreHI,
I am running as Guard Router using Tor IM Browser 0.2.1.25 and Windows 7. After a few days, not using Tor myself, my Firefox and IE lost all contact to the network. Polipo and Vidalia processes are running. I think Firefox is talking...HI,
I am running as Guard Router using Tor IM Browser 0.2.1.25 and Windows 7. After a few days, not using Tor myself, my Firefox and IE lost all contact to the network. Polipo and Vidalia processes are running. I think Firefox is talking to Polipo. View Network in Vidalia doesn’t show any Connections. Tor traffic is still flowing as usual at full speed. I had the same problem with version 0.2.1.24. After restart of the computer the program works fine again.
Best Regards
STHnet
**Trac**:
**Username**: anonymousAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/531Transition from 0.0.0.0 listener to specific listener disallowed2020-06-13T13:58:49ZNick MathewsonTransition from 0.0.0.0 listener to specific listener disallowedCoderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undo...Coderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undoable), but it can't open the new listener until the old one is closed.
See or-talk/or-dev thread, "Server node stalls on unsuccessful socks listener change."
It looks like we have two options:
1) Disallow the 0.0.0.0 -> non 0.0.0.0 change.
2) When transitioning from 0.0.0.0, accept that the transition will not be perfectly undoable.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecified