gtk-gnutella-devel Digest, Vol 31, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 31, Issue 1
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: Foxy 1.9.9.0 in hostcache? (Christian Biere) 2. Re: Foxy 1.9.9.0 in hostcache? (Christian Biere) 3. crash from SVN 16943 (assertion SOCKET_MAGIC == s->magic) (Meelis Roos) 4. a question (rick james) 5. Re: a question (Raphael Manfredi) 6. The problem on DragonFly platform (Hasso Tepper) 7. Re: The problem on DragonFly platform (Raphael Manfredi) 8. Crash from GUI (Meelis Roos) ---------------------------------------------------------------------- Message: 1 Date: Sun, 14 Jun 2009 03:34:47 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <20090614013447.GC3970@...> Content-Type: text/plain; charset=utf-8 Michael Rogers wrote: > Matthew Lye wrote: > > I'm noticing an extraordinary number of outgoing attempts to connect > > to Foxy 1.9.9.0 clients in Taiwan and Hong Kong as GTKG starts up, > > here. Could the [swarms of] Foxy clients which are [always] failing > > to connect as incoming connections nonetheless be ending up in the > > GTKG hostcache? That's possible. I've also noticed many incoming connection attempts from Foxy peers. > I don't know if this is related, but Foxy clients frequently hit the > gwebcaches operated by LimeWire - maybe GTKG is picking up their > addresses from there? It's rather the other way around. I don't see a noticable amount of outgoing connections but a steady stream of incoming connections. > I though ghostwhitecrab was configured to ignore > requests with net!=gnutella, but possibly not. It's quite possible that some cache spoiling is going on but I doubt this happens through ghostwhitecrab. Foxy has actually it's own GWebCaches listed at gcachescan.jonatkins.com. The ones using FTWebCache and jumswebcache are apparently dedicated to Foxy. Looking at the requests rates, use of GWebCaches and GDNA under the hood, tells me the Foxy "developers" screwed up on an epic level just like those Morpheus guys years ago. Nonetheless, the quality of GWC/UHC responses is, in fact, very poor. Many reported peers are fakes, spammers and zombies. Though that's just a mirror of the network which doesn't look any better. -- Christian ------------------------------ Message: 2 Date: Sun, 14 Jun 2009 22:55:22 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Foxy 1.9.9.0 in hostcache? To: gtk-gnutella-devel@... Message-ID: <20090614205522.GD1871@...> Content-Type: text/plain; charset=utf-8 Matthew Lye wrote: > I'm noticing an extraordinary number of outgoing attempts to connect > to Foxy 1.9.9.0 clients in Taiwan and Hong Kong as GTKG starts up, > here. Could the [swarms of] Foxy clients which are [always] failing > to connect as incoming connections nonetheless be ending up in the > GTKG hostcache? I've looked at some of the handshakes. Apparently, they always hang up after the first handshake response which seems to indicate they don't like some of the parameters. Maybe they just hang up due to the missing "X-Auth-Challenge" in the response. These handshakes look more or less like normal Gnutella handshakes. According to my information though Foxy isn't based on Gnutella but G2, the handshake doesn't indicate this. I've seen a search result from Foxy exactly once so far. So Foxy doesn't really seem to be using Gnutella. The easiest option would be banning them by their identification. The last thing Gnutella needs is another abusive parasite. Their IP addresses might end up in the cache due the Listen-IP header in the first handshake request. This should certainly be avoided. -- Christian ------------------------------ Message: 3 Date: Fri, 19 Jun 2009 12:38:03 +0300 (EEST) From: Meelis Roos <mroos@...> Subject: [gtk-gnutella-devel] crash from SVN 16943 (assertion SOCKET_MAGIC == s->magic) To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0906191225480.13995@...> Content-Type: text/plain; charset="iso-8859-15" Got this after 3.5 days uptime, running as ultrapeer: (gdb) bt #0 0xb7f1c410 in ?? () #1 0xbfc1349c in ?? () #2 0x00000006 in ?? () #3 0x00001c7f in ?? () #4 0xb75d8811 in raise () from /lib/tls/i686/cmov/libc.so.6 #5 0xb75d9fb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #6 0xb78bd0b4 in IA__g_logv (log_domain=<value optimized out>, log_level=G_LOG_LEVEL_ERROR, format=0xb78e7880 "file %s: line %d (%s): assertion failed: (%s)", args1=0xbfc13a7c "?.'\b\222") at gmessages.c:497 #7 0xb78bd0e9 in IA__g_log (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0xb78e7880 "file %s: line %d (%s): assertion failed: (%s)") at gmessages.c:517 #8 0xb78bd167 in IA__g_assert_warning (log_domain=0x0, file=0x8272ec8 "sockets.h", line=146, pretty_function=0x829a960 "socket_check", expression=0x8272ed2 "SOCKET_MAGIC == s->magic") at gmessages.c:552 #9 0x0812c86b in socket_evt_set (s=0xbddf9630, cond=INPUT_EVENT_RX, handler=0x80d29c9 <io_read_data>, data=0xbeb0a5e4) at sockets.h:146 #10 0x080d291f in io_get_header (resource=0xbe79f200, io_opaque=0xbe79f310, bws=BSCHED_BWS_IN, s=0xbddf9630, flags=<value optimized out>, done=0x80909af <call_download_push_ready>, start=0, error=0x834ab20) at ioheader.c:493 #11 0x080967e1 in download_push_ack (s=0xbddf9630) at downloads.c:12179 #12 0x0812edd4 in socket_read (data=0xbddf9630, source=118, cond=<value optimized out>) at sockets.c:1573 #13 0x0822e2b2 in dispatch_poll (unused_source=0x83c0200, unused_cond=G_IO_IN, udata=0x83a4520) at inputevt.c:714 #14 0xb78ddcbf in g_io_unix_dispatch (source=0x83c0248, callback=0x822e142 <dispatch_poll>, user_data=0x83a4520) at giounix.c:162 #15 0xb78b4771 in IA__g_main_context_dispatch (context=0x83c0380) at gmain.c:2045 #16 0xb78b77e6 in g_main_context_iterate (context=0x83c0380, block=1, dispatch=1, self=0x83c2eb8) at gmain.c:2677 #17 0xb78b7ba7 in IA__g_main_loop_run (loop=0x909efd8) at gmain.c:2881 #18 0xb7d4c281 in IA__gtk_main () at gtkmain.c:1003 #19 0x081804ee in main_gui_run (geometry_spec=0x0) at main.c:695 #20 0x08056531 in main (argc=1, argv=0xbfc140a4) at main.c:1616 -- Meelis Roos (mroos@...) ------------------------------ Message: 4 Date: Wed, 8 Jul 2009 20:10:00 -0400 From: rick james <rj1961r9@...> Subject: [gtk-gnutella-devel] a question To: gtk-gnutella-devel@... Message-ID: <b72da3d30907081710g92149c2ud3cc1ecc0e1ce11@...> Content-Type: text/plain; charset=ISO-8859-1 Hi, I was wondering exactly how do I get gtk-gnutella to use the current local/private 192.*.*.* IPadress instead of the public 76.*.*.* adress it seems to want to default to on my laptop. I've got packet forwarding up and running using the wlan interface and software like deluge have no problems with seeing and using forwarded ports using the 192.* adress But gtk-gnutella seems to insist on using the public 76.* IP adress and not seeing the the current portforwared 192.* adress or that's the impression i'm getting because gtk-gnutella keeps saying I'm firewalled even though I'm telling it to use the opened port if you understand what I'm saying. I'm most likely not doing a good job of explaing what i'm running into here, huh? ------------------------------ Message: 5 Date: Thu, 9 Jul 2009 08:49:55 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] a question To: gtk-gnutella-devel@... Message-ID: <h34avj$3hb$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting rick james <rj1961r9@...> from ml.softs.gtk-gnutella.devel: :But gtk-gnutella seems to insist on using the public 76.* IP adress :and not seeing the the current portforwared 192.* adress or that's :the impression i'm getting because gtk-gnutella keeps saying I'm :firewalled even though I'm telling it to use the opened port if you :understand what I'm saying. Maybe I'm not understanding your issue fully but you need to know how things work to properly diagnose whether there is a problem in your configuration or whether there is a problem in the way GTKG works currently. The IP address that GTKG wants to use is the IP address that remote peers report you have when you connect to them. The "firewalled" status is computed by looking at whether you do get incoming connections to the advertised port or not, on your external IP address. The proper configuration therefore is to make sure the public IP router will have a rule to forward your listening port to your local machine. For instance, imagine your LAN address is 192.168.0.1 and your external IP address is 76.0.0.1, with your local listening port set to 12345. Locally, GTKG listens to 192.168.0.1:12345 but it is going to advertise 76.0.0.1:12345 to the world. Therefore, on your 76.0.0.1 box, you need to forward port 12345 to 192.168.0.1 and everything will work fine. Raphael ------------------------------ Message: 6 Date: Tue, 14 Jul 2009 00:21:48 +0300 From: Hasso Tepper <hasso@...> Subject: [gtk-gnutella-devel] The problem on DragonFly platform To: gtk-gnutella-devel@... Message-ID: <200907140021.48125.hasso@...> Content-Type: text/plain; charset="iso-8859-1" Hi, I happen to be a person taking care a lot of pkgsrc (www.pkgsrc.org) packaging work for DragonFly (www.dragonflybsd.org) platform. Recently I received a report from user that gtk-gnutella doesn't build on DragonFly. The problem is in the src/lib/entropy.c in SHA1Input(&ctx, f, sizeof *f); calls. FILE is an opaque (incomplete) type, so sizeof(FILE) just fails to build on DragonFly. As I don't understand the code very well and why the size of struct FILE is needed at all (is it really the data which is needed there?), no patch to apply from me. regards, -- Hasso Tepper ------------------------------ Message: 7 Date: Tue, 14 Jul 2009 06:58:11 +0000 (UTC) From: Raphael_Manfredi@... (Raphael Manfredi) Subject: Re: [gtk-gnutella-devel] The problem on DragonFly platform To: gtk-gnutella-devel@... Message-ID: <h3haa3$96g$1@...> Content-Type: text/plain; charset="iso-8859-1" Quoting Hasso Tepper <hasso@...> from ml.softs.gtk-gnutella.devel: :As I don't understand the code very well and why the size of struct FILE :is needed at all (is it really the data which is needed there?), no patch :to apply from me. The purpose of the code is to get a much random information as possible to get an hopefully unique 160-bit value. The information in the FILE structure would yield platform-specific information, especially as it changes whilst we read from the file because each stdio has its own way of updating the structure. That is another source of entropy, but it's not completely random in that it's predictable on a given system. Since we already collect enough entropy out of the system, I've removed the problematic calls from the code in r16947. Raphael ------------------------------ Message: 8 Date: Thu, 16 Jul 2009 09:00:16 +0300 (EEST) From: Meelis Roos <mroos@...> Subject: [gtk-gnutella-devel] Crash from GUI To: gtk-gnutella-devel@... Message-ID: <Pine.SOC.4.64.0907160857140.173@...> Content-Type: TEXT/PLAIN; charset=US-ASCII I had rev 16943 running for quite some time. Today opened the search pane with F8, clicked on another search and gtk-gnutella crashed. Backtrace below, if it's of any use. Program terminated with signal 11, Segmentation fault. #0 0xb79cd314 in IA__g_object_remove_weak_pointer (object=0x1, weak_pointer_location=0x9670518) at gobject.c:1543 1543 gobject.c: No such file or directory. in gobject.c (gdb) bt #0 0xb79cd314 in IA__g_object_remove_weak_pointer (object=0x1, weak_pointer_location=0x9670518) at gobject.c:1543 #1 0xb7c8562b in queue_item_free (item=0x9670518) at gdkgeometry-x11.c:1025 #2 0xb7c857c7 in _gdk_window_process_expose (window=0xa8c2578, serial=46624709, area=0xbf97c29c) at gdkgeometry-x11.c:1185 #3 0xb7c82456 in gdk_event_translate (display=0x83fd0a8, event=0xacd0c10, xevent=0xbf97c2fc, return_exposes=0) at gdkevents-x11.c:1630 #4 0xb7c82b57 in _gdk_events_queue (display=0x83fd0a8) at gdkevents-x11.c:2225 #5 0xb7c82ebf in gdk_event_dispatch (source=0x8401e28, callback=0, user_data=0x0) at gdkevents-x11.c:2285 #6 0xb7952771 in IA__g_main_context_dispatch (context=0x83c0380) at gmain.c:2045 #7 0xb79557e6 in g_main_context_iterate (context=0x83c0380, block=1, dispatch=1, self=0x83c2eb8) at gmain.c:2677 #8 0xb7955ba7 in IA__g_main_loop_run (loop=0x853ed58) at gmain.c:2881 #9 0xb7dea281 in IA__gtk_main () at gtkmain.c:1003 #10 0x081804ee in main_gui_run (geometry_spec=0x0) at main.c:695 #11 0x08056531 in main (argc=1, argv=0xbf97c5e4) at main.c:1616 -- Meelis Roos (mroos@...) ------------------------------ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 31, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
