mIRC dislikes Windows TCP teardowns if... - 03/05/12 12:49 AM
Most IRC server daemons are designed to minimize resource overhead in every possible way, one of which is while deflecting rapid clone connection attacks (with the message "ERROR :Your host is trying to (re)connect too fast -- throttled"). In the case of such messages, the typical behavior of an IRCd is to spew the error string followed by immediately destroying the TCP connection without waiting to see if the client is simultaneously attempting to sending anything -- e.g. the USER/NICK/PASS commands.
But there seems to be something different between the way Windows and Linux destroy sockets. mIRC seems to like the way Linux does it in the aforementioned scenario, but it barfs when that scenario comes from a Windows-based IRCd.
Specifically, when dealing with a Linux host, you will always see the "ERROR: Your host is trying to (re)connect too fast -- throttled" message followed by a nice, clean "* Disconnected" from mIRC. But when dealing with the same thing from a Windows host, mIRC almost always fails to show the server's message, displaying instead the dreaded "* [10053] Software caused connection abort".
Here's an example featuring a Windows server host, and showing two separate telnet clients successfully seeing the message, but mIRC failing 7.5 out of 8 times:
http://img152.imageshack.us/img152/9743/toofast.png
(Please note: the telnet clients receive the string every time -- even though I'm not demonstrating more than 2 occurrences.)
The easiest way to reproduce this is to simply make mIRC (running under Windows) emulate such an IRCd message followed by its immediate TCP teardown:
Put that in mIRC on a spare Windows machine elsewhere on your LAN, and type /portopen in it. Then back on your main machine, in mIRC, do /server lan.ip.address.here 12345 repeatedly, and you should witness mIRC frequently fail to show you the "server's" message.
A real Windows IRCd will cause the problem too, of course. If anyone wants to reproduce the issue with one, the fastest way I know how is:
a) Get the source code for BewareIRCd (a simple, free, open source Undernet IRCu clone that's portable and stand-alone -- no install/uninstall process): http://ircd.bircd.org/bewareircd-src.zip
b) Unpack it into a temporary directory.
c) In bsock.pas, change "if ipc = nil then begin" to "if ipc <> nil then begin" (http://i.imgur.com/TQ09t.png -- this just forces the daemon to answer with the throttled ERROR message)
d) Install (ugh) free pascal (it's quick to do -- just use all-default settings in the installer wizard): http://www.freepascal.org/download.var
e) Compile BewareIRCd by typing "[path_to_freepascal_executable]\fpc.exe -Mdelphi bircd.dpr" (ignore the many compiler warnings)
f) Execute bircd.exe
g) /server 127.0.0.1 6667 (as many times as you want to observe/packetsniff/etc the issue)
h) Execute "bircd signal stop" to kill the daemon when you're done, then delete its temporary directory, and finally: Start Menu > All Programs > Free Pascal > Uninstall Free Pascal
FWIW, you can do the same steps above, but on a Linux machine (free pascal is available for linux too, and the same source zip will compile under linux). If you do, you'll notice that the Linux bircd executable's connection terminations will not trouble mIRC at all; the message displays properly, followed by no [10053].
P.S. I wonder if mIRC's trouble with Windows connection teardowns might explain some percentage of the [10053] errors that are commonly suffered inexplicably by mIRC users. The basic issue, as near as I can tell, seems to be that mIRC reports [10053] when a Windows TCP/IP stack (server side) is doing the TCP teardown sequence at the same time mIRC is sending data to it.
But there seems to be something different between the way Windows and Linux destroy sockets. mIRC seems to like the way Linux does it in the aforementioned scenario, but it barfs when that scenario comes from a Windows-based IRCd.
Specifically, when dealing with a Linux host, you will always see the "ERROR: Your host is trying to (re)connect too fast -- throttled" message followed by a nice, clean "* Disconnected" from mIRC. But when dealing with the same thing from a Windows host, mIRC almost always fails to show the server's message, displaying instead the dreaded "* [10053] Software caused connection abort".
Here's an example featuring a Windows server host, and showing two separate telnet clients successfully seeing the message, but mIRC failing 7.5 out of 8 times:
http://img152.imageshack.us/img152/9743/toofast.png
(Please note: the telnet clients receive the string every time -- even though I'm not demonstrating more than 2 occurrences.)
The easiest way to reproduce this is to simply make mIRC (running under Windows) emulate such an IRCd message followed by its immediate TCP teardown:
Code:
alias portopen /socklisten localhost 12345 alias portclose /sockclose localhost on *:SOCKLISTEN:localhost:{ /sockaccept localhostx /sockwrite -n localhostx ERROR :Your host is trying to (re)connect too fast -- throttled. } on *:SOCKWRITE:localhostx:/sockclose localhostx
Put that in mIRC on a spare Windows machine elsewhere on your LAN, and type /portopen in it. Then back on your main machine, in mIRC, do /server lan.ip.address.here 12345 repeatedly, and you should witness mIRC frequently fail to show you the "server's" message.
A real Windows IRCd will cause the problem too, of course. If anyone wants to reproduce the issue with one, the fastest way I know how is:
a) Get the source code for BewareIRCd (a simple, free, open source Undernet IRCu clone that's portable and stand-alone -- no install/uninstall process): http://ircd.bircd.org/bewareircd-src.zip
b) Unpack it into a temporary directory.
c) In bsock.pas, change "if ipc = nil then begin" to "if ipc <> nil then begin" (http://i.imgur.com/TQ09t.png -- this just forces the daemon to answer with the throttled ERROR message)
d) Install (ugh) free pascal (it's quick to do -- just use all-default settings in the installer wizard): http://www.freepascal.org/download.var
e) Compile BewareIRCd by typing "[path_to_freepascal_executable]\fpc.exe -Mdelphi bircd.dpr" (ignore the many compiler warnings)
f) Execute bircd.exe
g) /server 127.0.0.1 6667 (as many times as you want to observe/packetsniff/etc the issue)
h) Execute "bircd signal stop" to kill the daemon when you're done, then delete its temporary directory, and finally: Start Menu > All Programs > Free Pascal > Uninstall Free Pascal
FWIW, you can do the same steps above, but on a Linux machine (free pascal is available for linux too, and the same source zip will compile under linux). If you do, you'll notice that the Linux bircd executable's connection terminations will not trouble mIRC at all; the message displays properly, followed by no [10053].
P.S. I wonder if mIRC's trouble with Windows connection teardowns might explain some percentage of the [10053] errors that are commonly suffered inexplicably by mIRC users. The basic issue, as near as I can tell, seems to be that mIRC reports [10053] when a Windows TCP/IP stack (server side) is doing the TCP teardown sequence at the same time mIRC is sending data to it.