About the use of passive DCC, to save some time I'll simply quote:
Passive DCC reverses how the connection is made. The sender usually receives the connection-- with passive DCC on, the receiver receives the connection. (...) [T]he point is that the receiver has to have the port open with passive on, the sender must have it otherwise. This means a passive DCC SEND will not work when the user sends to someone who does not have DCC configured.
Passive DCC creates the connection in "reverse" of a normal DCC connection. This means that the person receiving has to configure their router/firewall correctly to receive the file and the sender doesn't have to do anything. In a normal DCC connection, the sender has to configure the router/firewall correctly and the receiver doesn't have to do anything. See where the difference is?
Basically, in Passive DCC, if YOU as the sender cannot configure your ports correctly, then you are stuck using Passive DCC and hoping that anyone wanting to receive from you IS able to configure theirs. If they also can't configure their router/firewall, then they will not be able to receive files from you. That's where the problem is with using Passive DCC... everyone receiving files from you has to configure their router/firewall or they can't receive files from you.
In comparison, if you're using normal DCC, you're the only one who has to configure the router/firewall so it makes it easier for everyone involved and you're pretty much guaranteed to be able to send to everyone as long as they aren't blocking DCCs.
• Given that you can send without passive DCC
if the correct IP is set at "local", it's probably no
port forwarding issue. what are your actual settings at Options:Connect:Local ("On connect, always get:" and "Lookup method")?
• While connected to the network, does the command
fill the correct IP?
If it does, try setting "always get" to "host name" and "lookup method" to "server". If your localinfo hadn't been filled as desired after a reconnect, your problem may indeed be related to a script. You can test this by installing a separate, clean mIRC into a separate folder (choose "portable mode") and see whether you have the same problems with abovementioned settings at "local".
If it does not - I once made a
small workaround script to retrieve and set that IP. The script was to help users who retrieve a wrong IP at "local" due to a proxy/BNC - but it might help you as well.
