于 2010-3-24 10:44, torsecurity 写道: > The 172.18.12.161 is my private network address and the bridge is only > intended to be used in the internal network. > 2010-03-24 > ------------------------------------------------------------------------ > Gaofeng He > ------------------------------------------------------------------------ > *发件人:* wang.wang.test > *发送时间:* 2010-03-24 10:35:33 > *收件人:* or-talk > *抄送:* > *主题:* Re: a problem about run tor bridge > 于 2010-3-24 10:19, torsecurity 写道: >> Hi, everyone! >> My computer is behind a NAT and I can connect to the Tor network >> directly ( not using Tor bridges although I am in China). Now I want >> to configure my tor as a bridge to let my friend connect to the Tor >> network. His IP is 172.18.12.xxx. My configuration file looks like: >> BridgeRelay 1 >> ContactInfo hegaofeng at seu dot edu dot cn >> ControlPort 9051 >> ExitPolicy reject *:* >> Log notice stdout >> Nickname ORhgf >> ORPort 443 >> PublishServerDescriptor 0 >> RelayBandwidthBurst 10485760 >> RelayBandwidthRate 5242880 >> And my bridge information is: 172.18.12.161:443 >> But this dosen't work. The Vidalia is always stopping at "Loading >> relay information...". >> I use Wireshark and find the TLS handshake is normal. >> Can anyone tell me why? Thanks a lot! >> 2010-03-24 >> ------------------------------------------------------------------------ >> Gaofeng He > first, you can't run any tor service behind NAT unless you can > configure your firewall/NAT in order to enable port forwarding. By the > way, what the hell is 172.18.12.161? Who can connect to that thing? > > second, I do not think "Loding relay information..." has anything to > do with your recent bridge configuration.
sorry to misunderstand you. http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=doc/spec/dir-spec.txt take a look at 5.1: If a client is missing a live network-status document, it tries to fetch it from a directory cache (or from an authority if it knows no caches). On failure, the client waits briefly, then tries that network-status document again from another cache. The client does not build circuits until it has a live network-status consensus document, and it has descriptors for more than 1/4 of the routers that it believes are running. maybe that's your problem -- no enough descriptors.