Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Radek]

@skolnick
NAT behaviour and stateful inspection are two different things. A NAT is only stateful insofar, as it may (depending on the kind of NAT) close the punched "hole" again after a while without traffic. The rest is for the firewall/packet filters.

I meant the NA(P)T implementations in quite a lot of routers. I had to do with this kind of problems because I experimented with VoIP and NAT used to be one of the biggest problems for beginners in that field. I gave some help in forums at that time.
So I found out that a lot of methods (STUN) didn't work for me, because I always have used routers of a more 'sophisticated' kind (aka normally not working "out of the box", but a lot of possibilities instead after one invested some hours in RTFM).

For some VoIP-providers for example I always had to manually set the external SIP port to the same port number as the one I wanted to connect to. Strange things happened with the different implementations of the SIP servers.

So I tend to search for protocol problems in that same direction. But it's of course just kinda brain storming atm. Some interesting links: RFC3489 (STUN) and Wikipedia (NAT)

I believed for some time, that I had found some link between the disconnect intervals and the amount of downloads I had. Normally I have few to none active downloads but have mostly "releases" and other uploads.
It's some time ago I used to watch all that, but I think the time Kad stayed connected, was noticeably longer, when I had some active downloads. This lead me to the conclusion, that there was some connection with the traffic on Kad.

@Kry
My ISP, for example, does not block any ports or regulate traffic (apart from technical failures on their side ).

And even if my ISP would do that - what should be the difference for them between restarting amuled and reissueing the command "connect kad" and doing the latter without the first? Both should show the same results, when monitored from outside, I think. The only difference might be the absence (or not) of connection to some ed2k server. When I start amuled I normally enter "connect kad" first and "connect <IP>:<port>" later. Whereas I normally stay connected to some ed2k server when Kad disconnects and only try "connect kad" then.

[skolnick]

Hi Radek!

I never talked about stateful packet inspection. I know that is for firewalls and similar devices. I just talked about stateful as in "it keeps states". Just like any protocol, if you do not follow the protocol but send a random message, you cannot expect it to be responded correctly. Only non-stateful protocols do that (like sending a SYN+ACK with no previous SYN...that would mean RST on most modern TCP stacks. That was what I was refering to, the fact that the NAT keeps (or should keep) the state of the packets going in or out. Nothing to do wht SPI.

Regards.

[gmemon]

I am running amuled on FC3 and I am having a similar problem. I did some poking around and found that after some time the amuled simply stops reading packets from its UDP buffer. This can be because of a bug in the code (not handling proper interrupts from the OS)  or in the OS itself (not sending proper interrupts). This leads to packet drops and amuled will disconnect itself from the Kad network if it does not receive any packet for 20 minutes. The reason Connect Kad does not work from amulecmd is the same. amuled tries to reconnect by sending out new packets but its buffer is still full so the packet drop continues. However if you restart the process then the buffer is cleared by the OS and everything is as good as new.

As somone mentioned that his/her amuled works fine on FC6 so I am moving to FC6 and will update you guys if I see any progress.

[gmemon]

No luck with FC6. I think it has to do something with the code. There is some segfault which stops the process from reading its UDP buffer. In the meanwhile I am back to running GUI version of amule. I hope that works without problems

[wuischke]

Please create a backtrace for this issue. (http://www.amule.org/wiki/index.php/Backtraces)
That's the only way for the developers to know about the reasons of the problem.

[Radek]

Hi!

I googled a little and found this in the wine bugtracker! It sounds (reads) very familiar!

Basically they have similar problems with UDP ports not working anymore after some amount of time. Though this is about eMule and µTorrent under Wine, it could very well give some hints...

The theory developed in the above bugtracker entry is: when someone does a select() on a (UDP) port to check for input data he might get the result that some data has arrived and, when trying to read the data, get an error that no data is available. Such things seem to happen under Wine, if the arrived packet turns out to have errors (bad checksum), which causes it to be dropped by the underlying libraries.

Maybe this isn't really a problem of Wine, but of the host system?! If this is the case, it might very well be the same problem here. I didn't check the amule sources, yet, to see if this select()/read()-mechanism is used here, but it's very likely as that is  "standard procedure".

Coincidentally, I did some sniffing on my linux box running amule (tcpdump with "udp port xxxx") yesterday and checked the captures with WireShark. I found out that every packet sent by amuled on my linux box was flagged with "[UDP CHECKSUM INCORRECT]", whereas no packet received had this flag. At that time, Kad was connected and running.
So, either WireShark makes some mistake or amuled sends incorrect UDP packets, which could lead to the above errors.

Next piece of the puzzle:
Today I compiled the new snapshot and restarted amuled. Kad was "connected(ok)" after a few seconds. 3 hours later Kad is still ok, but the "Recv-Q" on the box is growing rapidly (netstat -l)! That should never happen, I believe, and fits in the above theory...

Cheers

[gav616]

theres an unofficial patch out for wine that might fix the disconnecting...OS side mostly

[Radek]

@gav616
Yes, I read that in the bugtracker, too, but unfortunately our problem here isn't directly related with Wine. I mentioned Wine because of similarity of symptoms and, seemingly,  chain of events, too.

@all
Addition to my last post:
A few minutes after writing the above post, the status of Kad changed to "Not connected"! The receive queue of my UDP port stays at 110464, which might be some buffer limit, that is reached now.

I think, we may have hit something here...

Cheers

[gmemon]

This is exactly what I said in my post earlier that UDP buffer grows and after some time Kad gets disconnected.

An addition is that on Fc6, if I run only 1 amuled then it runs fine. Only when I run multiple amuled then they start crashing one by one.

[xor]

Hi.

I have the same problem here. I'm running debian sarge. I've compiled myself wxBase 2.6.3 and aMule 2.1.3, and after some time (usually 5 hours or so) kad stops and would not reconnect. The UDP rec. queue has 109328 unprocessed packets, so no matter you try to restart it, it wont run anymore.

I've changed the code in amule.cpp to instead of just stoping kad, close the UDP port and reopen it again to clean the queue ( just add clientudp->Close(); clientupd->Open(); ), then StartKad() again. It's ugly, but it works. I have no clue about why the UDP cue gets full, but definitively this is the reason Kad stops working eventually. Maybe is  a wxWidgets problem. I've downloaded wxBase 2.6.4 but I've not tried it yet.

Hope this helps.

[Menion]

Same problema also here, amuled built on a May SVN, running on a Kurobox (NAS with PowerPC), Kad disconnected after a while, reconnect, disconnect, and so on for few times, after it dosconnects without reconnecting any more. I had this problem from the day I start using amuled (last summer). Connecting to internet via WiFi router with Firewall on and stateful packet inspection ON. Bye!

[realcruncher]

Hi there,

this problem is still not fixed. Some time ago i already suggested to close and reopen the UDP port and obviously it is a workaround for this problem.
Now with this new discovery about the RECVQ i think this i a programming error. Somehow amule doesn't read or reset the queue until it is full.
Even if you don't have these errors why don't you just code the workaround and maybe look for a missing read ? This wouldn't harm you, right ?

Thanks,
realcruncer

[wuischke]

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.

[realcruncher]

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.

[traycold]

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.

hi, i'm experiencing the same problem. I use amuled, CVS version, on Debian (i used the stable 2.1.3 version, but the problem was the same).
The ports are set up correctly, and in fact both the server and the kad networks are ok when amueld start. But after some time (half an hour in this case) kad disconnect (amulecmd reports: "Kad not connected") and the amulecmd command to reconnect is useless in this case.
As indicated before on this forum, i launched the command: "netstat -lu" (after Kad disconnected) and the output is:

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                *:*

and these are the relevalt amule log lines:

 > 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

do you have any news about this bug or any idea on how to solve it? thanks