schat module is not IPv6-aware #95

New Issue

2026-10-05T03:58:42+02:00

adam commented

2026-10-05 03:58:42 +02:00

The schat module is not IPv6-aware, it uses GetLongIP which is needed for IPv4 IP addresses, but in the case of an IPv6 address it returns 0 instead of the actual IPv6 IP address. IPv6 IP addresses must be returned in their normal form unlike IPv4 IP addresses.

The schat module is not IPv6-aware, it uses GetLongIP which is needed for IPv4 IP addresses, but in the case of an IPv6 address it returns 0 instead of the actual IPv6 IP address. IPv6 IP addresses must be returned in their normal form unlike IPv4 IP addresses.

adam commented

2026-10-05 03:58:43 +02:00

According to the spec, the IP's in any DCC command should be expressed as integers such as how it is currently. The DCC spec itself does not support IPv6.

The address, port, and size should be sent as ASCII representations of the decimal integer formed by converting the values to host byte order and treating them as an unsigned long, unsigned short, and unsigned long respectively.

http://www.irchelp.org/irchelp/rfc/ctcpspec.html

The only two commands which do not follow this rule are DCC REVERSE and DCC XMIT which are not widely supported (and are not covered in the DCC spec). I believe there are some clients which do not follow the spec and allow IPv6.

As extension to the protocol, KVIrc allows to be an IPv6 address in the standard hexadecimal notation, the connection will be made over the IPv6 protocol in this case (obviously if both clients support this feature).

http://www.kvirc.de/docu/doc_dcc_connection.html

According to the spec, the IP's in any DCC command should be expressed as integers such as how it is currently. The DCC spec itself does not support IPv6. > The address, port, and size should be sent as ASCII representations of the decimal integer formed by converting the values to host byte order and treating them as an unsigned long, unsigned short, and unsigned long respectively. http://www.irchelp.org/irchelp/rfc/ctcpspec.html The only two commands which do not follow this rule are `DCC REVERSE` and `DCC XMIT` which are not widely supported (and are not covered in the DCC spec). I believe there are some clients which do not follow the spec and allow IPv6. > As extension to the protocol, KVIrc allows <ipaddress> to be an IPv6 address in the standard hexadecimal notation, the connection will be made over the IPv6 protocol in this case (obviously if both clients support this feature). http://www.kvirc.de/docu/doc_dcc_connection.html

adam commented

2026-10-05 03:58:43 +02:00

What KVIrc does is what some other clients are already doing too, such as irssi, eggdrop and mIRC (I tested those and they follow this unofficial spec).

What KVIrc does is what some other clients are already doing too, such as irssi, eggdrop and mIRC (I tested those and they follow this unofficial spec).

adam commented

2026-10-05 03:58:44 +02:00

I think all DCC modules should be dropped as there isn't a standard and everyone speaks different dialect often having issues.

I think all DCC modules should be dropped as there isn't a standard and everyone speaks different dialect often having issues.

adam commented

2026-10-05 03:58:45 +02:00

There is a general consensus on how to do things, though. So I wouldn't just drop it like that.
This just needs IPv6 support implemented in the way described in my opening post and this module is then perfectly fine to use.

There is a general consensus on how to do things, though. So I wouldn't just drop it like that. This just needs IPv6 support implemented in the way described in my opening post and this module is then perfectly fine to use.

adam commented

2026-10-05 03:58:45 +02:00

Is it possible to implement this? Please, it has been almost 13 years and this basically only needs a few if/else statements (or something like that) to detect if an IPv4 or IPv6 IP address is being used and then this module is perfectly good to go for IPv6 support.

The if/else basically should be doing this: If an IPv4 IP address is provided then keep using the current "long" methods to convert the address. Else, if an IPv6 IP address is provided, use the literal IPv6 IP address with no conversions or anything.

Please consider implementing this.

Is it possible to implement this? Please, it has been almost 13 years and this basically only needs a few if/else statements (or something like that) to detect if an IPv4 or IPv6 IP address is being used and then this module is perfectly good to go for IPv6 support. The if/else basically should be doing this: If an IPv4 IP address is provided then keep using the current "long" methods to convert the address. Else, if an IPv6 IP address is provided, use the literal IPv6 IP address with no conversions or anything. Please consider implementing this.

adam commented

2026-10-05 03:58:46 +02:00

Patch welcome!

Patch welcome!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#95