AdiIRC

What is a "portlisten event" ?

This bug report is very sloppy, please provide as much details/information about the problem as possible, including steps to reproduce and expected behaviour vs actual behaviour.

Per Amundsen wrote:

What is a "portlisten event" ?

This bug report is very sloppy, please provide as much details/information about the problem as possible, including steps to reproduce and expected behaviour vs actual behaviour.

in mIRC Scripting Language, codes like for example ON 1:PART, ON 1:JOIN, ON 1:SOCKREAD and others are considered events. Even the mIRC's official help file considers them this way.

Actually, the ON *:PORTLISTEN on AdiIRC only recognizes Local connection.

I have never heard about a MSL scripting event called on PORTLISTEN, do you have any information about what it does?

Per Amundsen wrote:

I have never heard about a MSL scripting event called on PORTLISTEN, do you have any information about what it does?

My mistake, sorry.

It's: ON *:SOCKLISTEN

Actually if you open a port on AdiIRC using sockets, it only recognizes local connections.

Okay now you are making more sense, but still a little light on details.

What does your /sockopen command look like with parameters?

If I understand correctly you are trying to setup a listening port using upnp, upnp may or may not work for you depending on your windows/firewall/router settings, also I have noticed the built-in windows upnp library doesn't work for some people, there is no clear reason why.

You can try keeping Rawlog open while starting the listening socket, look for upnp errors in the Rawlog -> Debug tab.

Per Amundsen wrote:

Okay now you are making more sense, but still a little light on details.

What does your /sockopen command look like with parameters?

If I understand correctly you are trying to setup a listening port using upnp, upnp may or may not work for you depending on your windows/firewall/router settings, also I have noticed the built-in windows upnp library doesn't work for some people, there is no clear reason why.

You can try keeping Rawlog open while starting the listening socket, look for upnp errors in the Rawlog -> Debug tab.

I am aware about the needing of Port-Forwarding and Firewall configuration. I use a router and i already did setup it and made all the proper tests.

If you use a /socklisten (not /sockopen) to open a port on AdiIRC, AdiIRC will only recognizes local connection for the ON SOCKLISTEN event. If a friend around the internet (for example) tries to connect to your IP, he/she will not be able to connect to you.

I've opened servers on my notebook before using other softwares and i never had problems. For both: UDP and TCP ports.

You might try write a basic code by yourself and test it (only if you want, of course)

Additional information: Using AdiIRC, actually i am testing the socklisten feature using TCP port.

Okay so you use the /socklisten command, what are the parameters you are passing to the /socklisten command?

By default a socket will be created that listen to port [port], there is no difference between public or local connections, it all depends whether the port is open in your firewall and router.

Upnp can be used to automatically open the port in your router/firewall when using the -p parameter, otherwise the port must be manually opened in your firewall/router.

Per Amundsen wrote:

Okay so you use the /socklisten command, what are the parameters you are passing to the /socklisten command?

By default a socket will be created that listen to port [port], there is no difference between public or local connections, it all depends whether the port is open in your firewall and router.

Upnp can be used to automatically open the port in your router/firewall when using the -p parameter, otherwise the port must be manually opened in your firewall/router.

I tested in 2 ways: using -p and without -p

It doesn't recognize public connections for both ways, only local.

If -p is used, the debug returns: -> Add Upnp:Object reference not set to an instance of an object.

As I mentioned earlier "I have noticed the built-in windows upnp library doesn't work for some people, there is no clear reason why", they get this same error "Upnp:Object reference not set to an instance of an object", I don't know why it happens or how to fix it.

YOu would have to manually make sure the specified port is open in your firewall/router in this case.

One idea you could try, specify the local ip address, e.g /socklisten -dp sockname 127.0.0.1 port.

Per Amundsen wrote:

One idea you could try, specify the local ip address, e.g /socklisten -dp sockname 127.0.0.1 port.

This method, it returns: [15:56:04] * /socklisten: invalid parameters

Sorry it should be /socklisten -dp 127.0.0.1 sockname port.

I did some searching, and the error "Upnp:Object reference not set to an instance of an object" seems to indicate upnp is either disabled in the router or not available, can you confirm that?

Per Amundsen wrote:

Sorry it should be /socklisten -dp 127.0.0.1 sockname port.

I did some searching, and the error "Upnp:Object reference not set to an instance of an object" seems to indicate upnp is either disabled in the router or not available, can you confirm that?

The bug is invalid. Sorry.

It's accepting public connections now.

I've found on my firewall an (very, very) unexpected thing. By the way, fix the subject of the thread, please. Thanks.

But

What i've found on my firewall isn't related with this

Do you remember when you've sent me a build for testing something? My firewall shows 2 AdiIRC installed on my notebook. One of them didn't have the proper configuration.

Actually, i can only affirm that using /socklisten without any parameters works fine.

I still need to make tests using parameters.

I know it's not related to this issue, but from my searches the error is consistent with upnp not detected/enabled in either firewall or router, this means I can show that in the rawlog debug for any future upnp issues instead of "Object reference not set to an instance of an object".

Since you are able to receive connections without using the -p parameter for upnp, your ports are already open, you would have to close them or firewall them and enable upnp to test it, don't think that is necessary though, upnp seems to work fine.