>> Wouldn't a more capable MAPADDRESS function help some of you who >> need to anchor certain services to a specified exit over long >> term use?
> See https://trac.torproject.org/projects/tor/ticket/933 Awesome!!! I will read it in more detail for possible further comment midweek. Likewise, for your reference, my original detailed proposals and rationales are here: domains: Jun 05/12 2009 or-dev mid: d2e731a10906121236v1d820a98q6375a4110d67f...@mail.gmail.com Jun 16 2009 or-talk mid: d2e731a10906152223m3063c9aci5ef9b18751e5f...@mail.gmail.com Aug 24 2009 or-talk mid: d2e731a10908241344h3b064218n4256c41b042f2...@mail.gmail.com Dec 20 2010 or-talk mid: aanlktimnkfbpnmp4m8g2-oqnahg1rmycaoq4og9u9...@mail.gmail.com cidr: Oct 30 2009 or-talk mid: d2e731a10910292340l108dfffy8372b52dae1b1...@mail.gmail.com Should I add all this to the ticket? > If you have anything to add, now is the time! Yes, per the above posts, add CIDR block mapping as well: 95.0.0.0/17 -> 95.0.0.0/17.<fingerprint>.exit For MAPADDRESS entry marking purposes, it should allow any IP address, so long as the address lies within the block boundary: 1.2.3.77/24 -> 1.2.3.77/24.<fingerprint>.exit I know at least FreeBSD allows you to configure interfaces like that, with both the address and netmask in one string, so you could find a code example for the address within boundary thing there I'm sure. There are more examples in the above posts, particularly: host: 45.2.1.7/32 everything: 0.0.0.0/0 Address list notation might be as such: 1.2.3.{1..4,7..9,23,54,99..136} 1.2.{3..5}.{0..10} I might further suggest extending the MAPADDRESS parser to handle Type Of Map declarations and defaulting unspecified ones to the old style for backward compatibility. That way each type can be maintained separately and new types can be added modularly. It may be desireable to replace the underscore with a space or a slash. Not sure about that yet. ie: MAPADDRESS_DOMAIN *.foo.com MAPADDRESS_CIDR 1.2.3.4/24 MAPADDRESS_LIST 1.2.3.{7..9} MAPADDRESS_LEGACY a.foo.com MAPADDRESS a.foo.com This might be further enhanced as well: getinfo address-mappings/<type> Types: all = everything DOMAIN, CIDR, LIST = as above LEGACY = old style entries And of course, removing any entry from the map remains the same: Stop further dynamic mapping by setting the source=destination, thus removing the request to generate dynamic maps: 1.0.0.0/24=1.0.0.0/24 Remove a specific dynamic entry by mapping the full exit=exit: foo.com.<fingerprint>.exit=foo.com.<fingerprint>.exit _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
