From IRC, where no one responded after around five hours:
Heyas, using ktorrent 3.2.2 inside kde 4.2.4, running on Gentoo Linux. For some odd reason, ports on my desktop (6881 for torrents/DHT, 4444 for that other thing) forward fine, but on my laptop (6882 for DHT/torrents, 4445 for that other thing), DHT doesn't seem to get 6882 forwarded via uPnP.... Any ideas on what gives?
I am running a custom-built router, it's also on gentoo linux, using miniupnpd as my upnp server, iptables as my firewall, so if someone's willing to help me track down the issue, I've got plenty of control over everything on the network.
Also, nothing else is using UDP or TCP 6882, so it _SHOULD_ be able to get it forwarded.

-----------------------

Well, since I couldn't watch IRC like a hawk day and night to see if someone answers, I came here. I tried deleting the ~/.kde4/share/config/ktorrentrc as well as messing with various options in there, to no avail. The settings are back to their defaults, with DHT and upnp turned on. Thus, port 6881 for DHT and for the torrents themselves, and 4444 for the UDP tracker port.

I run a very similar install, Gentoo (but 64-bit) with KDE4.2 and ktorrent 3.2.2. That box has NO ISSUES at all forwarding all three ports (6882 and 4445 instead), but my laptop still just convinces miniupnpd on my router to forward TCP 6881 and UDP 4444.

---------

Just did some further investigation. miniupnpd forwards ports in both the NAT table and the regular one, but for some reason the forward for 6881 gets put into the NAT table, but NOT the regular one. It looks like this MIGHT be some kind of bizarre miniupnpd error, but I'd like to check this out from all angles first as my desktop never had any trouble getting ports to forward when it was the box using ports 6881 and 4444...

Anyway, if anyone has diagnostic tips I'll gladly try them out. I think I might post this on the miniupnpd board as well, if they have one...

If you have any experience with miniupnpd, that'd be great.

Oh, btw, it ONLY HAPPENS, EVER, with the DHT port. On the laptop. EVER. That's the ONLY TIME I see this happen, which is why my first suspicion is ktorrent or some lib it depends on somehow...

Anyway, thanks to anyone who took the time to read this =D

Probably an issue in miniupnpd.

What does it actually return on the forward request ?

Please clarify what you mean, that was a bit vague.

I looked through the log that ktorrent generates, and I un-forwarded and then re-forwarded the ports, this is what it spat...

Wed Jul 15 03:03:04 2009: Undoing forward of port 6881 (TCP)
Wed Jul 15 03:03:04 2009: Undoing forward of port 4444 (UDP)
Wed Jul 15 03:03:04 2009: Timeout occurred
Wed Jul 15 03:03:04 2009: Authentication to *SCRUBBED* : failure
Wed Jul 15 03:03:04 2009: Initiating connection to *SCRUBBED*
Wed Jul 15 03:03:05 2009: Piece cache: memory in use 0 B, memory freed 64.0 KiB
Wed Jul 15 03:03:05 2009: Forwarding port 6881 (TCP)
Wed Jul 15 03:03:05 2009: Forwarding port 4444 (UDP)


I'm willing to bet the stuff in the middle is unrelated.

This is the resulting relevant iptables -nvL


Chain UPNP_FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.199 tcp dpt:6882
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.0.199 udp dpt:4445
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.56 tcp dpt:6881
104 14248 ACCEPT udp -- * * 0.0.0.0/0 192.168.0.106 udp dpt:50463
0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.56 tcp dpt:6881
0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.0.56 udp dpt:4444


And the resulting relevant iptables -t nat -nvL

Chain UPNP_PREROUTING (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6882 to:192.168.0.199:6882
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4445 to:192.168.0.199:4445
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:6881 to:192.168.0.56:6881
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:50463 to:192.168.0.106:50463
0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6881 to:192.168.0.56:6881
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4444 to:192.168.0.56:4444


So, yeah.

Lemme see if I can find a log for miniupnpd. I should probably also increase logging verbosity there if I can...

No, doesn't seem there's a way to make miniupnpd terribly verbose... :/

Also, if you can name a good packet sniffer/traffic analyzer, that'd help me out lots...

I think wireshark is a good one?

Wireshark is the tool we use yes.

A wireshark trace would be helpfull