[freenet-support] [freenet.uservoice.com] New message: 'Freenet V 0.7.5 Build #1401 and Thaw bot…'
Customer Feedback for Freenet Project Inc. freenet.uservoice.com [freenet.uservoice.com] New Bug Report sent a message from http%3A%2F%2Ffreenet.uservoice.com%2Fforums%2F8861-general [http%3A%2F%2Ffreenet.uservoice.com%2Fforums%2F8861-general] Freenet V 0.7.5 Build #1401 and Thaw both stopped connecting last week. Now Freenet 0.7.5 #1402 and #1403 don't start. What's wrong? Are there problems with the software? Problems with the servers? Can and will this be fixed? Is there anything I can do to fix these problems? I forwarded all the correct ports and allowed the use of Javascript through my firewall and my browser, but but these problems have occurred since. Firefox 3.6.3 (Windows 7) [http://uservoice.com]___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
[freenet-support] Freenet 0.7.5 build 1403
Freenet 0.7.5 build 1403 is now available, please upgrade! The main change is a fix for USK polling, which affected USK@.../-1/ lookups, but probably also bookmarks and Freetalk (caused by a low level change in ~ 1399). Thanks Eleriseth! Other changes, which have been in master for a while, include: - Merge operhiem1's work on the first time wizard. This is now much simpler for most people, and internally has been heavily refactored, as well as lots of tweaks including options for dealing with monthly bandwidth caps. - Write the peers file much less often, and write backups, which are only rotated when a significant change happens. - Always load plugins asynchronously - that is, don't wait for them to load before showing the plugins page. - Improve handling of bookmark links in the content filter (this was supposed to go in in 1398 but didn't). - Move the temp dir to "temp". It should not include the port number. Delete the old temp dir, it doesn't contain anything important. - Remove the node name from the page titles. - More detailed stats via FCP. - Fixes for binary blobs. Thanks to: Eleriseth operhiem1 saces ShareLink Bombe toad Apologies for poor network performance recently, I doubt that the USK fix will help much, but it is a known problem that we need to deal with. It might be partly related to the disruption around 1401 being self-mandatory, but there may be deeper problems, it will be looked into. If you have any evidence or information that might explain what the problem is please publish it / let us know ... signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] http fproxy ports are not closed
On Wed, 7 Sep 2011 17:50:36 +0100, Matthew Toseland wrote: > On Friday 02 Sep 2011 15:34:30 Dennis Nezic wrote: > > On Fri, 2 Sep 2011 14:40:22 +0100, Matthew Toseland wrote: > > > On Friday 02 Sep 2011 13:20:39 Dennis Nezic wrote: > > > > On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: > > > > > On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: > > > > > > On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: > > > > > > > netstat (netstat -pnat | grep java) shows 213 connections > > > > > > > to my fproxy at 127.0.0.1:, in a "CLOSE_WAIT" state. > > > > > > > I only noticed this after I could no longer access fproxy > > > > > > > -- probably because of some thread or connection limit. > > > > > > > I'm not exactly sure how to reproduce this -- it's not > > > > > > > simply a matter of opening a connection to fproxy. > > > > > > > > > > > > False alarm. I think my freenet wget spider got out of > > > > > > control. Apologies. > > > > > > > > > > Upon further consideration, I think it might actually be a > > > > > bug. For one thing, this never happened with earlier > > > > > pre-1401ish versions. For another thing, why are there so > > > > > many sockets open, when my wget client has long since closed > > > > > and exited? (it has been about half an hour now > > > > > -- I'll provide updates if they ever do close.) CLOSE_WAIT > > > > > apparently means fproxy got the FIN signal from my wget, but > > > > > didn't close it's end? > > > > > > > > > > I'm still not sure exactly how this bizarre behavior (of not > > > > > closing sockets) starts -- because if I restart freenet, and > > > > > do a simple wget transaction, the socket does get properly > > > > > closed. > > > > > > > > All those "HTTP socket handlers" are still open and consuming > > > > freenet threads. They were initiated by "wget > > > > localhost:/USK..." type calls > > > > -- and they probably failed because the sites were old. Normal > > > > browser access to control localhost: does still close the > > > > socket properly. > > > > > > Well what are they doing then? Still running the requests? This > > > is a fundamental problem with fetching stuff over HTTP from > > > Freenet with a low timeout - if your tool moves on to add more > > > requests, the old requests haven't failed, they are still going. > > > > They will go on forever? Fproxy will never close them? (Sounds > > pretty easy to DDOS that?) And why didn't this happen before? > > No, they go on until they complete. There is a limit on the total > number of connections handling requests, iirc the default is 100. Well, I just checked -- all the 80 connections that were opened a week ago are still open and still in CLOSE_WAIT. What does "until they complete" mean? Also, if I kept my wget spider running, it could easily use 213 or over, like it did when I first reported the problem, and eventually not let me back into fproxy :s. How does that fit into the 100 request limit? (Why isn't there a time limit, or an hop-limit again?) > > > Having said that it may eventually be possible to detect > > > connection closed - in 0.5 there was a hack for it. > > > > I think tcp's CLOSE_WAIT means fproxy should have already gotten a > > "close" signal, no? > > Surprisingly enough, we are not directly generating TCP packets > here... Huh? I meant, (I'm guessing), didn't my wget already send a "FIN" tcp message to fproxy at some point, which is what put those connections into CLOSE-WAIT? (a la http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm ), or am I missing something? ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] http fproxy ports are not closed
On Friday 02 Sep 2011 15:34:30 Dennis Nezic wrote: > On Fri, 2 Sep 2011 14:40:22 +0100, Matthew Toseland wrote: > > On Friday 02 Sep 2011 13:20:39 Dennis Nezic wrote: > > > On Fri, 2 Sep 2011 00:23:00 -0400, Dennis Nezic wrote: > > > > On Wed, 31 Aug 2011 15:02:14 -0400, Dennis Nezic wrote: > > > > > On Wed, 31 Aug 2011 09:44:17 -0400, Dennis Nezic wrote: > > > > > > netstat (netstat -pnat | grep java) shows 213 connections to > > > > > > my fproxy at 127.0.0.1:, in a "CLOSE_WAIT" state. I only > > > > > > noticed this after I could no longer access fproxy -- > > > > > > probably because of some thread or connection limit. I'm not > > > > > > exactly sure how to reproduce this -- it's not simply a > > > > > > matter of opening a connection to fproxy. > > > > > > > > > > False alarm. I think my freenet wget spider got out of control. > > > > > Apologies. > > > > > > > > Upon further consideration, I think it might actually be a bug. > > > > For one thing, this never happened with earlier pre-1401ish > > > > versions. For another thing, why are there so many sockets open, > > > > when my wget client has long since closed and exited? (it has > > > > been about half an hour now > > > > -- I'll provide updates if they ever do close.) CLOSE_WAIT > > > > apparently means fproxy got the FIN signal from my wget, but > > > > didn't close it's end? > > > > > > > > I'm still not sure exactly how this bizarre behavior (of not > > > > closing sockets) starts -- because if I restart freenet, and do a > > > > simple wget transaction, the socket does get properly closed. > > > > > > All those "HTTP socket handlers" are still open and consuming > > > freenet threads. They were initiated by "wget > > > localhost:/USK..." type calls > > > -- and they probably failed because the sites were old. Normal > > > browser access to control localhost: does still close the > > > socket properly. > > > > Well what are they doing then? Still running the requests? This is a > > fundamental problem with fetching stuff over HTTP from Freenet with a > > low timeout - if your tool moves on to add more requests, the old > > requests haven't failed, they are still going. > > They will go on forever? Fproxy will never close them? (Sounds pretty > easy to DDOS that?) And why didn't this happen before? No, they go on until they complete. There is a limit on the total number of connections handling requests, iirc the default is 100. > > > Having said that it may eventually be possible to detect connection > > closed - in 0.5 there was a hack for it. > > I think tcp's CLOSE_WAIT means fproxy should have already gotten a > "close" signal, no? Surprisingly enough, we are not directly generating TCP packets here... signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
