
I suppose there could be something wrong with that, but it would be strange considering that a number of indicators all say that it is being done correctly. I'm not certain that I am doing port forwarding corectly, but this is how I am doing it at home (I arbitrarily chose a 5 digit listening port - let's say it's 20000): myRouter : 20000 => myPC (static IP) : 20000. It doesn't seem like my network config is the issue, because both QT and nicotine report that the ports are being forwarded, QT appears to be working perfectly fine with in the same environment, and in the past I have successfully port forwarded with other applications. I suppose it is now a question of whether it is my network config or the client that is causing the issue. box definitely means that port forwarding is the issue then. The behaviour of nicotine after I check the I can receive. errors and all the other errors appear on the logs of my home machine when idling (and also when I check the I can receive direct connections box.
#SOULSEEKQT PORT BLOCKED PC#
Today I did the same thing though and I can download from my home pc running nicotine just fine, so I'm no longer sure what to make of what happened the other day. I tried downloading from a bunch of different people, and my home pc was the only account that gave me problems.
#SOULSEEKQT PORT BLOCKED WINDOWS#
I was on my Windows laptop using QT and trying to download from my home pc running nicotine. Sorry, I wasn't clear about the school thing. Hi for the response, and I appreciate the help. I know this is not a desirable state but have you tried it to see how Nicotine would react ? An alternative to test, if OpenWRT permits it, is to put your PC in a DMZ (should be a similar behaviour that the bridge mode). OpenWRT should be tunable enough to activate the bridge mode I think.

The I can receive direct connections checkbox basically mean what it says: it tells Nicotine and other clients that they can contact your PC directly either via a port forwarding (UPnP or static) or if you have a public IP on your PC (bridge mode). Has QT the same connectivity issues at school by any chance ? I'm not entirely familiar how the peers connection scheme works but that's what I'm understanding from this doc. For those who have redirection on the other side it should work. So if you have people in the same situation on the other side (no forwarding) you will see the giving up messages. Hi connection issue at your school doesn't really surprise me because, as you said, you can't do anything about port redirection there. The QT port checker doesn't show any of this volatility, which matches its lack of volatility upload-wise.
#SOULSEEKQT PORT BLOCKED HOW TO#
I don't know exactly how to interpret all of this, but it doesn't seem like my router would be responsible. I think the ports are being forwarded correctly A third party port checker website corroborates what the nicotine checker says about the ports nicotine is listening on.

This seems to be the big clue: When I am in the unreachable state, the nicotine port checker shows the ports as closed. About an equal amount of time is spent in each state.

It oscillates back and forth between seeming to be working fine (haven't been able to compare it with QT yet, so can't confirm), and being completely unreachable (I can't find my files via search, and lots of Can't connect. When the I can receive direct connections box is checked, however, things change quite a bit. Occasionally, I become unreachable via search, and I can't form connections with anyone at all - this is a mystery. When the I can receive direct connections box is unchecked, I get about half the uploads as I do in QT, which I assume is expected behaviour.
