Forums Bug Reports * [10053] Software caused connection abort

I agree and understand. However every message that said it was an answer sent to the same place. I just want people to know that is not really an answer for all people.

I have since solved my problem. I tried many different things to make it work, and when it finally did, I am not totally sure what made it work. All I know is I tried to install mIRC v5.91 over the 6.03 and run it, because from what I have read here the problem is v6+ related. However, under 5.91 I still had the same problem. I in turn deleted all *mirc*.exe files in my root mirc directory (usually c:\program files\mirc) and re-installed version 6.03 into the same directory. I also installed the 2 new critical updates for Windows XP Pro which were released earlier this week and rebooted. After resarting and connecting the problem was solved. I am sorry I couldnt at least be more specific. Because I had re-installed ver 6.03 OVER (not totally deleting the old files first) and it did not work. But re-installing with save old settings returned my mIRC client to its previous 'glory'.

If you have similar problems, let me know I will do my best to help. I looked into this error for days, and best I can tell it is related to a DNS issue under windows XP. However, the case it is just a bug, so sometimes it works and sometimes not.

Thanks for all the help I did recieve. I didnt mean to be rude, I just want people to be able to find the correct answer as easily as possiable. I tried #Help rooms, and #mIRC rooms with no success, in the end it was just fiddling around that was a solution.

Have a happy IRC day.

#Darvocet (DALnet)
-Darvocet

Glad you solved the problem - now next time someone posts the question, we can direct them to this thread!

LOL and let the game of "message board hot potato" Begin yet again LOL

To jlowe: Glad ya solved your problem ive already noted this thread for future reference

Just restarting mIRC usually fixes it for me, temporarely.. And it can't be DNS related, nameservers have nothing to do with this

wonder why this would only happen to you when you are "running something CPU intensive on the foreground" and how mIRC could be the cause. Be interesting to know if some of the many other ppl with this problem have the same condition to its happening, altho i know many dont.

If its a mIRC problem, then why do many users say that they only have this problem when the xp firewall is enabled or only on certain servers and others say they have never had it? And i know for sure that it happens to some ppl when they are quite actively chatting in mIRC. You said it has an occasional "bad day" and i cant help but wonder if those bad days are only when you are on certain servers.

As Poppy said, lots of xp users have reported this, but not all have it. When something doesnt happen to ALL users ALL the time, by its very inconsistancy its hard to track down. People reporting specifics that are consistant helps do that. So far about the only sort of constant is those who say if they disable the firewall and stay off certain servers, it stops and even that doesnt apply to everyone.

The reason you saw so many posts referring ppl to the IRC Errors thread is because, sadly, many ppl dont take the time you obviously did to do a search. If ppl took the time to do a search, we wouldnt have to tell 50 diff ppl the same thing.
The "stupid little 2 line analogy" you object to was written that way so the less technically oriented user could read a simple explanation with links to urls to read more details should they wish to. We found simply referring users to pages like here seemed to be of little help to many users.

"The answer to the problem IS NOT IN THE ANSWER YOU *PEOPLE WHO ARE SUPPOSED TO KNOW* ARE TELLING YOU. The answer is they dont know."
well, as the user on this thread quoted me as saying, I dont have a why. Pretty much looks like i said i dont know and could only report what others have found helped. And if you read the other posts on this issue, i know you saw that, and what others have tried/found, ie disabling firewall, changing servers, updating firmware, removing speed patches. I disagree with you that ppl reporting what they have found worked/didnt work are "pointless replies", altho i do agree that having to say the same thing over and over is annoying, as annoying im sure as it is to read over and over by those who do a search.

Your report that you can send on EFnet without any problem, but cant on DALnet is one i dont recall seeing before. Hopefully others will report if they find the same thing. But i do know this is happening to some ppl regardless of network. Understand that by its very inconsistancy, this problem isnt easy to track down. As you yourself said, it isnt consistant for you in various ways either.

Your comments about what you found regarding ips i also dont remember anyone reporting. Oddly enuf, the 172.16.0.1 is BLACKHOLE-1.IANA.ORG, "This block is reserved for special purposes. Please see RFC 1918 for additional information." Altho this article relates to errors in win2k, you may find it of interest: MS support article re the other ip you mentioned, 66.12.202.2 was the person you were sending to on one of the various verizon dsls? And i assume both of these happened on DALnet? Before or since the attacks? Could other ppl could send to that user all right? Can you pin down any changes that occurred about the same time this started to happen to you?

I realize i am more asking questions than giving you the specific answer you want, but the problem is there isnt one i can give. There is some speculation that the cause is the change of the default MTU from 1,492 to 1,500 in Win2K and after, but again we are back to the blackhole detection issue and as it relates to win2k. (Yes, i know you have XP, but i mention it only due to what i said above so please dont start yelling at me for talking about 2k when you have XP..hrm, i wonder if it was on the recieving persons end rather than yours)

*sigh* /me smacks her browser for not showing the latest posts until AFTER i typed the one i just did to you.

i'm glad you resolved the problem! Do you by any chance remember what those two critical updates were for?

To jlowe420:

That's it???? After all that ranting and raving about, and I quote:



So, smart one, according to you (and I am not disputing this statement because I have not yet tested it for myself), deleting mirc*.exe and reinstalling the binary back into the same directory solves the problem. That's very nice, and, if true, I applaud you in your troubleshooting efforts and will also put them into effect myself, since I still suffer from the 10053 problem.

However, o bright and brilliant star of wisdom, you have not told us what the problem really is. You bitched and moaned about the analogy, yet no pearls of wisdom seem to be forthcoming from your general direction. What is the problem?

I already know, so don't bother to "go there", that it is a Windows Sockets (WinSock) API error; I also know that that particular error message has to do with the returned error codes from somewhere off the localhost, like the infamous 10054 Connection reset by peer that the server generates, but client-side. Both 10053 and 10054 mean that the socket has simply gone bad or become invalid in some way, according to the code that I have taken the time to read and which you obviously haven't bothered to. Had you done so, you certainly wouldn't have been so insulting. Poppy told you exactly what was happening and that there is no one correct answer. The socket went bad for any one of many reasons. Your WinSock abandoned the socket as unusable and generated that error message. Perhaps you, in your infinite wisdom, can tell us WHY it's happening.

I must assume that, since you have solved the problem, you can solve it server-side as well. Please tell us how to do that too, please, because I'm quite tired of getting my connection reset by peer as well. After all, it's the same error.

And now, it's my turn:

HOW DARE you jump down anyone's throat on this message board like that because we are "PEOPLE ARE SUPPOSED TO KNOW"? Just who the hell died and elected YOU God? Every one of us here, up to and including Khaled, are volunteers. We all take time out of our lives to try our level best to help other people solve their problems because we might, JUST MIGHT, have run into that problem before and maybe even seen how to correct the problem, if such a solution already exists. And we MIGHT even remember how it was done.

Do you know, if I knew for a FACT how to fix the problem, after reading your original post, I'd rather burn in hell for eternity before I shared the secret setting to fix it for you? I and a great many other people contribute what knowledge we have to solving whatever problems arise, however we can. No one, up until your eloquent self clued us in, had yet figured out how to solve the problem. 99.99999% of the people didn't even understand the error message, which is why Merlin wrote that page with the analogies to explain in simpler terms what each of those error codes mean. Since I helped him with it, let me apologize for bothering to try to help those who haven't looked up the WinSock error codes, traced them back to the BSD implementation and then reduced what I found into an easier-to-follow description than straight C code. Next time, go read it yourself.

Let me clue YOU in: we do NOT know it all, we never CLAIMED to know it all, most of use WISH we knew it all and realize we CAN'T know it all. But we ALSO try to do our best. It's people like you that make people who try to help NOT want to help.

Don't be part of the problem: be part of the solution.

It is not server related, it happens on all of them. However, it seems to occur more often if I'm connected two more than 1 server at once (2 or 3).

I know it would be preferable to have reproducable circumstances, but all I can say is that I personally have not had it while mIRC was in the foreground.

Maybe I'll be able to check it out with a packet sniffer sometime, that could shed some light on what's happening (or what isn't)..

Ohh jesus. Ok, you want to know what it is. here ya go. The probelm is a DNS issue under Windows XP. When the DCC starts, there are several things that happen, a ping, a ctcp, and then the file starts. When the ctcp is sent, everything goes well, but the ping is then sent very quickly, before the CTCP has returned to the Senders computer. This ping, is subsequently sent to a wrong address, because either windows or mirc doesnt resolve the ping, just sends it to the IP that is cached in your system.

Why reinstalling mIRC solved the problem? I am not sure. Maybe the cache was cleared, maybe alot of things. Like I said, I had done this before and it didn't work. So, maybe also it was the Critical Updates. Who knows. I just say what I finally did to resolve the issue. I do know that the connection was a protocol timeout because the IP address the ping was sent to did not exist. So, maybe the designers of mIRC, or Windows can do somethign about this with this information, but I am not an expert. I do know that The information I wrote in my messages was far more aimed at helping the next person than alot of the messages here. Alot of them send you Here. and give you another description of your problem. Well, I was experiencing it, so I knew the problem. Here were my steps to solve, and eventually fix the problem for me. I said I am sorry I couldnt give more information, but I am not even sure exactially why it started working again. Maybe you should spend more time helping people that need help then reading old posts.

Let me clue YOU in: we do NOT know it all, we never CLAIMED to know it all, most of use WISH we knew it all and realize we CAN'T know it all.

Finally someone say's something meaningful.

Don't take things personally if you cant handle it.

Yes I do actually know about the Critical Updates. 1 Was an Update for Microsoft Internet Explorer, a security issue, and reading in detail listed nothing which SHOULD affect this problem, and another for Microsoft Outlook (and I believe Outlook Express), and again I didn't see any reason WHY these would affect anything, but who knows.

Well, true, I don't really think it is a problem resolving the IP from the Host name, I think it is more of a not trying to resolve at all and just using a wrong address.

Ohh grand master, You said yourself you would rather burn in hell than help me. And you are as wrong as the way you dress about it being the same problem. Just because you get ping timeouts, they are not related to the Software Caused Connecting Abort. " I know Disconnect are hard for you to understand" But that is all the 'connection reset by peer'. Here and I though you knew what you were talking about.

Just let us know if you need any help with your Computer Education classes. I'll start you off. asdf jkl;

Thanks Subspace.. all input is appreciated, narrowing down the "sometimes" "always" "never" circumstances can help.

hammer stated :

Do you know, if I knew for a FACT how to fix the problem, after reading your original post, I'd rather burn in hell for eternity before I shared the secret setting to fix it for you?

jlowe i think u need to read that line a bit better as he was tryin to ask u if u actually thought he was withholding info from u ..... not that he was sayin he wouldnt help u if he knew ..... that said jlowe u really should swallow some bit of pride and offer an appology to the guy ...... he is as anyone else is offering his free time to help ppl with problems .....

With that said id like to thank everyone for volunteering thier time to help out others like myself because its all of u that make mirc forums and mirc itself what it is .......

What in the world are you talking about DCC for? The question is dealing with [10053] Software caused connection abort (RST received when SYN or SYN+ACK expected). How did you manage to get from that error (which is has to do with your socket connection to the IRC server) to DDC Sending a file?


What kind of ping are you talking about? ICMP, IRC or CTCP? CTCP is a specialized format of PRIVMSG to a nick, which is an IRC command as it's used here.

CTCP PING goes to the nick you send it to //raw PRIVMSG nickname :
PING $ctime

IRC PING goes to the server, requesting a PONG: //raw PING $ctime
ICMP type 8 is an ICMP Echo request sent to an IP (TTL maxed)

I know you're not talking about DCC Sending a file, because what you have described has nothing whatsoever to do with the DCC Send protocol.

Here are some things that I have noticed, while troubleshoot this problem:

• I have never had 10053 while sending a file.
• I have had 10053 with XPs firewall enabled.
• I have had 10053 without XPx firewall enabled.
• I have had 10053 on every server I have ever been connected to, at one time or another.
• I have had 10053 after installing those last two Critical Updates.
• I have had 10053 after upgrading XP to XP(SP1)
• I have had 10053 while mIRC was the active application while I was idling and just watching.
• I have had 10053 while mIRC was the active application while I was typing my fingers off.
• I have had 10053 while typing up messages for this forum in its editor (mIRC not AppActive).

And all of those just this week!

If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state. If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.

Reset Processing

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user (which is where the 10053 ECONNABORTED or WSAECONNABORTED comes from) and goes to the CLOSED state.

-pulled directly from the end of TCP RFC (793) Section 3.4 Establishing a connection (my emphasis added)

Au contraire. "Ping timeout" is a message generated by the IRC server if your client does not respond within a reasonable amount of time to its periodic PING? with an appropriate PONG! It is an IRC protocol error and a means of closing down dead sockets (or those that the server assumes are dead). Connection reset by peer (10054) is not controlled by the IRC process at all, it comes directly from the socket engine which is not under the IRCd's control. Please get your protocols straight before trying to use them specifically in support of what you are talking about. 10054 and 10053 are the same error, viewed from different perspectives in a client-server architecture.

Grandmaster? Hardly. I, like most of the other helpers here, am just someone who likes to help others resolve their problems. My personal preference is in helping to provide support for scripting-type questions. I do try to answer other questions too, when I find I might have input that might help resolve an issue.

"And you are as wrong as the way you dress about it being the same problem." This statement is nonsensical, so I'll do you the favor of ignoring it completely.

I never said I never make mistakes; quite the opposite...I've had to apologize many times on these forums for blatant mistakes I've made. I'll have to do it again in the future, there's no doubt of that.

My point being they are both ping timeouts, but for different reasons, and from different servers/or programs. However, they are related in the ping pong relationship. However you will not recieve a ping timeout error for the problem I was describing, because it involves software. Ping Timeouts in irc are due to server or user pings, my pings & errors were almost exclusivly due to dcc chat or send only on dalnet. I never stated that this would solve the problem, I just stated what fixed it for me. Also, after working someone else through it on irc, it fixed it for them.

Your right, I have never seen the way you dress, I just assume by the way you talk. I wasn't upset at YOU, you just decided to take it personally. I never singled anyone out. Maybe a guilty conscious?

Anyways, if it helps you great, if not sorry. It worked for me, and I tried the winxp firewall on and off too, I tracked it (no matter what you say in response) to a ping to an invalid IP (my internal) non used ip. This would be a router problem essentually, but no correction was needed on that front.

Sorry if I offended you, like I have said in multiple posts, I was just trying to stress a point. I believe I might have even apologised. Nonetheless...

Happy IRCing