Re: MinGW compile error with rev 10888
On Sun, Aug 19, 2007 at 10:07:09AM +0800, Li-Hui Zhou wrote: > > > In file included from or.h:121, > > > from buffers.c:16: > > > c:/Gnu/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/event.h:93: > > > error: field `ev_timeout' has incomplete type > > > make[3]: *** [buffers.o] Error 1 > > > > That looks like a libevent error. As far as I know, the best libevent > > for mingw is still 1.1b. Is that the one you're using, or do you have > > a different one installed? > > I tried with libevent 1.1b without success. The same error happened. So > it's not likely to be a libevent problem. Try tor trunk now. I believe it should work. I also think it's a libevent error though, since the problem is that libevent's event.h has no idea what a timeval is. Tor has a workaround for systems that don't define a timeval, but libevent should include this workaround too. Nick, can you look further into this? Thanks, --Roger
Re: MinGW compile error with rev 10888
On Fri, 17 Aug 2007 19:04:48 -0400 Nick Mathewson <[EMAIL PROTECTED]> wrote: > On Fri, Aug 17, 2007 at 09:24:26AM +0800, Li-Hui Zhou wrote: > > Sorry to bother again. Several revisions > > after rev. 11043, compile on win32 by > > MinGW seems broken. > > > > Error message read: > > > > In file included from or.h:121, > > from buffers.c:16: > > c:/Gnu/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/event.h:93: > > error: field `ev_timeout' has incomplete type > > make[3]: *** [buffers.o] Error 1 > > That looks like a libevent error. As far as I know, the best libevent > for mingw is still 1.1b. Is that the one you're using, or do you have > a different one installed? > > yrs, > -- > Nick Mathewson I tried with libevent 1.1b without success. The same error happened. So it's not likely to be a libevent problem. -- Li-Hui Zhou <[EMAIL PROTECTED]>
Re: Privoxy usage?
On 8/18/07, coderman <[EMAIL PROTECTED]> wrote: > ... TCP VPN over Tor i forgot to add: LongLivedPorts and NEWNYM are your friends.
Re: Privoxy usage?
On 8/18/07, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > ... > > with Tor your tcp endpoint is terminating quite close, in this case on > > the same host stack or one host over. > > That's not TCP over TCP. That's two TCP connecitons put end to end, > and that's fine. indeed. i need more coffee before getting into technical protocol discussions. (i was misreading part of this thread...) > On the other hand, if you run a layer 2 VPN over tor, you get TCP > within IP within multiple layers of SSL within TCP. And that's not > good, either for your performance, or for the network. right, there can be a hit here. enough that maybe interest in the UDP transport proposal could get some attention? :) however, this is a much bigger hit for lossy links, rather than latent links. TCP VPN over WiFi is much more problematic than TCP VPN over Tor in my experience. i've also had success tweaking the TCP VPN layer (disable nagle for example, and i recall someone using cork to benefit too). the Tor UDP proposal is here: http://tor.eff.org/svn/trunk/doc/spec/proposals/100-tor-spec-udp.txt , DTLS is more mature now than it was at time of writing, but this still has unresolved issues. best regards,
Re: Privoxy usage?
>> Ahem... if your VPN software is using TCP rather than UDP or raw IP, >> then I strongly recommend that you choose a different VPN vendor. > that's not good advice. tcp to 443 and other uses in general are > quite acceptable. (ok, i do favor AH/ESP or UDP, but TCP is still > quite usable and useful) That's not a VPN. That's encryption at the application layer, and that's fine. > with Tor your tcp endpoint is terminating quite close, in this case on > the same host stack or one host over. That's not TCP over TCP. That's two TCP connecitons put end to end, and that's fine. > the performance hit for TCP over TCP in Tor land is the latency and > bandwidth associated with onion routing, not nested TCP transport. There is no nested TCP in normal tor operation; there's multiple layers of SSL encryption over a single TCP connection. On the other hand, if you run a layer 2 VPN over tor, you get TCP within IP within multiple layers of SSL within TCP. And that's not good, either for your performance, or for the network. Juliusz
Re: Privoxy usage?
On 8/18/07, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > ... > Ahem... if your VPN software is using TCP rather than UDP or raw IP, > then I strongly recommend that you choose a different VPN vendor. that's not good advice. tcp to 443 and other uses in general are quite acceptable. (ok, i do favor AH/ESP or UDP, but TCP is still quite usable and useful) > Which means that until Roger, Nick and their basementful of slaves > implement a datagram transport for tor, it will not be possible to run > a well-designed VPN over tor. i've used openvpn tcp over tor. it works just as you expect other application layer protocols over tcp to work. what's your grudge against tcp over tcp? > [... out of order reply ...] > TCP over TCP has some problems, the least/biggest of which is the > timeout factor. > > If there is a communication problem, TCP has a "back off and resend" > rule. with Tor your tcp endpoint is terminating quite close, in this case on the same host stack or one host over. you don't lose or timeout packets over a single hop (unless you've got a blaster infected client on your LAN :) please back up these arguments with some kind of facts, since you're misunderstanding the usual nature of TCP applications using Tor here. the performance hit for TCP over TCP in Tor land is the latency and bandwidth associated with onion routing, not nested TCP transport. best regards,
Re: Privoxy usage?
[EMAIL PROTECTED] wrote: I have heard of the "TCP over TCP" issue but have not had any bad experiences so far. I am currently using both TCP and UDP-based VPN systems and while the TCP-based one is a bit slower, it still seems very stable for applications such as Terminal Services, FTP, http(s), etc. I do notice problems with some apps (FTP for example) if I'm trying to use a TCP-based connection over a satellite link - lot of TCP RSTs and "Zero Window"-type errors in the sniff though on some satellite systems even UDP-based tunnels don't seem to work very well for anything other than low bandwidth applications. Same here. I use OpenVPN with my laptop as the client. I chose to use TCP over port 443, rather than the default UDP so I'd have no NAT/firewall issues as I move around from network to network. Works like a charm. I don't deny it's probably inefficient, but it's not noticably so. Not to me anyhow. Mike
Re: bandwidth graph ok with 0.1.2.14-dev only
Robert Hogan wrote: > On Wednesday 01 August 2007 09:19:46 Olaf Selke wrote: >> >> my OR still periodically shows up a 24 hours "sawtooth" bandwidth >> utilization using 0.1.2.15. Regarding the dropping bandwidth every night >> GMT+2 it behaves exactly like 0.1.2.14. I supposed this issue to be >> fixed with 0.1.2.14-dev since the bandwidth utilization with >> 0.1.2.14-dev doesn't change very much over the day. >> > > I've done some light research on this issue and suspect (on the basis of > fairly slender analysis) that the problem may not be entirely down to just > the version of Tor you're using. The only way to see if it is a factor is to > run 0.1.2.14-dev for a while and see if the problem re-appears after a week > or two. Would you mind doing that? and here it is: 0.1.2.14-dev run perfectly smooth without the "sawtooth" bandwidth pattern for about 17 days. Last Wednesday the process died again with the "Out of memory on realloc(). Dying." error message. Olaf signature.asc Description: OpenPGP digital signature
Re: Privoxy usage?
> I may be doing a horrible job of explaining the problem. No, you're doing fine. I'm just going to explain it differently. > IP over IP works. > UDP over UDP works if your UDP protocol supports it. > TCP over TCP fails. The timeout rules cannot stack properly. You missed the two important cases ;-) TCP over IP works (duh) TCP over UDP works This last case is why things like OpenVPN can do their job. TCP over TCP is extremely inefficient; it will cause spurious retransmissions, seriously impair the throughput you get and congest the tor network. (This does not apply to tunnelling over ssh, since ssh tunnels the higher-layer data stream rather than the TCP packets.) Juliusz
Re: Privoxy usage?
I have heard of the "TCP over TCP" issue but have not had any bad experiences so far. I am currently using both TCP and UDP-based VPN systems and while the TCP-based one is a bit slower, it still seems very stable for applications such as Terminal Services, FTP, http(s), etc. I do notice problems with some apps (FTP for example) if I'm trying to use a TCP-based connection over a satellite link - lot of TCP RSTs and "Zero Window"-type errors in the sniff though on some satellite systems even UDP-based tunnels don't seem to work very well for anything other than low bandwidth applications. Thanks again...Nd On Sat, 18 Aug 2007 11:52:46 -0400 Michael_google gmail_Gersten <[EMAIL PROTECTED]> wrote: >On 8/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> I have several options - what's the issue w/ using TCP? > >TCP over TCP has some problems, the least/biggest of which is the >timeout factor. > >If there is a communication problem, TCP has a "back off and >resend" >rule. This starts with "I didn't get an acknowledgment. I might be >sending data too fast, or data might have gotten lost. I'll pause >for >two seconds, and then send the data again". > >The problem? If the low level TCP stream does this, then any >higher >level stream with data in transit will also see a delay, and a >need to >re-transmit. > >I may be doing a horrible job of explaining the problem. A simple >terminal session may have no problem -- a single packet of data >will >eventually get an acknowledgment back. > >But if there is a stream with more and more data behind it, then >you >wind up with an ever increasing resending that never gets caught >up. >Eventually all the TCP channels break. > >TCP was designed with certain assumptions in mind. It does not >work as >a general purpose transport -- that was never it's goal. > >IP over IP works. >UDP over UDP works if your UDP protocol supports it. >TCP over TCP fails. The timeout rules cannot stack properly. -- Make up to $100/hour by getting a Sports Medicine Degree. Click Now! http://tagline.hushmail.com/fc/Ioyw6h4fRPYLey2rvkF1ZXnAAaXHzBNMdDrODhnZzfDccOe6VWXOUx/
Re: Privoxy usage?
On 8/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I have several options - what's the issue w/ using TCP? TCP over TCP has some problems, the least/biggest of which is the timeout factor. If there is a communication problem, TCP has a "back off and resend" rule. This starts with "I didn't get an acknowledgment. I might be sending data too fast, or data might have gotten lost. I'll pause for two seconds, and then send the data again". The problem? If the low level TCP stream does this, then any higher level stream with data in transit will also see a delay, and a need to re-transmit. I may be doing a horrible job of explaining the problem. A simple terminal session may have no problem -- a single packet of data will eventually get an acknowledgment back. But if there is a stream with more and more data behind it, then you wind up with an ever increasing resending that never gets caught up. Eventually all the TCP channels break. TCP was designed with certain assumptions in mind. It does not work as a general purpose transport -- that was never it's goal. IP over IP works. UDP over UDP works if your UDP protocol supports it. TCP over TCP fails. The timeout rules cannot stack properly.
Re: Privoxy usage?
I have several options - what's the issue w/ using TCP? What vendor would you suggest? Thanks - Nd On Sat, 18 Aug 2007 08:14:36 -0400 Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: >> what may be useful is the transparent TCP proxy support in Tor >for >> ensuring the VPN connections are going through Tor. (VPN >software >> being difficult to SOCKS'ify so to speak) > >Ahem... if your VPN software is using TCP rather than UDP or raw >IP, >then I strongly recommend that you choose a different VPN vendor. > >Which means that until Roger, Nick and their basementful of slaves >implement a datagram transport for tor, it will not be possible to >run >a well-designed VPN over tor. > >Juliusz -- Make up to $100/hour by getting a Sports Medicine Degree. Click Now! http://tagline.hushmail.com/fc/Ioyw6h4fRPY5QYfMpqLNAqF4vqDdPixgg0w9TESiE4mcpBZeydX0VL/
Re: Privoxy usage?
> what may be useful is the transparent TCP proxy support in Tor for > ensuring the VPN connections are going through Tor. (VPN software > being difficult to SOCKS'ify so to speak) Ahem... if your VPN software is using TCP rather than UDP or raw IP, then I strongly recommend that you choose a different VPN vendor. Which means that until Roger, Nick and their basementful of slaves implement a datagram transport for tor, it will not be possible to run a well-designed VPN over tor. Juliusz
