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 +0000 From: nusenu nusenu-lists@riseup.net
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]
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/93156A27C9B035C488678E98FE415...
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/revi...
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.
tor-relays@lists.torproject.org
-
Argo2 -
nusenu -
Toralf Förster