mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
A user running one of my mIRC scripts has reported the following problem:

Code
/dns -h raw.githubusercontent.com
* Dns resolving raw.githubusercontent.com
* Dns unable to resolve address raw.githubusercontent.com


On my PC I get:
Code
/dns -h raw.githubusercontent.com
* Dns resolving raw.githubusercontent.com
* Dns resolved raw.githubusercontent.com to 151.101.64.133, 151.101.0.133, 151.101.192.133, 151.101.128.133


I asked user to run separate IPv4 and IPv6 lookups:
Code
/dns -4h raw.githubusercontent.com
[10:22] * Dns resolving raw.githubusercontent.com
[10:22] * Dns resolved raw.githubusercontent.com to 151.101.68.133
/dns -6h raw.githubusercontent.com
[10:22] * Dns resolving raw.githubusercontent.com
[10:22] * Dns unable to resolve address raw.githubusercontent.com


So apparently mIRC is not looking up DNS entries correctly on a PC with IPv6 internet connectivity.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report.

Quote
So apparently mIRC is not looking up DNS entries correctly on a PC with IPv6 internet connectivity.

mIRC depends entirely on the Windows Winsock API to resolve addresses.

A Windows application should not be delving into IPCONFIG to perform something as basic as DNS resolution.

If /dns -6 is not working for the user, this means that the Windows API is unable to resolve the address, probably due to a network configuration issue.

Thanks for your other suggestions. Please note that IPv6 support was added years ago and its implementation and behaviour were discussed thoroughly at the time. Its behaviour has been tweaked a few times (see versions.txt) since then but is otherwise working as intended.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Obviously if Winsock provides what is needed, then you should of course be using winsock - but I suspect that there may be issues in the way mIRC uses winsock for IPv4/IPv6 for non-IRC connections particularly when server connection is IPv6.

There certainly seem to be two or three networking issues in this particular case. These could be due to the users home router configuration having something small wrong with it - or it could be mIRC doing something wrong - or both.

ISSUE 1. User has mIRC automatically connecting to irc.irchighway.net when mIRC starts using Connect at Startup rather than a script. The user is NOT issuing a /server -6 command manually or via a script and mIRC is NOT set to use IPv4 by default.

I do NOT have IPv6 internet connectivity, just IPv4. When I do an nslookup on irc.irchighway.net I get:
Code
Non-authoritative answer:
Name:    irc.irchighway.net
Addresses:  2001:41d0:8:9403::1
          81.169.242.139


When I do /dns I get the following:
Code
/dns irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 81.169.242.139
/dns -4 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 81.169.242.139
/dns -6 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns unable to resolve address irc.irchighway.net
/dns -46 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 81.169.242.139


When the user with IPv6 connectivity does the same they get
Code
/dns irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 2001:41d0:8:9403::1
/dns -4 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 66.207.167.12
/dns -6 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 2001:41d0:8:9403::1
/dns -46 irc.irchighway.net
* Dns resolving irc.irchighway.net
* Dns resolved irc.irchighway.net to 2001:41d0:8:9403::1, 66.207.167.12


This is the case whether the user is connected to IRC or not.

There appears to be an issue here - I am expecting /dns to return the same results for /dns and /dns -46 but it doesn't. Since user has NOT got IPv6 set as priority, I would expect server connection to be IPv4, but it is IPv6 probably for the same reason that /dns returns only IPv6 addresses.

When you don't have IPv6 internet connectivity I would still personally expect to see IPv6 DNS entries returned like nslookup but I can live with that not happening.

2. A slightly different issue (which might have the same cause) is when you try to connect to a different server that is only IPv4.

When I do an nslookup on raw.githubusercontent.com I get:
Code
Non-authoritative answer:
Name:    github.map.fastly.net
Addresses:  151.101.128.133
          151.101.192.133
          151.101.0.133
          151.101.64.133
Aliases:  raw.githubusercontent.com


User with IPv6 gets:
Code
/dns raw.githubusercontent.com
* Dns resolving raw.githubusercontent.com
* Dns unable to resolve address raw.githubusercontent.com
/dns -4 raw.githubusercontent.com
* Dns resolving raw.githubusercontent.com
* Dns resolved raw.githubusercontent.com to 151.101.0.133, 151.101.128.133, 151.101.64.133, 151.101.192.133
/dns -6 raw.githubusercontent.com
* Dns resolving raw.githubusercontent.com
* Dns unable to resolve address raw.githubusercontent.com
/dns -46 irc.irchighway.net
* Dns resolving raw.githubusercontent.com
* Dns resolved raw.githubusercontent.com to 151.101.0.133, 151.101.128.133, 151.101.64.133, 151.101.192.133


Same issue of /dns only doing /dns -6 not /dns -46 but in this case it breaks the connectivity completely.

So there seem to be two potential network issues here:

a. /dns is not the same as /dns -46 and it should be.

b. Presumably sometimes /dns is currently equivalent to /dns -4 and sometimes equivalent to /dns -6 - but no idea what is causing it to be equivalent to /dns -6 when user has NOT got IPv6 prioritised.

Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
/server -6 OR connecting to an ipv6 ip address is the same, mirc won't support ipv4 by default there.
This is working as intended, even if that seems weird, it was the design chosen.

The only thing that could be a bug is, you said even when the user was not connected, in which case it should rely on the global setting imo.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
After a bit more research I believe that any suggestion I may have made about mIRC implementing a v6 to v4 gateway is entirely INAPPROPRIATE - such gateways should be external and mIRC should consider IPv6 and IPv4 networks to be entirely separate but parallel networks.

I would still be interested to understand how DCC works in the following scenarios:

a. IPv6 and IPv6 - non-passive and passive.

b. IPv6 and IPv4 - in both directions and non-passive / passive.

c. Situations where one or both ends have bit IPv6 and IPv4 connectivity - both non-passive and passive.

If this can be explained to me I will try to find the time to document it on WikiChip.

Last edited by Protopia; 18/12/19 09:01 PM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote
ISSUE 1. User has mIRC automatically connecting to irc.irchighway.net when mIRC starts using Connect at Startup rather than a script. The user is NOT issuing a /server -6 command manually or via a script and mIRC is NOT set to use IPv4 by default.

This is working as intended.

The Windows Winsock API does not resolve IPv6 addresses on IPv4-only systems. It looks like either Microsoft intentionally placed this limitation on the API or it is a Windows bug. The nslookup command actually has to work around this limitation to find the IPv6 address. There is a way to make the API resolve IPv6 addresses on IPv4-only systems but it requires an administrator DOS prompt and a netsh call.

(Just in case you decided to try out the above netsh call, you can see the current state using "netsh interface Teredo show state", enable IPv6 resolution using "netsh interface teredo set state type=enterpriseclient", and reset it to default using "netsh interface teredo set state type=default").

The reason that /dns defaults to IPv4 is that there is no point in returning IPv6 addresses for users who are on a non-IPv6 system. These addresses would be unusable, unless a user/script has a specific need for it, in which case they can choose to override the default by using /dns -6.

Quote
2. A slightly different issue (which might have the same cause) is when you try to connect to a different server that is only IPv4.

This is working as intended.

When you create an IPv4 server window, everything defaults to IPv4, including /dns.
When you create an IPv6 server window, everything defaults to IPv6, including /dns.
If you have IPv6 prioritized in the Ports dialog, everything defaults to IPv6 then IPv4, including /dns.

These behaviours were established a long time ago after much discussion and, as far as I can tell, they are working as intended.

Last edited by Khaled; 19/12/19 12:44 PM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote
I would still be interested to understand how DCC works in the following scenarios:

a. IPv6 and IPv6 - non-passive and passive.

b. IPv6 and IPv4 - in both directions and non-passive / passive.

c. Situations where one or both ends have bit IPv6 and IPv4 connectivity - both non-passive and passive.

You will need to research this as I am not aware of anyone having looked into it.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted by Khaled
Quote
ISSUE 1. User has mIRC automatically connecting to irc.irchighway.net when mIRC starts using Connect at Startup rather than a script. The user is NOT issuing a /server -6 command manually or via a script and mIRC is NOT set to use IPv4 by default.

This is working as intended.

This is - as far as I can see anyway - NOT working as intended. User has NOT got IPv6 prioritised yet their server connection to irc.irchighway.net is by IPv6 even though there is an IPv4 address. IMO this is a bug.

Originally Posted by Khaled

The Windows Winsock API does not resolve IPv6 addresses on IPv4-only systems. Microsoft intentionally placed this limitation on the API. The nslookup command actually has to work around this limitation to find the IPv6 address. There is a way to make the API resolve IPv6 addresses on IPv4-only systems but it requires a DOS prompt and a netsh call.

Accepted - you have to work within the limitations of Windows. I will look into the netsh call and document it on Wikichips, but you are right IMO not to ask users to use netsh.

Originally Posted by Khaled

The reason that /dns defaults to IPv4 is that there is no point in returning IPv6 addresses for users who are on a non-IPv6 system. These addresses would be unusable, unless a user/script has a specific need for it, in which case they can choose to override the default by using /dns -6.

This is (as far as I can see anyway) NOT working as intended. /dns does NOT default always to IPv4 - even when this user is not connected, /dns defaults to IPv6. But, IMO, /dns should ALWAYS be equivalent to -46 (though obviously if user is only one either IPv4 or IPv6 but not both or if the server you are looking for is only on IPv4 or IPv6 then you are only going to get one type of resolution. I do not think that changing /dns to be equivalent to -46 would create any backwards compatibility - as and on DNS scripts should already be coded to cope with IPv4/6 responses.

Originally Posted by Khaled
Quote
2. A slightly different issue (which might have the same cause) is when you try to connect to a different server that is only IPv4.

This is working as intended.

When you create an IPv4 server window, everything defaults to IPv4, including /dns.
When you create an IPv6 server window, everything defaults to IPv6, including /dns.
If you have IPv6 prioritized in the Ports dialog, everything defaults to IPv6 then IPv4, including /dns.

These behaviours were established a long time ago after much discussion and, as far as I can tell, they are working as intended.

Despite much discussion a long time ago (and if you can provide a reference to it I can go and see what it says), I think this behaviour is wrong! (I would happily concede that an IPv6 IRC connection should prioritise other (non-IRC) IPv6 connections over IPv4, but not that it should prevent IPv4 connections when this is the only option (or vice versa if you are IPv4 and trying to connect to an IPv6-only address).

P.S. I have now configured Teredo and have IPv6 connectivity, and so can test stuff.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Here are my test results:

1. When I start mIRC with IPv6 NOT as priority, the connection is made to irc.irchighway.net using IPv4.

2. If disconnect, set IPv6 as priority and connect again by clicking the connect button, it connects using IPv6.

For my connection, mIRC seems to be behaving as expected in this respect with internet access over both IPv4 and IPv6.

With IPv6 set as priority, I am also able to connect to an IRC server which is IPv4 only over IPv4. Again, mIRC is behaving as expected.

It gets a bit weird, however, if I switch backwards and forwards between IPv6 as priority and not. So when I set it as priority and connect I obviously connect by IPv6, but after I clear it but do not restart mIRC, when I reconnect it is still done by IPv6. This appears to be a bug - perhaps something to do with DNS caching i.e. if it has only got IPv6 in the cache it uses that rather than check for IPv4 before connecting.

I have to admit that I would rather that mIRC acts deterministicly - which means its DNS cache needs to keep track of which IP version it has queried and if e.g. it has IPv6 addresses cached, but IPv6 is not priority, then it needs to query for IPv4 DNS entries rather than assume that IPv6 addresses are the only ones.

This also makes me wonder whether the other user's issues are timing i.e. if PC has both IPv6 and IPv4 connectivity, does it issue both IPv4 and IPv6 DNS queries in parallel but connect to the first version that replies, or does it wait for both versions to reply before deciding which address and version to connect to.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote
It gets a bit weird, however, if I switch backwards and forwards between IPv6 as priority and not. So when I set it as priority and connect I obviously connect by IPv6, but after I clear it but do not restart mIRC, when I reconnect it is still done by IPv6.

In the same way that using /server to connect via SSL will permanently make a status window use SSL for future conections, using /server -4 or -6 to set a status window's default IP state will make it use those for future connections. If you use /server without -46, it will use the default global setting.

Note that mIRC does not perform any DNS caching. It calls the Windows API to resolve an address every time.

So far, I have not been able to reproduce any issues in my tests. The behaviour may not be what you would like but, as far as I can tell, it is behaving as intended.

Last edited by Khaled; 19/12/19 08:15 PM.
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Is this -4 / -6 stickiness persistent across restarts of mIRC? (I don't think it was in my tests, but I would like to have it confirmed.)

Also, it would be useful to have a list of where the stickiness comes from (the IRC connection), when it applies (when the IRC connection is closed and before/as a new connection is made? Only in the same connection window or across connection windows?) and what things it applies to if you don't explicitly code -4 or -6 (/sockopen, /dns, anything else?)...

In the end, I guess I can live with the way mIRC chooses to make IRC connections - and I guess that providing:

a. /dns -46 works the same regardless of whether your IRC connection is v4 or v6 - which it seems to; and
b. sockopen -46 works consistently to connect regardless of whether your IRC connection is v6 or v4 (I still need to test this); and
c. DCC works between IRC users connected with IPv6 and IPv4 (and I assume it does even if not documented anywhere because otherwise file sharing channels would not work a lot of the time)

then I guess we can live with this because you can always explicitly code -46 to make /dns and /sockopen work consistently regardless of whether you connect with v6 or v4, providing that the documentation for /server, /dns, /sockopen and /DCC clearly explains the limitations if you don't specify -46.

Of course, this does break backwards compatibility for scripts written before v6 support which will no longer work for users who connect with v6 without explicitly coding -46. And whilst I can see that you might want to prioritise v6 connections to other addresses if you are connected to IRC over v6 (or if you have set v6 to have priority in mIRC options), I really cannot see why you would want to prevent potential connections over the other version if both ends have the connectivity. But it is what it is, I guess.

Bottom line is that we probably need slightly better help file documentation highlighting what happens if you don't specifying -46 and much better documentation elsewhere about what happens for::

1. IRC connections
2. /sockopen
3. /dns
3. /dcc (for both not-passive and passive)

when:
a. your system has just v4, just v6 or both connectivity to the internet;
b. the system you are trying to connect to has just v4, just v6 or both connectivity to the internet;
c. when your IRC connection is v4 or v6;
d. when mIRC options has IPv6 not set or set as priority;
e. you specify -4, -6, -46 or none of these for the connection (inc. for the latter the stickiness described above).

This is a lot of dimensions and so a lot of combinations, far too complex to be in the mIRC help file - on Wikichip perhaps??

Last edited by Protopia; 19/12/19 09:13 PM.
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Everything is already on wikichip, I made some adjustement earlier based on your posts though, and I still need to do some, based on what khaled said, namely that the status window keeps the ipv6 setting, just like SSL.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel

Link Copied to Clipboard