Forums Bug Reports Weird bug

I find that 6.1 freezes up when i dont use it, or possibel when i dont use the puter for a while, and when i check back, all seem normal but the next text i write up, i get dissconnected,
also.. last time, i answer a question. and when i got connected again i asked if that Question was typed just a sec ago, and he said it was typed 30min ago, so something just freeze all up...

Lousy, i want 5.0 back.

Do you get the "software caused connection abort" error in your status window when you get disconnected? If so, read this thread. If not, type /!remote off and see if it still happens.

I've noticed it freeze. I run atleast 2 mircs at once, 6.03 which is a trivia bot and 6.1 which is me, both have ran for atleast a week without my touching the computer and niether have frozen up. Possibly it is mirc is drainging your resources through a script, So id suggest what was mentioned above. Turn off your remotes and see what happens.

This doesn't sound like an mIRC problem at all. IRC is a protocol that uses half-open sockets, which means it doesn't need to be sending and receiving packets constantly, the socket is held open in the event that data needs to be sent or data is received. If you close the socket and don't "tell" the server you're quitting, the server wouldn't know it because it wasn't told you quit, therefor you'd still appear on the IRC server. To battle this, IRC servers setup timer pings (which your client needs to respond to) to make sure you're still connected. If a ping isn't responded to within a set period of time, a ping timeout results (for the ghost nick). Obviously, if the client doesn't do a form of connectivity checking, it would never know if the socket has been disconnected from the server, since it's in a half-open state... it only becomes evident once the client tries to send data on the socket, which of course would fail, since it isn't really connected to anything. So, if for any reason you or your ISP had connectivity problems and your client couldn't respond to the a periodic ping, this could be a reason for the server closing up on their end, but there can be several other reasons, all based around the same concept.

I'm not sure, but I believe this started happening for me when I started denying dest-unreachable icmp packets. I'm guessing a firewall could be preventing TCP control messages from reaching the client, such as "sorry bud, but an error occured and we're severing your connection". If the client doesn't receive this, it just sits there oblivious that there's nothing being sent anymore.

What I find interesting is that mIRC only realizes it has been disconnected when you try sending text to a channel or query, but it doesn't realize this when it sends an ISON command every 30 seconds to update /notify. Perhaps Khaled could make mIRC check the connection if the server fails to respond to ISON and any other command for several seconds.

- Raccoon

It is not part of the IRC protocol to send an ICMP packet for any reason. You should be able to block all ICMP packets and have no connectivity issues to an IRC server as a result. If my memory serves me correctly, this is the process that would occurr if a server wants to let the client know that it's closing the socket: it'll send a FIN (the FIN flag turned on in the TCP header) packet to the client. The client can then respond with an ACK packet to acknowledge the FIN, and can also send its own FIN/ACK packet packet in which the server understands the client to be closing the socket and responds with an ACK packet to acknowledge the fact. In those circumstances, both sides have come to the understanding that both sides/sockets have closed. This is all part of TCP doing its job to ensure transmission reliability. If the client never receives the FIN packet, it doesn't know the server doesn't wants to close the connection, but this doesn't have anything to do with ICMP.

Besides the fact that TCP does it's part in closing the connection, the proper thing for a client to do when wanting to quit is to send a QUIT message on the socket before sending a FIN packet. Likewise, the server should send an ERROR (Closing Link) message before sending its FIN packet.

That was probably more than is necessary for the point of proving that mIRC is highly unlikely to be at fault, but the point is that packet loss can cause the client to never see that the server closed down the socket that the client's socket had connected to.

It would be trivial to create a script to check connectivity... there are probably many ping scripts that alread do that. You can have a timer send a PRIVMSG to yourself every so often containing $ticks, and if by the time the timer reitterates you haven't gotten your PM, a message could be displayed as a warning to connectivity problems. An added bonus would be to actually subtract the ticks in the PM from current $ticks, divide by 1000 (this result is a round-trip in seconds), then display it somewhere such as the title-bar or a lag-bar.

What you describe is an ideal TCP connection termination, which is not what Raccoon was talking about. ICMP packets are usually coming from routers somewhere along the route from the IRC server to you, to inform you that something there went horribly wrong (eg. a certain route suddenly disappeared). Since routers don't understand IRC or even TCP, it makes perfect sense to use ICMP in that case.

Btw, there is no such thing as the "half-open" sockets you described earlier. The closest I can think of is "non-blocking" sockets, but that still doesn't entirely match your description...

No, mIRC doesn't directly receive these ICMP messages, but winsock does. Winsock thusly relays the information to mIRC.

I never understood why this happens. What I do know is that

a] mIRC version has absolutely nothing to do with it (I have experienced it on every version I've used as far back as 5.41)
b] for me, this seems to particularly happen when I'm running other programs that gobble up my bandwidth (available sockets?)

Isn't this describing a stoned server? Where your connection is dropped by the server but it hasn't told your client...

RedAlert, you have absolutely no idea what you're talking about. "Since routers don't understand IRC or even TCP..." DUH. Anyone in the area of networking would be laughing at this nonsense (referring to the part of TCP, not IRC). This immediately invalidates anything you have to say in this subject matter. Coupled that with "Btw, there is no such thing as the "half-open" sockets you described earlier.", you're nothing short of very ignorant on this subject. If you showed that you had any knowledge of the subject you're talking about, I might dignify your post with an actual response. But for the original poster, the conclusion should still be the same, it's very unlikely for it to be mIRC's fault in any way.

----------

As a side note, I did not use the term "half-open" (in references to sockets) in strict regard to it's technical definition of a state in which a socket has not yet received an ACK for it's SYN (and the term does exist, contrary to what you say). I was using it in reference to mIRC not being constantly aware of the state of the connection to the IRC server, because it's not constantly being validated; I can be on IRC, completely unplug the power to my router for 30 seconds, have it retrain, then go on chatting on the IRC server as if nothing to my connection had happened (unless something requiring a validation, such as a ping, occurred within that time frame which could not be responded to); I've done this multiple times. This is contrary to a connection that is constantly validated such as when playing a game.

Check your facts before you flame, please. Routers operate at the network layer (3) of the OSI-model, TCP operates at the transport layer (4). Go read a networking-for-dummies book, or prove my ignorance by finding a router that generates TCP RST packets when it cannot find a route.


I completely agree with that. However, this still does not contradict the fact that Raccoon's ICMP theory could be right.


I know that the term "half-open" exists (I've written my own SYN-scanner, have you?), I just said that the term, as you described it, does not exist. It doesn't. Please, don't just pick random technical terms and expect people to accept it, especially not when the term you picked already represents something different.


Since you made such a mess of the explanation in your previous two posts, even contradicting yourself at this point (unawareness of normal connection termination VS. awareness of normal termination by means of FIN packets), I will leave it at saying that what you try to describe, are characteristics of TCP, not of IRC or mIRC, and since IRC uses TCP/IP, it also automatically and transparently deals with for example ICMP in exceptional situations. IRC doesn't use ICMP, but IP does.

Note that there is no such thing as "the state" of a connection, there are two sides which can both have different states - mIRC knows just as much as the underlying TCP stack, but it is of course simply impossible to know the state of the other side of the connection at every possible moment. All you can do is probe the validity of the connection once in a while - something IRC servers do, and mIRC doesn't.


Nearly all games use UDP, which is connectionless, so there is no connection to be validated, just a lack of arriving packets - but that your game terminates so quickly has more to do with timeout values than anything else. I'm sorry, you probably already know all this, but the way you phrase your 'superior knowledge' makes it look like you only know half of the facts on this subject. A big mouth will really not get you the other half for free.

"Since routers don't understand IRC or even TCP..."

Have you ever heard of NAT? How about filtering/firewalling and ACLs? Do you understand how they work? And you didn't know even cheap routers can provide both of these features? My simple DSL router has built in NAT capabilities (try that without recognizing the TCP protocol). I can also setup filters based on, get this, PORT numbers; try that without ability to read TCP headers. And this isn't even touching on the more complicated capabilities of expensive Cisco routers. I've been through the four Cisco CCNA semesters, and know very well that routers are not limited to the network layer (and also know plenty about the OSI layer as well). Perhaps you'd be better off with a networking for morons book.

Never did I say a router sending RST packets when a path is not found, you seem adept at pulling garbage out of your rear. I know the router sends ICMP destination unreachable (with various subsets) packets for that purpose, but that was never a part of my point.

Again, I wasn't referring to the technical term "half-open", I was using it as my own personal description for the purpose of making a point. Obviously it's not advantageous to strictly use technical terminology when posting on a board that has nothing to do with networking; what matters is getting a point across. Apparantly this is also something you do not understand.

"I've written my own SYN-scanner, have you?" You sure seemed to have turned this into a contest. Actually, I have, and even with mIRC in fact. When opening a socket, mIRC sends a SYN packet to the target. If a RST/ACK packet is received, mIRC will report WinSock error 1006 for the socket and it can be determined that the port is closed, but not filtered. Of course a SYN/ACK response results in no WinSock error and it can be determined that the port is open, and no response assumes a filtered port. mIRC can be quite useful.

Again, when describing the "sate" of a socket, I was doing so in a non-technical, generic way. The point was to get a general idea across, not technical aspects.

Obviously as far as games go, ones which utilize UDP durring game-play are not what I was referring to. I didn't assume that people would instantly think FPSs, etc., when I say the word "game". Obviously UDP doesn't apply to this conversation in any way. While FPSs might have the majority of the market share, they aren't the majority of games in existance. Examples I was referring to include chess, checkers, Reversi, commons games that actually require intelligence, something a frag-happy teen might not be interested in.

You may think I have the big mouth, yet I posted for the purpose of helping someone. You have taken this thread completely off topic, started an argument with me, and in the process have said rediculous things like routers being unable to process/recognize TCP headers. In fact, I don't see anywhere that you've attempted to actually help. All of your arguments have been completely off topic and irrelevant of the original post made; so do everyone a favor and don't post your garbage if you don't plan on helping.

In order to stay on-topic, I'll reply only to the relevant part...


I'm going to have to quote your earlier post then....


That was exactly what I replied to. So if you really think all this was off-topic, lets summarize... Raccoon made a suggestion that blocking ICMP could be the cause of TCP connections still being open where they should have been closed. You replied with the statement quoted above, supposedly proving Raccoon wrong, and throwing a possible solution out of the window for the OP. I indicated that your statement was flawed, since routers use ICMP to report about broken links. Despite your stream of words, nowhere have I seen an argument from you that contradicts this. So much for on-topic replies huh?

I'll be happy to discuss all your other points with you (especially regarding the general concept "router" as opposed to the feature list of your SOHO natbox), but not here.