I need info on this problem to fix it. If someone is able to provide me the UPnP logs (enable it in preferences) and the libupnp debug logs (must compile it by hand and provide the files IUpnpErrFile.txt and IUpnpInfoFile.txt that are generated at the directory where aMule is run), I would be glad.
Hello,
I'll try to shed some light on the issue. The upnp package I've used (downloaded and
compiled with debug msgs) is 1.6.6 from upnp.sf.net.
Then I've recompiled aMule 2.2.1 with upnp support and enabling debug. Performing an
"ldd" on aMule binaries libupnp does not appear (don't know why but probably it is not
an issue).
On startup here it appears the messages hruotland mentioned:
2008-07-08 20:42:53: UPnP.cpp(87): Universal Plug and Play: error(CDynamicLibHandle): Unable to dlopen libupnp.so.2. Check PATH and LD_LIBRARY_PATH.
2008-07-08 20:42:53: UPnP.cpp(91): Universal Plug and Play: Successfully opened libupnp.so.3.
2008-07-08 20:42:53: UPnP.cpp(1063): Universal Plug and Play: bound to 10.0.0.254:49152.
2008-07-08 20:42:53: UPnP.cpp(1134): Universal Plug and Play: UPnP Error: CUPnPControlPoint::AddPortMapping: Wan Service not detected.
Apparently aMule at first is looking for the libupnp .so file belonging to a 1.4.x version
(libupnp.so.2), then correctly detects the installed version (libupnp.so.3 belonging to
libupnp 1.6.x).
I'll attach the file "IUpnpInfoFile.txt" as per your request. The file "IUpnpErrFile.txt"
is created but not populated (sticks to zero bytes).
I've noticed that on file upnp/src/genlib/miniserver/miniserver.c of libupnp srcs there's
such a statement:
#define APPLICATION_LISTENING_PORT 49152
this may be the reason why he's using that port in the first place. Opening the port on
the router doesn't change the erratic behaviour. I didn't find any trace of the other port
(60776), so maybe the choice is based on another logic.
Is it possible that some code in UPnp.cpp should be changed for newer libupnp?
This is as far as I can go :-), hope all this helps
Thanks for your help.
Jman