Print

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

[named]

I'm running latest SVN version and I'm having trouble connecting to Kad. Problem is that it's always disconnected, even if I try to bootstrap from known clients, even if I update the nodes.dat from http://emule-inside.net/nodes.dat. After some googling around I saw some inconclusive reports that there might be some problem with aMule-SVN and Kad. (If it is a kown issue, sorry for the spam.)
I checked and rechecked my setup (opened/forwarded ports, etc.). Everything seems to be ok. Still Kad's not working.
Finally I decided to give nmap a go. TCP port was ok, however, when I tried the UDP port:

Code: [Select]

nmap -sU -p 51111 127.0.0.1I would sometimes get:

Code: [Select]

51111/udp closed unknownand sometimes:

Code: [Select]

51111/udp open|filtered unknownRegardless of nmap output, these messages cropped up in aMule log:

Code: [Select]

2008-01-31 03:03:36: MuleUDPSocket.cpp(308): MuleUDPSocket: Socket died. Recreating socket.
2008-01-31 03:03:36: MuleUDPSocket.cpp(87): MuleUDPSocket: Shutting down Client UDP-Socket
2008-01-31 03:03:36: MuleUDPSocket.cpp(79): MuleUDPSocket: Created Client UDP-Socket at port 51111

[named]

It would be greatly appreciated if anybody could corroborate or refute this.

[phoenix]

Hi named,

I am not able to reproduce it here, Kad works fine for me.

About the messages you get, we can see that they are normal (in a wx sense  ), though it does not happen to me:

Code: [Select]

case wxSOCKET_INVSOCK:
// Once in a while, wxDatagram sockets have a tendency
// to suddenly become invalid. In order to work around
// this problem, we simply create a replacement socket.
AddDebugLogLineM(true, logMuleUDP, wxT("Socket died. Recreating socket."));
DestroySocket();
CreateSocket();
break;The other two log messages come from DestroySocket() and CreateSocket() respectively.

If you ask me for a wild guess, there is some other program messing with iptables. Other than that, I can't imagine what is going on.

What is the wx version that you are using?

[named]

Thanks for the reply, phoenix,

My destop PC is behind a router/firewall and I have turned off iptables. (Port forwarding is okay, I have already confirmed that.) Do I have to have iptables running to get Kad connected? That would be strange.

Wx version is 2.8.7.

Edit: I have also turned off all firewall related options in my kernel setup. (If that could explain something.)

[phoenix]

Hi named,

You seem to be doing everything correctly. You do not need iptables running, it is actually easier to set up without it running.

Is there any chance you could sniff the network with wireshark to try to figure out what condition triggers the UDP failure. With some filters set you could probably be able to catch only Kad traffic. This is not a simple task, but might worth the work.

[named]

Hi phoenix,

I followed your advice and gave wireshark a go. In order to be able to better see what was going on, I stopped all other network activities, disabled ed2k, so I had only Kad on. Following a fresh download of nodes.dat from http://emule-inside.net/nodes.dat, I could see a lot of outgoing UDP activity:

Code: [Select]

1447 805.345120 <my internal ip> <some external ip> eDonkey Kademlia UDP: KADEMLIA_REQ
1448 808.126311 <my internal ip> <some external ip> eDonkey Kademlia UDP: KADEMLIA_REQ
1449 809.907461 <my internal ip> <some external ip> UDP Source port: <my UDP port>  Destination port: 9869
1450 810.688628 <my internal ip> <some external ip> eDonkey Kademlia UDP: KADEMLIA_REQ
1451 813.470115 <my internal ip> <some external ip> UDP Source port: <my UDP port>  Destination port: vision_server
1452 815.251340 <my internal ip> <some external ip> eDonkey Kademlia UDP: KADEMLIA_REQ
1453 817.032526 <my internal ip> <some external ip> UDP Source port: <my UDP port>  Destination port: 25472
...........................

However there were no incoming UDP packets. So I thought that it was the router after all that was faulty. Checked the forwarding rule again and tried an online port scanner - http://www.auditmypc.com/port-scanner.asp. This is what appeared:

Code: [Select]

1330 730.241144 130.94.69.111 <my internal ip> UDP Source port: vpvc  Destination port: <my UDP port>

So apparently the router is configured properly and the port is forwarded to my internal ip address and my UDP port.

I am really at a loss here. Your help would be really appreciated.

[sborel]

Hi,

I experience the same behaviour. Both UDP sockets are open according to netstat but a local nmap shows that:
- the UDP port for extended server request is open just after starting aMule and closed some time after
- the extended client UDP port is always closed.

Not sure if this matters: box is running ubuntu gutsy x86_64, with amule 2.1.3 ad wx 2.8.4.

[Xaignar]

This seems to be caused (at least in part) by problems in the wxWidgets datagram-socket code ... I'm trying to figure out how to fix it, but we probably won't be able to do anything but work around it in aMule itself.

[Xaignar]

Ok, here's a bit of an explanation: The reason why nmap reports that the sockets are closed is that wxWidgets is buggy*, and the empty UDP packet sent by nmap causes the socket to close. However, I'm not sure if that is what causes your original problem, though I suspect that it's related. I'll try to improve the workaround for this situation, so that the sockets gets reoped as soon as its closed.

* I've submitted a patch, which should hopefully resolve this problem.

[phoenix]

named,

Xaignar has committed a patch that improves handling of invalidated UDP sockets. But I must agree with him in that it is probably not what causes your original problem.

I don't know exactly how this port scanner works (btw, I will check, thanks for the link!), but I imagine that if he could pass a few UDP packets through the router, then it considers it forwarding.

I have had a problem here with a WRT54G model 5 router that was driving me crazy, made me call the ISP support and look like a fool. It simply could not handle the reasonable intense ( ?, over the mean to be fair!) UDP traffic, and was dropping some UDP packets. When aMule was not running, I got near 100% success. When aMule was running, it entered an "UDP Dropping Mode (TM)" and even after stoping aMule it would behave badly. Turning the router off and on was the only way to make it work again. I have discovered it the hardest way, by faults in other UDP applications I was running.

I soon found out that model 5 WRT54G was a totally different hardware/software than it's great successor, model 4. LinkSys, now under Cisco has fooled me by making me believe it was a minor improvement by bumping the model number, when in fact it had less memory than before and no longer used linux. With such a big changes, I would never consider it a sucessor. It was a new product and far from beeing mature. I have returned it to my local dealer and changed it by an equivalent 3Com. And lived happy ever after.

Sorry for the long post, but to resume what I think, do not discard the possibility that your router is dropping UDP traffic at random.

Please, test tomorrow svn and report any changes. Thanks again for your support and patience.

[sborel]

I compiled today's CVS and I'am happy to say there is an improvement: before the Kad connection was first firewalled then off. Now it's stay firewalled and if the socket gets 'corrupted' by a nmap packet it gets re-recreated. However it does not solves the problem. I see packets received on my UDP port in the tcpdump traces, so I guess my forwarding/firewall settings are correct, but there are very few of them compared to the large number of requests. Maybe my router drops packets like in your case ... but I can't see anything obvious from the logs.

[sborel]

I hate to reply to my own post, but just to notify that the Kad connection is now working. It just seems it took a long time, but this new SVN version fixes the problem in my case.

[phoenix]

Replying to your own post is ok. This is really good news! Thank you for all the help.

[named]

I finally got around to sharing my latest experiences with amule+kad. Unforunately for me the problem still persists. I simply can't connect thru kad. In an attempt to pinpoint the problem I tried emule+wine using the same ports I assign in amule. emule connects kad immediately, searching thru kad works, downloads work with only kad enabled. emule online port test (http://www.emule-project.net/home/perl/general.cgi?rm=porttest&tcpport=XXXXX&udpport=XXXXX&lang=1033&l=1) reports all ports ok. So I have managed to definitely rule out my lan setup, port frowarding, fiewall, OS... Only thing that remains is amule itself.

When I closed emule, I tried amule again. Briefly it reported connected to kad. But I suspect that these were connections initiated by emule on the same ports. So not really amule's merit. Searching kad didn't work, downloads also. Soon kad was disconnected again and upon restart this time it simply stayed disconnected. I also tried emule's port test page with amule running (using the same ports). This time it failed.

There is something really strange. I can see amule sending out kad requests. On its own it never gets replies. With emule having initiated some connections amule detects the incoming udp traffic and reports itself connected. So maybe (and this is just a guess) kad packets sent out by amule get rejected by the other clients and amule can't connect. Maybe. But why?

[named]

Anybody with an idea?
How can I check if the kad requests/hellos amule sends out are valid?