> Kad: Not running$ amuled &
$ amuleweb -P<password> -q &
With "normal" NAT anyone could reply or send sth to UDP port 33333 at my external IP and the data would be forwarded to myComp at 192.168.1.1:2222. Sth like 9.8.7.6:4444 --> 4.3.2.1:33333 --> 192.168.1.1:2222If that happens, then your router/firewall is not stateful, which is rare even in small modern routers (I use an old Netgear, and it's stateful). I think this is not default behavior. It would be a huge security threat to use such a router, since it would allow easy spoofing.
I'll try to have a look at it, but don't expect results soon or better don't expect any results as I frankly don't know anything about the network part of aMule codewise, only in an abstract way.
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 192.168.0.10:netbios-ns *:*
udp 0 0 *:netbios-ns *:*
udp 0 0 192.168.0.1:netbios-dgm *:*
udp 0 0 *:netbios-dgm *:*
udp 0 0 *:17315 *:*
udp 108324 0 *:17322 *:*
udp 0 0 *:bootpc *:*
> 2007-10-29 12:45:13: Connected to Kad (firewalled)
> 2007-10-29 12:45:13: Connected to Kad (ok)
> 2007-10-29 13:16:55: Disconnected from Kad
> 2007-10-29 13:16:55: Indexed.cpp(249): Kademlia Indexing: CInvalidPacket Exception
in CIndexed::readFile: CInvalidPacket: Integer tag expected, but found ""=Type=10
> 2007-10-29 13:16:55: RoutingZone.cpp(150): Read 200 Kad contacts
well for me this patch works:
if(Kademlia::CKademlia::GetPrefs()->HasLostConnection()) {
StopKad();
clientudp->Close();
clientudp->Open();
if (thePrefs::Reconnect()) {
StartKad();
}
Somewhere around line 1460 in amule.cpp.
But this is only a workaround because a new recvq is opened. Not the problem that the queue is becoming full is solved this way.
I'm using the cvs version of amule
amule-daemon 2.1.3+CVS20071029-1Hmm?
One the one handQuoteI'm using the cvs version of amule
but on the otherQuoteamule-daemon 2.1.3+CVS20071029-1Hmm?
Actually, you did not added to your previous report. We see KAD running and then disconnected. We also see reconnection attempt failed for no particular reason.
Nobody seems to be arguing that this isnt a bug. No new information was, however, provided on a nature of this bug.
I still blame WX.
Nobody seems to be arguing that this isnt a bug. No new information was, however, provided on a nature of this bug.
I still blame WX.
Sorry if I sounded a bit harsh.
I'd like to point to this error:
2007-10-30 10:10:51: Indexed.cpp(249): Kademlia Indexing: CInvalidPacket Exception in CIndexed::readFile: CInvalidPacket: Integer
tag expected, but found "^B"=Type=10
Maybe it has something to do with Kadmelia not connecting again. However, the WX bug (wx closing udp ports and forgiving them) looks a good candidate. Shouldn't the proposed fix (closing/reopening) be commited, so we can try if that solves the problem?
i think the indexing error is just a symptom of the udp bug (incomplete data ?) and i also agree with the assumption that the bug is hidden in wxwidgets somewhere.
call the topic:
search only works if connected to kad and ed2k but not if connected to kad only