Forums Connection Issues [10101] Host disconnected

hi all

I've been recently getting a large number of disconnects from ETG and am trying to narrow down the cause. I've employed packet sniffers both directly on the machine running mIRC and at the edge-most location on my local network (outside of my router/firewall, between it & my PPPoE DSL modem).

My understanding of the IRC protocols is somewhat limited, but I'm learning. I think I have a decent understanding of TCP/IP, ethernet, etc...

With mIRC in the recent weeks I've had 20+ disconnects/day, although I've also had some connection problems with other applications & games... just not as frequent. Via the sniffer, these disconnects show up as a CLIENT initiated TCP FIN/ACK packet. These finish packets are exactly 2 minutes after mIRC sent a PING: TIMEOUTCHECK, but the server failed to return a PONG message in time. However, the server DID send a TCP ACK to the original ping, so I know at that level, it got it...

So I'm wondering if that PING: TIMEOUTCHECK packet is from the new feature in 6.17 called "check for timed out connections". So in my case, the ETG servers aren't responding to this request or their response is being eaten by my ISP. Also, if this new ping/pong (in addition to the usual SERVER GENERATED ping/pong) is just giving mIRC another reason to close the connection.. it might just hurt more than it helps! I don't know if I'd enabled this option at some point in the past or if it's defaulted to ON.

I also get the more typical [10053] Software caused connection abort errors also, so maybe my DSL provider just sucks...

You're right on the money, both the "PING :TIMEOUTCHECK" and the subsequent mIRC-initiated disconnects (with the 10101 error which doesn't really come from winsock) are the result of the "Check for timed out connections" option. It's new in 6.17 and on by default, but if it gives you trouble it's safe to turn it off - it's only there to detect dead connections, and turning it off will usually cause the same connection problems to manifest themselves in another way (typically with a 10053 sometime later).

In your case it's very strange that the server doesn't respond to the PING on the application layer but does ACK the tcp packet, though. It would be interesting (and possibly helpful) to find out what exactly is happening there, because as far as I know the ircd software that ETG uses, does send back a PONG to any PING from the client just as mIRC expects. You may want to check that first though - if you use "/raw PING :test" as command, does the server indeed reply ("PONG from ...")? If so, what happens if you send another command (which generates a response; say, a WHOIS) within the 2mins between mIRC's PING and the disconnect? Does the "PONG" arrive within the same TCP packet as the WHOIS response in that case, or does the connection die anyway? Etcetera.

I suspect that it will turn out to be your DSL connection anyway, but I'd say looking into it is worth a shot, especially as you have the necessary expertise and tools..