Re: [tor-relays] why the network lost 350 relays and some, bridges
Toralf Förster: > Just FWIW this is incremented to snap270: the number in the relay nickname is just the $SNAP_REVISION https://bazaar.launchpad.net/~privacy-squad/+junk/tor-middle-relay-snap/revision/87#daemon -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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] why the network lost 350 relays and some, bridges
Argo2: > I was intrigued by the high number of consumer IP's that these relay > are supposed to be running on while seemingly automated updating the > relay version. The nickname made me look into Ubuntu Snaps as a > possible tor distribution which led me to this snap: > https://snapcraft.io/tor-middle-relay. we are well aware of the source of that package (see previous threads on this ML) > It was last updated the 9th of January and when you download the > stable snap it is actually named 'snap269'. So the maintainer in this > case is the snap maintainer, but not necessarily the relay(s) > operator. I was not trying to suggest that package maintainer and relays maintainer are the same entity (Chad, the snap maintainer is on this list) > I have not looked into how these snaps actually work but > it may be the case that they actually needed the PortForwaring > functionality to get tor running inside a snap. > > Given that information it could very well be the case that these > relays are not running behind a NAT I doubt that. the demonstrated effect of removing the portforwarding functionality temporarily and their reverse DNS names suggest that they are mostly behind consumer grade Internet uplinks. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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] why the network lost 350 relays and some, bridges
On 1/12/19 11:08 AM, Argo2 wrote: > It was last updated the 9th of January and when you download the stable > snap it is actually named 'snap269'. Just FWIW this is incremented to snap270: https://metrics.torproject.org/rs.html#details/93156A27C9B035C488678E98FE4156F7B593872F -- Toralf PGP C4EACDDE 0076E94E 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] why the network lost 350 relays and some, bridges
I was intrigued by the high number of consumer IP's that these relay are supposed to be running on while seemingly automated updating the relay version. The nickname made me look into Ubuntu Snaps as a possible tor distribution which led me to this snap: https://snapcraft.io/tor-middle-relay. It was last updated the 9th of January and when you download the stable snap it is actually named 'snap269'. So the maintainer in this case is the snap maintainer, but not necessarily the relay(s) operator. I have not looked into how these snaps actually work but it may be the case that they actually needed the PortForwaring functionality to get tor running inside a snap. Given that information it could very well be the case that these relays are not running behind a NAT and not run by the same operator but actually by a group of different people. Date: Sat, 12 Jan 2019 08:07:00 + From: nusenu this occurred when these relays upgraded from tor 0.3.3.10 to 0.3.4.9 (package maintainer update) All these relays were behind NAT devices and they relied on a tor feature that got removed between these two versions: o Removed features: - The PortForwarding and PortForwardingHelper features have been removed. [...]https://trac.torproject.org/projects/tor/ticket/25409 I guess I somehow expected that: the maintainer patched tor 0.3.4.10 to added this feature again and here we go again with the flood of relays using that version of tor: 79 relays from 2019-01-11: | Up | Ext | JoinTime | Nickname | Version | IP | AS | CC | ORp | Dirp | OS| Contact | eFamMembers | FP | |--+---+++---+-+--+--+---++---+---+---+--| |0 | 0 | 01:06:55 | snap269| 0.3.4.10 | 117.104.229.222 | Instatelecom Limited | af | 43453 | 0 | Linux | None | 1 | CF52FF9F481C618E540D5DACB0C2875F1B7687B5 | |0 | 0 | 01:27:25 | snap269| 0.3.4.10 | 90.253.141.146 | Vodafone Limited | gb | 46089 | 0 | Linux | None | 1 | B483C5FE8A2888F8E02885D8488404DBBEFBCF3B | [SNIP] ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] why the network lost >350 relays and some bridges
> Assuming those relays get a weight of 20 (or zero?) I do wonder if > there's a metrics graph (option) showing the number of relays having > a significant weight? their consensus weight is non-zero (they make up ~0.3% of the tor network capacity) https://metrics.torproject.org/rs.html#search/snap2%20running:True -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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] why the network lost >350 relays and some bridges
On 1/12/19 9:07 AM, nusenu wrote: > I guess I somehow expected that: the maintainer patched tor 0.3.4.10 to added > this > feature again and here we go again with the flood of relays using that > version of tor: > > 79 relays from 2019-01-11: Assuming those relays get a weight of 20 (or zero?) I do wonder if there's a metrics graph (option) showing the number of relays having a significant weight? -- Toralf PGP C4EACDDE 0076E94E 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] why the network lost >350 relays and some bridges
> this occurred when these relays upgraded from tor 0.3.3.10 to 0.3.4.9 > (package maintainer update) > > All these relays were behind NAT devices and they relied on a tor > feature that got removed between these two versions: > >> o Removed features: >> - The PortForwarding and PortForwardingHelper features have been >> removed. [...]https://trac.torproject.org/projects/tor/ticket/25409 I guess I somehow expected that: the maintainer patched tor 0.3.4.10 to added this feature again and here we go again with the flood of relays using that version of tor: 79 relays from 2019-01-11: | Up | Ext | JoinTime | Nickname | Version | IP | AS | CC | ORp | Dirp | OS| Contact | eFamMembers | FP | |--+---+++---+-+--+--+---++---+---+---+--| |0 | 0 | 01:06:55 | snap269| 0.3.4.10 | 117.104.229.222 | Instatelecom Limited | af | 43453 | 0 | Linux | None | 1 | CF52FF9F481C618E540D5DACB0C2875F1B7687B5 | |0 | 0 | 01:27:25 | snap269| 0.3.4.10 | 90.253.141.146 | Vodafone Limited | gb | 46089 | 0 | Linux | None | 1 | B483C5FE8A2888F8E02885D8488404DBBEFBCF3B | |0 | 0 | 02:04:06 | snap269| 0.3.4.10 | 84.109.18.79| Bezeq International | il | 43663 | 0 | Linux | None | 1 | 4CB2C1DED2C3C0C1A3629C6EB89BEDD063839F3A | |0 | 0 | 02:04:44 | snap269| 0.3.4.10 | 24.171.142.150 | Time Warner Cable Internet LLC | us | 35659 | 0 | Linux | None | 1 | 4E323B6D6EEA0134C74311B02139A1899BB42396 | |1 | 0 | 02:06:28 | snap269| 0.3.4.10 | 102.251.43.31 | TELKOMMOBILE | za | 37359 | 0 | Linux | None | 1 | 156C88E2AC25EE27A5DE774DF33294A1F0BE9659 | |0 | 0 | 02:09:26 | snap269| 0.3.4.10 | 173.72.24.170 | MCI Communications Services, Inc. d/b/a | us | 35413 | 0 | Linux | None | 1 | F06D46106A5508D3904F20E5E316978E1C40C524 | |1 | 0 | 02:32:49 | snap269| 0.3.4.10 | 37.14.181.6 | Orange Espagne SA| es | 33927 | 0 | Linux | None | 1 | 01A9601468D4EDB410D8CAFCB6AFF57BDCECCC79 | |0 | 0 | 03:32:46 | snap269| 0.3.4.10 | 46.158.228.64 | Rostelecom | ru | 32945 | 0 | Linux | None | 1 | A1F23D3FAE72CCC04E9A2302E21F4FFA86B004BF | |0 | 0 | 03:46:57 | snap269| 0.3.4.10 | 96.58.48.239| BRIGHT HOUSE NETWORKS, LLC | us | 34779 | 0 | Linux | None | 1 | 75ECA8970059EC52ABDE432296DD379D926B4B9E | |0 | 0 | 03:59:27 | snap269| 0.3.4.10 | 167.56.51.66| Administracion Nacional de Telecomunicac | uy | 43415 | 0 | Linux | None | 1 | FBA355B99ED355440C22CD305C4106CD5EBFBF8D | |0 | 0 | 03:59:53 | snap269| 0.3.4.10 | 106.51.69.243 | Atria Convergence Technologies Pvt. Ltd. | in | 35099 | 0 | Linux | None | 1 | F708D88E38D31F47574FA086AFE95D77A0F57D3C | |1 | 0 | 04:07:21 | snap269| 0.3.4.10 | 178.149.21.184 | Serbia BroadBand-Srpske Kablovske mreze | rs | 33259 | 0 | Linux | None | 1 | 235658FF31A58ED10A86C5C04EDDD33A0ED3D27C | |1 | 0 | 04:10:50 | snap269| 0.3.4.10 | 80.6.137.83 | Virgin Media Limited | gb | 36423 | 0 | Linux | None | 1 | 3DB282CE152AA5C57521B5B24DAE9C9AE4D88F54 | |0 | 0 | 04:13:10 | snap269| 0.3.4.10 | 31.34.31.241| Bouygues Telecom SA | fr | 34075 | 0 | Linux | None | 1 | D923E3AD062307A65F14F6F05E6A9D755376F7F5 | |1 | 0 | 04:44:56 | snap269| 0.3.4.10 | 86.213.118.11 | Orange | fr | 45521 | 0 | Linux | None | 1 | E7EC0C654C83E35F41337DB3A8CE2FBAAEA96619 | |1 | 0 | 04:48:14 | snap269| 0.3.4.10 | 95.84.154.208 | Rostelecom | ru | 43275 | 0 | Linux | None | 1 | BAD04160018D61F1783BCE20A78619BCABC6409E | |1 | 0 | 05:05:41 | snap269| 0.3.4.10 | 71.193.142.132 | Comcast Cable Communications, LLC| us | 38941 | 0 | Linux | None | 1 | 6FF713C117BBA89221BA58B2D7925DBA12BAAAE9 | |1 | 0 | 05:33:27 | snap269| 0.3.4.10 | 73.70.172.19| Comcast Cable Communications, LLC| us | 41517 | 0 | Linux | None | 1 |
Re: [tor-relays] why the network lost >350 relays and some bridges
nusenu wrote: > As some of you might have noticed the tor network recently > lost a noticeable number of relays and bridges as seen in the > metrics.tpo relay graphs (0.7% cw fraction). > > https://metrics.torproject.org/networksize.html > https://pbs.twimg.com/media/DwGAESoXgAEoB6L.jpg > > this occurred when these relays upgraded from tor 0.3.3.10 to 0.3.4.9 > (package maintainer update) > > All these relays were behind NAT devices and they relied on a tor > feature that got removed between these two versions: > >> o Removed features: >> - The PortForwarding and PortForwardingHelper features have been >> removed. [...]https://trac.torproject.org/projects/tor/ticket/25409 > > The portforwarding worked only in about 5% of cases so only 350 of the over > 6000 > relays actually became reachable. > > Since I still believe these relays are not run by humans I hope they remain > unreachable behind their NAT routers. > Agreed, a very good and indicated removal -- those features where quite fragile and looked to users like they working as they should, where actually they worked in a very little percent. Any relay properly run by a human, even behind NAT, can still be easily configured with the proper port forwarding. For some time now Tor is very explicit in such situations, it checks the discovered address vs the address in torrc/descriptor and indicates if there is a mismatch, so the user knows exactly what and where to fix. 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
