- Aug 03, 2009
-
-
- Aug 02, 2009
-
-
Andrew Lewman authored
-
- Jul 30, 2009
-
-
Nick Mathewson authored
-
- Jul 29, 2009
-
-
Nick Mathewson authored
-
Peter Palfrader authored
-
Peter Palfrader authored
* debian-merge: New upstream version bump to 0.2.1.19 document my new relay-early behavior Changing MaxAdvertisedBW may not need a republish Write fingerprint to file and log without spaces Don't leak memory if we get too many create cells three hacks to workaround bug 1038
-
Peter Palfrader authored
-
Peter Palfrader authored
* commit 'tor-0.2.1.19': bump to 0.2.1.19 document my new relay-early behavior Changing MaxAdvertisedBW may not need a republish Write fingerprint to file and log without spaces Don't leak memory if we get too many create cells three hacks to workaround bug 1038
-
Roger Dingledine authored
also bring the release notes up to date
-
- Jul 28, 2009
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Relays no longer publish a new server descriptor if they change their MaxAdvertisedBandwidth config option but it doesn't end up changing their advertised bandwidth numbers. Bugfix on 0.2.0.28-rc; fixes bug 1026. Patch from Sebastian.
-
Roger Dingledine authored
Now it will look like the fingerprints in our bridges documentation, and confuse fewer users.
-
Roger Dingledine authored
Specifically, every time we get a create cell but we have so many already queued that we refuse it. Bugfix on 0.2.0.19-alpha; fixes bug 1034. Reported by BarkerJr.
-
Roger Dingledine authored
The problem is that clients and hidden services are receiving relay_early cells, and they tear down the circuit. Hack #1 is for rendezvous points to rewrite relay_early cells to relay cells. That way there are never any incoming relay_early cells. Hack #2 is for clients and hidden services to never send a relay_early cell on an established rendezvous circuit. That works around rendezvous points that haven't upgraded yet. Hack #3 is for clients and hidden services to not tear down the circuit when they receive an inbound relay_early cell. We already refuse extend cells at clients.
-
- Jul 25, 2009
-
-
Peter Palfrader authored
* debian-merge: New upstream version bump to 0.2.1.18 put in the full 0.2.1 release notes add a changelog entry for the upcoming 0.2.1.18 make phobos's lines start with tabs again added LIBS=-lrt to Makefile.am for static libevent in the tor rpms. forward-port the 0.2.0.35 release notes add blurbs for recent release candidates Bump version to 0.2.1.17-rc-dev
-
Peter Palfrader authored
-
Peter Palfrader authored
* commit 'tor-0.2.1.18': bump to 0.2.1.18 put in the full 0.2.1 release notes add a changelog entry for the upcoming 0.2.1.18 make phobos's lines start with tabs again added LIBS=-lrt to Makefile.am for static libevent in the tor rpms. forward-port the 0.2.0.35 release notes add blurbs for recent release candidates Bump version to 0.2.1.17-rc-dev
-
- Jul 24, 2009
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Roger Dingledine authored
in case Make on openirix128 can't handle it otherwise
-
-
Roger Dingledine authored
-
Roger Dingledine authored
- Jul 14, 2009
-
-
Nick Mathewson authored
-
- Jul 13, 2009
-
-
Peter Palfrader authored
-
Peter Palfrader authored
* debian-merge: (21 commits) Bump version to 0.2.1.17-rc Make "Invalid onion hostname" msg respect SafeLogging. updated rpm instructions for realtime libevent. Revise 0.2.1.17-rc changelog. Make an attempt to fix bug 1024. Update the year for the copyright statement in two more files another minor patch to add to 0.2.1.x and give the bug 969 fixes a changelog the third piece of bug 969 fixing the second piece of bug 969 fixing the first piece of bug 969 fixing Have eventdns set the "truncated" bit correctly. stop capping bandwidths we see in the consensus Added ChangeLog entry for control port fix Ignore control port commands after a QUIT Flush long replies over control port on QUIT add a changelog entry: clients use bw in consensus Clients now use bandwidth values in the consensus Serve DirPortFrontPage even if the write bucket is low. Add warning that the results of --enable-geoip-stats are different from those in master. ...
-
Peter Palfrader authored
* commit 'tor-0.2.1.17-rc': (21 commits) Bump version to 0.2.1.17-rc Make "Invalid onion hostname" msg respect SafeLogging. updated rpm instructions for realtime libevent. Revise 0.2.1.17-rc changelog. Make an attempt to fix bug 1024. Update the year for the copyright statement in two more files another minor patch to add to 0.2.1.x and give the bug 969 fixes a changelog the third piece of bug 969 fixing the second piece of bug 969 fixing the first piece of bug 969 fixing Have eventdns set the "truncated" bit correctly. stop capping bandwidths we see in the consensus Added ChangeLog entry for control port fix Ignore control port commands after a QUIT Flush long replies over control port on QUIT add a changelog entry: clients use bw in consensus Clients now use bandwidth values in the consensus Serve DirPortFrontPage even if the write bucket is low. Add warning that the results of --enable-geoip-stats are different from those in master. ...
-
- Jul 07, 2009
-
-
Nick Mathewson authored
-
Nick Mathewson authored
Patch by Roger; fixes bug 1027.
-
- Jul 02, 2009
-
-
Andrew Lewman authored
-
-
The internal error "could not find intro key" occurs when we want to send an INTRODUCE1 cell over a recently finished introduction circuit and think we built the introduction circuit with a v2 hidden service descriptor, but cannot find the introduction key in our descriptor. My first guess how we can end up in this situation is that we are wrong in thinking that we built the introduction circuit based on a v2 hidden service descriptor. This patch checks if we have a v0 descriptor, too, and uses that instead.
-
- Jun 30, 2009
-
-
-
o Minor features: - If we're a relay and we change our IP address, be more verbose about the reason that made us change. Should help track down further bugs for relays on dynamic IP addresses.
-
-
when we write out our stability info, detect relays that have slipped through the cracks. log about them and correct the problem. if we continue to see a lot of these over time, it means there's another spot where relays fall out of the routerlist without being marked as unreachable.
-