[tor-relays] Bridge relay: conversing with the message log

[eliaz]

Stephen - I can't thank you enough  for the clarification. I's a great
help to my understanding of how Tor interacts with ISPs. - eli


On 9/20/2012 3:24 PM, Stephen Mollett wrote:
> Hi Eli,
> 
> On Thursday, 20 September 2012, 13:25, eliaz <eliaz at tormail.org> wrote:
> 
>> ...
>> Sep 20 07:33:43.872 [Info] resolve_my_address(): Guessed local hostname
>> '<NAME>' resolves to a private IP address (<ISP address>).
>> Trying something else.
>> Sep 20 07:33:43.872 [Info] resolve_my_address(): Interface IP address
>> '<LAN address>' is a private address too. Ignoring.
>> ...
> 
>> In particular, what does it mean that the <LAN address> is being
>> identified as private? 
> 
> 
> "Private address" in the context of an IP address usually refers to an address in one of the reserved ranges which are set aside for use on private networks and which can't be routed to over the internet. These ranges are 192.168.*.* (the commonest one, used by most home routers when issuing addresses to clients), 10.*.*.* (fairly common, especially in corporate networks) and 172.16.*.*-172.31.*.* (not seen very often). 100.64.*.*-100.127.*.* is also reserved for ISPs to use, primarily to help ease the transition from the old-style 32-bit IPv4 addressing system (addresses that look like 173.194.69.99 which is one of the addresses for www.google.com) to 128-bit IPv6 addresses (which look like 2a00:1450:4008:c01::68 - also www.google.com).
> 
> 
> It's not surprising that your LAN address is a private one (most likely in 192.168.0.* or 192.168.1.* depending on what router you have); your ISP may also be using private addresses, at least for its residential customers. If your ISP does allocate you a private address, your reachability from the public internet is largely dependent on how their NAT and firewalling system works. Publishing the private address won't work, though, as it could be used by many different ISPs (or even multiple times by the same ISP!)
> 
> 
> Hope this sheds a little light on the log entries.
> 
> Stephen
> 
>  
> 

-- 
gpg: 0x3E346824