mIRC Home    About    Download    Register    News    Help

Print Thread
#229588 10/02/11 06:06 AM
Joined: Feb 2011
Posts: 1
A
Mostly harmless
OP Offline
Mostly harmless
A
Joined: Feb 2011
Posts: 1
I encountered an interesting problem with ipv6-mode for DNS resolution of domain names in /sockopen.

For example:
/sockopen -d 1.2.3.4 255.255.255.255 80

As we all know, would, open a socket bound to interface '1.2.3.4' targeting address '255.255.255.255'.

For the sake of another example, <some.com> would have IP address: 255.255.255.255.

In IPv4 mode this:
/sockopen -d 1.2.3.4 <some.com> 80

would target 255.255.255.255 because ipv4 DNS resolution would register an ipv4 IP address to connect to.


Now, in IPv6 mode the first example would still work (/sockopen -d 1.2.3.4 255.255.255.255 80) because it is by passing the IPv6 DNS resolution and using a specific IPv4 address as a target. However this would not work.

<some.com> = 255.255.255.255
/sockopen -d 1.2.3.4 <some.com> 80

Because IPv6 mode explicitly forces DNS resolution as 'ipv6' a socket to an ipv4 website can not be made even if the bound local interface is an IPv4 address. The $sockerr error returned in a SOCKOPEN event would be '[0] Unknown Error' and it would fail to proceed.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I'm not entirely sure this is a bug. Yes, DNS in IPv6 mode attempts to resolve hostnames to IPv6 addresses. This is expected.

It seems that you're asking for mIRC to detect that the bind ip is ipv4 and force ipv4 in this case. I'm not sure it's mIRC's responsibility to do this. If anything, /sockopen needs a -4/6 like /server and /dns has. But this would be an extra feature, not a bug.

Until then you should perform dns yourself on hostnames if you want to enforce ipv4, if you're in ipv6 mode.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Mar 2010
Posts: 57
W
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Originally Posted By: argv0
I'm not entirely sure this is a bug. Yes, DNS in IPv6 mode attempts to resolve hostnames to IPv6 addresses. This is expected.


I completely disagree with you. This is definitely not an expected behavior. /sockopen is not connection dependent and thus shouldn't have different behaviors depending on where it being called from. Currently, /sockopen will resolve based on the mode of the connection it is called from, this can (and in his case does) lead to unpredictable behaviors.


Originally Posted By: argv0
It seems that you're asking for mIRC to detect that the bind ip is ipv4 and force ipv4 in this case. I'm not sure it's mIRC's responsibility to do this.

If anything, /sockopen needs a -4/6 like /server and /dns has. But this would be an extra feature, not a bug.


Assuming you have one connection -6 and one -4, /scon -at1 sockopen... will generate an error for the first connection and the other will work perfectly fine. This is something that sockopen should be doing to make sure the dns lookup is the correct one; using /dns is just workaround to this bug, not a solution. The best way to resolve this issue, like you said, is to add a -4/-6 switch to /sockopen AND make it ipv4 dns lookup by default to keep it consistent from connection to connection.

Last edited by Wiz126; 10/02/11 05:51 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wiz126
/sockopen is not connection dependent and thus shouldn't have different behaviors depending on where it being called from. Currently, /sockopen will resolve based on the mode of the connection it is called from, this can (and in his case does) lead to unpredictable behaviors.


Where are you getting this behaviour from? I have IPv6 connections and calling /sockopen <hostname> or even /dns works fine to resolve ipv4 addresses on ipv4 hostnames.

"IPv6 mode" is a global mode, not server specific. You enable it by binding to an ipv6 adapter or enabling IPv6 priority. From then on, all /dns and /sockopen requests will use IPv6 first, regardless of active server connection. Try it yourself before "disagreeing". I use vyncke.org as a host that resolves in both ipv4 and ipv6.

Adding a -4/-6 switch works specifically because this is a global setting, and is specifically not a bug because you are enabling a global setting to prioritize a specific protocol over another. mIRC can't actually know what protocol to use until it attempts to dns the host, because it doesn't know if it's going to be getting an ipv6 or ipv4 address until the name resolves. You should be telling mIRC which one you want if you're going to be binding to a specific address (and specific protocol by extension).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
I think the point is that if you are specifying an IPv4 bind address, then "-4" should be implied, right? It doesn't make sense for mIRC to attempt to connect to an IPv6 address if you are binding to an IPv4 address, does it?

Joined: Mar 2010
Posts: 57
W
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Originally Posted By: argv0
Where are you getting this behaviour from? I have IPv6 connections and calling /sockopen <hostname> or even /dns works fine to resolve ipv4 addresses on ipv4 hostnames.


You are missing the fundamental problem here, as we can clearly see by your choice of example. vyncke.org has support for both ipv4 (91.121.200.122) and ipv6 (2001:41d0:1:d17a::1). The problem is not here.. the problem is *everywhere* else!

Originally Posted By: argv0
"IPv6 mode" is a global mode, not server specific. You enable it by binding to an ipv6 adapter or enabling IPv6 priority. From then on, all /dns and /sockopen requests will use IPv6 first, regardless of active server connection. Try it yourself before "disagreeing". I use vyncke.org as a host that resolves in both ipv4 and ipv6.

Adding a -4/-6 switch works specifically because this is a global setting, and is specifically not a bug because you are enabling a global setting to prioritize a specific protocol over another. mIRC can't actually know what protocol to use until it attempts to dns the host, because it doesn't know if it's going to be getting an ipv6 or ipv4 address until the name resolves. You should be telling mIRC which one you want if you're going to be binding to a specific address (and specific protocol by extension).


Your "ipv6 mode" has nothing to do with anything I was talking about. I was expending on the /sockopen problem. Perhaps I should dumb-down the problem I see, explanation:

Originally Posted By: argv0
From then on, all /dns and /sockopen requests will use IPv6 first, regardless of active server connection. Try it yourself before "disagreeing". I use vyncke.org as a host that resolves in both ipv4 and ipv6.

That's absolutely incorrect. Try testing it first yourself. (For the part I was talking about)

take a simple script like this:
Code:
alias goog {
  sockopen g google.com 80
}
on *:sockopen:g:{
  if ($sockerr) { echo -a Opps! $sock(g).wsmsg | return }
  echo -a All good, header would have been here!
  sockclose g
}



Code:
1) Open a blank mIRC
2) Connect to some ipv4 server:
     /server irc.someserver.net
3) Run the script:
     /goog
   As expected:
     "All good, header would have been here!"
4) Now, connect to some ipv6 server as well:
     /server -m6 irc.someserver.net
5) Run the script (from that connection):
     /goog
    Not what you expect (google does not have ipv6 on google.com dns failed)
      "Opps! [0] Unknown Error"
6) Go back to the first connection
7) run that script again
     /goog
   As expected:
     "All good, header would have been here!"
8) Trying /goog on the second connection (-6) will result in the same error again:
     "Opps! [0] Unknown Error"


This can be repeated as many times as you want, and on each connection it will based on that connection type (ipv4 or ipv6) it has nothing to do with any global mode you were talking about.

As you can clearly see, AFTER "I tried it myself before "disagreeing"", there is a problem here. Like I said in my original post, the behavior is inconsistent because it relies on the current connection that is executing the script, which is clearly a bug.

Last edited by Wiz126; 11/02/11 01:29 AM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wiz126
That's absolutely incorrect. Try testing it first yourself. (For the part I was talking about)


Funny, actually *ALL* of my IRC connections are IPv6. I connect to IPv4 addresses via /sockopen many times daily, every day, from these IPv6 connections. I *did* test this before responding with mIRC's actual behaviour.

Originally Posted By: Wiz126
This can be repeated as many times as you want, and on each connection it will based on that connection type (ipv4 or ipv6)


This is NOT the behaviour I see.

On an IPv6 server with no special adapter settings:

Code:
/dns google.com

(00:56:36) * Dns resolving google.com
-
(00:56:36) * Dns resolved google.com to 72.14.204.147
-


Same goes for IPv4 connections, naturally.

On an existing IPv4 connection, change your adapter settings to bind to an IPv6 only adapter (NOT priority mode) and retest:

Code:
(00:58:17) * Dns resolving google.com
-
(00:58:17) * Dns unable to resolve address google.com
-


Same thing happens even on an IPv6 connection. It will stop working when you unbind from the IPv6 only adapter.

It has nothing to do with the active connection; it has everything to do with the interface mIRC is bound to in your adapter settings.

/sockopen behaves the same way, it's just easier to show with /dns (/dns holds the underlying code that's of concern here anyway).


edit:

We are actually both right:

I initially didn't notice you used /server -6. Using -4 or -6 in /server ultimately binds your active connection to a specific adapter (the first available IPv4 or 6 adapter in the list). It is effectively a way to override the global setting with a connection local one. There is therefore both a global and local setting-- you were right about the local one, I was right about the global one. HOWEVER:

Using -6 for that connection means that IPv4 does not work in that connection. This is expected behaviour as well. /dns will not function on IPv4 addresses inside of a connection with /server -6. Again, this is expected behaviour. Because of this, it will be impossible to resolve IPv4 hosts. The issue isn't about bind ips, it's about resolving hosts. IPv4 is disabled in a connection bound to an IPv6 only adapter. /server -6 does this (local for a connection). This is by design. I'm not a huge fan of the design, but it was discussed thoroughly when the feature was introduced. Even forcing IPv4 with /dns -4 will fail to resolve a host in such a connection.

In that sense, mIRC's behaviour with /sockopen is correct (in that it is by design). In a connection that it bound to an IPv6 adapter (either globally or locally via /server -6), IPv4 will be completely and explicitly disabled. /sockopen will not resolve the host because it can't (again, by design) use IPv4 here. Therefore: you should probably not be using /server -6. It has a very specific usage.

Now, the "fix": Use PRIORITY MODE (Alt+O -> Connect -> Options -> Ports), not /server -4/-6. This mode will FALL BACK to IPv4 when 6 isn't available. /dns will continue to function. This is how *I* am able to /dns google and run your /goog script in my IPv6 connections.

Last edited by argv0; 11/02/11 10:16 AM.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
As I pointed out, I'm not convinced that mIRC should be making this decision. I'm not exactly totally sure of the details, but IIRC there were some issues raised a while ago about the possibility of adapters having both ipv4 and ipv6 support at the same time. In this case, binding to an address might bind to an adapter that COULD support an IPv6 address. Again, I'm not sure if this is possible, but this is one possible scenario. It just seems to me that, if you're enforcing a specific adapter/bind ip, you should enforce the protocol too.

In any event, the issue here is not whether mIRC should guess what protocol to use, it's the fact that mIRC can't resolve an ipv4 host when in IPv6-only mode.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Mar 2010
Posts: 57
W
Babel fish
Offline
Babel fish
W
Joined: Mar 2010
Posts: 57
Originally Posted By: argv0
Using -6 for that connection means that IPv4 does not work in that connection. This is expected behaviour as well. /dns will not function on IPv4 addresses inside of a connection with /server -6. Again, this is expected behaviour. Because of this, it will be impossible to resolve IPv4 hosts. The issue isn't about bind ips, it's about resolving hosts. IPv4 is disabled in a connection bound to an IPv6 only adapter. /server -6 does this (local for a connection). This is by design. I'm not a huge fan of the design, but it was discussed thoroughly when the feature was introduced. Even forcing IPv4 with /dns -4 will fail to resolve a host in such a connection.


My tests contradict what you said. /dns -4 does not fail, in fact it works just like it should (which is why /sockopen should have -4/6 switch as well)

Originally Posted By: argv0
Now, the "fix": Use PRIORITY MODE (Alt+O -> Connect -> Options -> Ports), not /server -4/-6. This mode will FALL BACK to IPv4 when 6 isn't available. /dns will continue to function. This is how *I* am able to /dns google and run your /goog script in my IPv6 connections.


The priority mode is backwards and irrelevant... "Enable IPv6 support and prioritize IPv6 over IPv4 connections"

I am unable to do /dns like you are saying. It simply fails after trying to lookup IPv6, only with the -4 switch it works. But /goog still does not work, because I can't foce -4 (of course if I use the IP address it works just fine, but this shouldn't be necessary)

Last edited by Wiz126; 11/02/11 05:18 PM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wiz126

I am unable to do /dns like you are saying. It simply fails after trying to lookup IPv6, only with the -4 switch it works.


You are unable to /dns in a IPv6 server connection NOT using -6, with priority mode on?

Originally Posted By: Wiz126
The priority mode is backwards and irrelevant


It may be backwards (though I don't see how), but it's not irrelevant. mIRC can be in one of three modes:


  • IPv4 only (with no fallback)
  • IPv6 only with no fallback
  • IPv6 with fallback to IPv4


/server -6 initiates a connection in the 2nd mode, that is, IPv6 with no fallback. You CAN have mIRC in IPv6/fallback mode, this is the "prioritize" feature discussed above. You are effectively asking for this mode, but it already exists. The problem is you are in the wrong mode.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
General reply. So I originally wrote this page from this discussion: http://en.wikichip.org/wiki/mirc/ipv6
Which seems about right.

Someone just reported this situation to me: if you use /server without the -6 switch to connect to an ipv6 ip address which mIRC therefore doesn't need to resolve, /sockopen will fail to resolve ipv4 addresses on that connection, so will /dns, however /dns -4 will work correctly (where the local mode using /server -6 makes /dns -4 fails). This seems to be kind of a mix of the two modes.

So mIRC is binding to an ipv6 adapter in this case, just like with the local mode, however mIRC is still able to resolve ipv4 addresses with dns -4, so mIRC is capable of resolving ipv4 addresses when binded to an ipv6 adapter, it's just that the design of /server -6 makes it so by default, it won't, but why should /dns -4 fails on a '/server -6' connection when it doesn't fail on a '/server <ipv6 address here>' connection? Perhaps I'm just not a fan of the design (either). It seems to me the -6 switch of /server only means you want to eventually connect to an ipv6 address (/server -46 some.domain.com is meant to be a thing right? where it would connect to either type of addresses), not that you want to get ipv4 to fail for that connection, I don't see the point in this.

Of course -4/6 switches for /sockopen would be useful and I'm going to request it right away, but I think the above shows there is some kind of a missing feature in the design. Using /sockopen -4 on a /server -6 connection would make it fail with the current design, and that seems to imply you do not, in any case, want to use /server -6 since it means your socket script requiring ipv4 would simply fail.
Perhaps I'm missing something but is there any reason one wouldn't want some ipv4 fallback by default, in all case, with the ability to force ipv6/ipv4 resolution with -6/-4?

I think that regardless of the -4/-6 switch, /dns and /sockopen should NOT be connection dependent like Wiz said.
Assuming you are connected to an ipv6 server (regardless of if you used -6 or if you specifiied an ipv6 ip address) on server A and to an ipv4 server on server B, and that some.domain.com can resolve to an ipv6 ip address as well as an ipv4 ip address, /scid -a /sockopen test some.domain.com 80 should work, it would connect to the ipv6 ip address on server A (because we didn't specify any switch on /sockopen, assuming they exist) and to the ipv4 ip address on server B.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the explanation. I have made a few changes for the next version that should help:

1) I have added /sockopen -46 switches which work in the same way as /server and /dns.

2) I have made /sockopen check the bind address and, if -46 are not specified, it will base its DNS resolution on whether the bind address is ipv4/ipv6. If no bind address is specified, it will be based on the server/global ipv4/ipv6 setting as before.

3) In previous versions, if a /server -46 switch was not specified but you specified an ipv4/ipv6 address, /server remained neutral and used the global ipv4/ipv6 setting. In the next version, if -46 is not specified, /server will base its ipv4/ipv6 context on the IP address type. This will affect the context of /dns, /sockopen, etc.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Hello,

Quote:
3) In previous versions, if a /server -46 switch was not specified but you specified an ipv4/ipv6 address, /server remained neutral and used the global ipv4/ipv6 setting. In the next version, if -46 is not specified, /server will base its ipv4/ipv6 context on the IP address type. This will affect the context of /dns, /sockopen, etc.
Some feedbacks:

/server wasn't so much neutral before, the global setting allows for ipv4 resolution, that is, /dns domain.com can be resolved to ipv4 (no -4 switch on /dns) but /server with an ipv6 address wasn't making this /dns works. It was with the -4 switch, which is still the case currently.

Quote:
/server will base its ipv4/ipv6 context on the IP address type
I don't know what this means but something is certain, this context is a different mode than the others two:

global mode:
(1)connected to ipv4 address or non connected: can access ipv4 addresses without -4 switch
(2)connected to ipv6 address: can access ipv4 address with -4 switch only

(3)local mode: cannot access ipv4 at all.


I don't understand why this context (2) results in people not being able to resolve ipv4 without -4, is this by design or a bug?

It looks like -4 is useful only in this (2) mode, where its meaning is to 'force ipv4 resolution when in mode (2)'.

I believe the purpose of the global mode is to always have a fallback on ipv4, this is not the case here, is it incorrect to think that?



Last edited by Wims; 26/11/18 11:06 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I don't know what this means

This means that if you use an IP address that is either IPv4 or IPv6, /dns will detect that and use that mode to resolve it. If you specify a host name, /dns cannot tell the difference, it will use the setting of the status window which is definied by the global setting, unless you specify -46 force it to use one or the other. At least, that's what I remember about the implementation. If it's not doing that, let me know.

Quote:
local mode: cannot access ipv4 at all.

I have not been able to reproduce this so far. Can you describe a step by step method that reproduces this for you, including your global IP setting, server address, command used, etc.?

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I don't have ipv6 connectivity myself, made some tests with westor who does.. I was just trying to document how ipv6 works in mIRC.
Looks like I gave argv0's speech more credits than Wiz's one, not sure why, on his last post argv0 claims that with /server -6 there's no fallback to ipv4, specifically that /dns -4 won't work. That statement seems to be incorrect and I take it /dns -4 does work with /server -6 (confirmed by westor).
My goal is also to document how scripts should handle these situations, many scripts use /sockopen without any of the -46 switch, I myself have such script and they failed recently on a server -6 connection.

So if I get this right:

1) on a /server -4 connection, ipv6 is disabled 'by default', but you can force it with /dns -6 and /sockopen -6

2) As a scripter, let's say I'm /sockopen'ing to somehost.com and suppose I'm aware that it can resolve to both type of ip addresses v4/v6, and that I want /sockopen to be able to connect to any of the type regardless of the ipv4/6 setting, I should be using /sockopen -64, correct?




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

Link Copied to Clipboard