Hi,

Napshare is very stable. The only problem to keep it working for days is
that I get IPs like 255.255.255.255:6346 (and others) in my gnutella host cacher. Those IPs cause messages like 'network unreachable (retrying)'. Moreover, napshare keeps retrying only those addresses. This makes any other connection impossible. I always have to remove it manually from the host cacher. Shouldn't those IPs which cause 'network unreachable' messages be automatically discarded from the host cacher?

How can I avoid this situation?

Thanks in advance,

Which cacher do you use?

Morgwen

Perhaps this link helps:

http://www.gnutellaforums.com/showth...&threadid=7473

Morgwen

Well, I meant the gnutellaNet host catcher list that appears on
the gnutellaNet window of Napshare.

I'm not running another host catcher to which napshare may connect.

I'm using a direct connection to internet and Debian GNU/Linux 2.2

This is no problem of your cacher! I use them with other clients without problems...

This is a problem of Napshare - perhaps a bug?

Morgwen

Sorry, thanks for explaining the problem better. Easy fix:

in hosts.c add this line in check_valid_host()

if (ip == (guint32) 0xFFFFFFFF) return FALSE;

so now it looks like the below (tabs are messed up here).
let me know if there are any other problems like this, 255.255.255.255 seems to be the only one that does this.

This solved the problem. Thanks.

Another IP caused the same problem but I don't remember it. If it appears
again I'll tell you about it.

Well, bad news.
I've got another IP which gave a network unreachable error:
224.18.19.8:6349

I still think it is better to discard an IP when a network unreachable
error is found, instead of retrying until the IP is manually removed.
Primarily, because no other IP is tried while napshare is connecting
to the unreachable address.

Is that possible?

That was a quick fix you could put in easy.
I updated CVS with a real fix that works. Try getting the anon CVS version, it has more automation features and filters too.
The whole block of 224.* IPs all fail for some reason with a 101 error. You could block them for now by doing something like this, but the fix on CVS is better. (0xE0 = 224 decimal)

if ((ip & (guint32) 0xFF000000) == (guint32) 0xE0000000) return FALSE;

Same problem here, but with 224.*.*.* .
Oviously, some clients send bogous IPs. Therefore, we should ignore 0.*.*.*, 127.*.*.* and [224-255].*.*.*, optionally (for bigger LANs the next adresses may make sense) also 192.168.*.*, 172.[16-31].*.* and/or 10.*.*.*.

An option to ignore search results from these adresses would also be nice.

ObInfo:
255.255.255.255: subnet-local broadcast, non-routable, no TCP.
224-: broadcast, reserved and experimental, partially no TCP.
127.*.*.*: test range, .0.0.1 is loopback test
0.*.*.*: some boot protocol
0.0.0.0: unspecified adress

10.*.*.*, 172.[16-31].*.*, 192.168.*.*: site-local adresses, not routable (at least it sould not be) on the internet. You're free to use them in your LAN. If you have one of those and connect to the internet, you are firewalled (even if you use port forwarding).
See "push request" from the readme for additional infos.
(HINT: select "never send push request", except for large LANs with local gnutella server.)

Delaying/retrying on network unreachable is not a bad trick if you wait for a temporarx connection problem, but there should be a timeout.

BTW: There should be an option to automatically use the reflected IP.