Ugh, I knew I would forget something. After unpacking the source code zip, you also need to download the files from http://www.lcore.org/svnroot/lcore/trunk/ into the unpacked source code's directory: Then bircd will compile. smile (Sorry.)


Anyway:

argv0, I actually had a long diagnostics discussion with bircd's author last year about this, and had planned to report the issue here. But other priorities came up and I eventually forgot about it. In any case, I can pass along a few notes from our e-mails.

For one thing, timing seems to be a factor in the issue. For example, while packet sniffing, I noticed that the troublesome disconnects were occurring as follows (note: this happened entirely within my LAN, from mIRC under Windows to bircd on another Windows machine):

Code:
  me: syn
serv: syn ack
  me: ack
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
  me: psh ack "CAP LS" + 0a
serv: fin ack
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to 192.168.1.3 (6667)
-
* [10053] Software caused connection abort
-
* Disconnected

On a hunch, I decided to see what would happen if I shortened mIRC's login sequence, by constructing an ON ^LOGON event to send the same data, but without the extra CAP LS packet. The result (same intra-LAN windows machines scenario):

Code:
  me: syn
serv: syn ack
  me: ack
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: fin ack
  me: ack
  me: fin ack
serv: ack

*************** Meanwhile, in mIRC:

* Connecting to 192.168.1.3 (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected

Seeing this at first, (and momentarily forgetting that the TCP protocol is a bit more complicated than this), I thought the problem was simply that mIRC kept sending even after it saw that the server was initiating the FIN ACK/ACK/FIN ACK/ACK teardown sequence -- forcing the server to resort to RST (which I believe is proper when a client doesn't cooperate with the FIN ACK/ACK/FIN ACK/ACK handshake).

But then I decided to restore mIRC's default login sequence (by removing the ON ^LOGIN override), and to then have a friend on the other side of the world run bircd under Windows (same OS+bircd versions as mine) so I could see if something different would happen with the vastly longer roundtrip lag involved (versus the tight timings of my LAN). The result that time:

Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "CAP LS" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: fin ack
  me: ack
serv: rst ack
serv: rst
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to 95.XXX.XXX.XXX (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* [10053] Software caused connection abort
-
* Disconnected

Which disproved my simple assumption. Because clearly here the same FIN ACK/ACK/FIN ACK/ACK handshake failure (fallback to RSTs) is occurring -- only now, time itself is re-arranged, with the server receiving mIRC's packets on a delay, and reacting to each one with successive RSTs.

I guess that's when I remembered that the handshake sequence falling back to RSTs is unavoidable in a lagged environment if one side is trying to close while the other is simultaneously trying to send.

Still, just for curiosity's sake, I then reinstated the same ON ^LOGIN override, and tried his Windows bircd server agian. Result:

Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
serv: fin ack
  me: ack
serv: rst ack
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to 95.XXX.XXX.XXX (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* [10053] Software caused connection abort
-
* Disconnected

Yup. Same as before, just one less RST, corresponding with the one-fewer packet from mIRC.

Which left me knowing only two things:

* with a Windows server, mIRC wasn't showing [10053] if the timing was tight enough to allow a successful FIN ACK/ACK/FIN ACK/ACK handshake
* with a Windows server, mIRC was discarding (or never seeing) the server message ("ERROR") if the timing was tight and if a teardown resorted to RST

And so with all that in mind, here's how things change when dealing with a Linux host:

After having the friend with Windows run bircd, I had another friend with Linux (and also on the other side of the world) run bircd for me. Here were the results, first with my shortened login sequence, then with mIRC's normal long login sequence:

Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
serv: fin ack
  me: ack
serv: rst
  me: fin ack
serv: rst
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to 84.XX.XX.XX (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected
Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "CAP LS" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
  me: psh ack "PASS myservpass" + 0a + "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: fin ack
  me: ack
serv: rst
  me: fin ack
serv: rst
serv: rst
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to 84.XX.XX.XX (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected

Immediately noticed: as with the overseas Windows machine, the extra CAP LS packet generated an extra RST. But also, I noticed a difference: while the Windows machine sent its first RST packet with both the "RST" and "ACK" flags enabled, the Linux machine sent its first RST packet with only the "RST" flag enabled. And to the Linux machine, mIRC responded with a "FIN ACK"; while to the Windows machine, mIRC did not.

I then decided to try the same thing (short sequence, long built-in sequence) against an Undernet server on the other side of the world (IRCu + some linux flavor) (note: the PASS parameter was omitted this time):

Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
serv: fin ack
  me: ack
serv: rst
  me: fin ack
serv: rst
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to manchester.uk.eu.undernet.org (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected
Code:
  me: syn
serv: syn ack
  me: ack
  me: psh ack "CAP LS" + 0a
serv: psh ack "ERROR: Your host is trying to (re)connect too fast -- throttled" + 0d0a
  me: psh ack "NICK mynick" + 0a + "USER myident 0 * :myname" + 0a
serv: fin ack
  me: ack
serv: rst
  me: fin ack
serv: rst
serv: rst
serv: rst

*************** Meanwhile, in mIRC:

* Connecting to manchester.uk.eu.undernet.org (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected

Result: same as with the friend's linux bircd -- no CAP LS packet resulted in one less RST from server; and server sends "RST" instead of "RST ACK"; and mIRC replies to initial "RST" with "FIN ACK" (as opposed to sending nothing in reply to Windows' initial "RST ACK").

Anyway, even with all this, it's still a simplified overview which at best can only provide clues. There is more to the TCP protocol than just which packet flags are enabled and the coincidental order of packet arrival. There are sequence and sequence-acknowledgement headers which play a roll, and so forth. And I don't have the patience or time repeat every one of the tests above while screen-capturing every one of their packets.

But ... I will do one comparison. If anybody fond of headaches wants to decipher all this crap, have a blast. laugh

_______________________________________________________________________________

Packet 01: http://i.imgur.com/QVf9z.png
Packet 02: http://i.imgur.com/Xzazw.png
Packet 03: http://i.imgur.com/mfQG8.png
Packet 04: http://i.imgur.com/DzB07.png
Packet 05: http://i.imgur.com/3YtEn.png
Packet 06: http://i.imgur.com/CKiWL.png
Packet 07: http://i.imgur.com/fIGzt.png
Packet 08: http://i.imgur.com/bRHtn.png
Packet 09: http://i.imgur.com/qx5Nf.png
Packet 10: http://i.imgur.com/OkvpZ.png
Packet 11: http://i.imgur.com/2jUl3.png
Packet 12: http://i.imgur.com/m6vrc.png
Packet 13: http://i.imgur.com/p5bo3.png

Code:
* Connecting to manchester.uk.eu.undernet.org (6667)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* Disconnected

Packet 01: http://i.imgur.com/bL80E.png
Packet 02: http://i.imgur.com/bJ5GO.png
Packet 03: http://i.imgur.com/JW1Bb.png
Packet 04: http://i.imgur.com/VHLcG.png
Packet 05: http://i.imgur.com/k1oJL.png
Packet 06: http://i.imgur.com/6LsrI.png
Packet 07: http://i.imgur.com/sJTFN.png
Packet 08: http://i.imgur.com/5SyeH.png
Packet 09: http://i.imgur.com/gtwMp.png
Packet 10: http://i.imgur.com/CPKJS.png
Packet 11: http://i.imgur.com/h8vYE.png

Code:
* Connecting to 95.XXX.XXX.XXX (30050)
-
ERROR Your host is trying to (re)connect too fast -- throttled
-
* [10053] Software caused connection abort
-
* Disconnected

Backup of all the packet screen captures (with proper file names): http://depositfiles.com/files/kl3hu1sl9 (packets.zip, 1.87 MB)