Bill Pringlemeir wrote: > > Bill Pringlemeir wrote: > >> I have a number of CLOSE_WAITs from a node.
> >>> netstat -tn | grep CLOSE_WAIT | grep 69.120.111.63 | wc > >> 15 90 1215 > On 5 Feb 2006, [EMAIL PROTECTED] wrote: > > That's Cablevision. They don't provide Internet access only > > something remotely similar. I suggest to read this thread: > > http://groups.yahoo.com/group/the_gdf/message/22192 > > I guess it would be a good idea to enforce TLS for ranges known to > > be broken. Of course, nobody else supports it. > I see. I didn't compile with TLS because I have OpenSSL and I didn't > want to install another SSL library. I think it's legal to provide an ability to compile GTKG against OpenSSL but offering pre-compiled binaries is not possible due to license incompatibilities. OpenSSL does not the usual BSD-License but something more restrictive. Of course OpenSSL and GNU TLS are not drop-in replacements for each other but they offer more or less the same facilities in different ways. This would only help people that compile gtk-gnutella themselves. For source-based package distributions like pkgsrc or Gentoo this doesn't really matter since they will install dependencies automagically anyway. Such packages would only be marked source-only. However, if both is supported there's little reason to pick OpenSSL then. > Also, I thought it was paranoid > to run this and I didn't want to allocate the CPU to encipher/decipher > traffic. It doesn't seem to be so heavy on resources but I haven't run any benchmarks. > However, even if I compile with TLS, the lime wire client probably > won't have this feature. So I will have the same result. Can I ban > the the cable vision subnet? I guess I just add this to hostiles.txt. If you do this it's best to add it to the ~/.gtk-gnutella/hostiles.txt and not the system-wide one. Otherwise, you might lose these ranges by an update. Of course the other one can be made system-wide too using a (sym-)link. On the other hand, you're doing Cablevision a favour if you ban their range. So far, it does not seem as if all customers are affected. Maybe these filters are only active for certain sub-nets, customers or require certain router models etc. As far as I know, these filters don't apply to outgoing connections. So you'd even block these incoming connections. > That does seem rather dramatic. But it would work for now... Or I > can live with these dropped connections. I wonder if other clients > could use stunnel to tunnel out of these networks to GTKG nodes? I don't know whether stunnel supports the ciphers used by gtk-gnutella. If it does, it should work but it would require that someone installs and configures it first. So it's pretty unlikely that anyone uses this and you could still only contact peers that support this which is a very low number for now. -- Christian
pgpKbKMyejoQq.pgp
Description: PGP signature
