Before I start off, here's the souce of my bot:

DMBot.zip

Please check it out, if you're willing. Once you set up the login/cdkey vars, and execute the program, click connect, you'll see it connects, logins and goes to a channel fine. Even can chat/whisper with people. Looks good so far, right? Now click Disconnect.

It disconnects. So far, good, right?

Click connect. BAM, runtime error #6, overflow, apparently at winsock buffer. Do not, I repeat, DO NOT, attempt to reconnect. This results in ipban.

Strange, right? Well, exit VB. Then go back into VB, and run the program again. Strangely, it connects, logins, and enters channel without ANY problems.

Apparently as long as VB is restarted after a disconnection, the bot works fine. This is fine for a temporary solution, but it's starting to get aggravating...

I've been poring over my code, trying to find possible errors, but I keep coming up with nothing- it all seems good. So it is with this note, that I now plead with you guys to take a gander at it. Thanks to all of you guys teaching me about botmaking, I've been able to code enough to get the bot this far, so I'd like to take this chance to thank you guys for being very informative, helpful, and as well as especially patient, what with it being my first time coding a binary bot!

Thank you all very much for your help not only in the past, but also in advance!

Before you ask us to fix your code, which I might be able to do from work without VB6 installed, I want to ask you -- have you tried to debug it?

Step through your code from where the connection sequence begins.  After which packets (if any) does the RTE occur?  Does it occur during a receive or send operation?  I mean, really, there are a couple dozen things you can check that it doesn't sound like you're checking.

https://davnit.net/bnet/vL/phpbbs/index.php?topic=12790.0

As you can see from that thread, I definitely have been trying to debug it.

And I *DID* step through the code. The only time the RTE occurs is when I use the SendPacket sub, and the line:

sck.SendData Chr(&HFF)

is highlighted. The RTE error only occurs when data is sent (or at least attempted to be sent). It seems to mainly only happen with the 0x0A, 0x51, and rarely, 0x29 when they are sent. Most of the time, the error occurs with 0x51, less often with 0x0A, and rarely 0x29. All of the other packets appear to be sent without a problem.

I modified my code to NOT disconnect upon RTE-- and watched bot without interacting with it. BNET sent my bot a ping, and my bot automatically replied to the ping with 0x25 without a problem. BNET sent a 0X00, and the bot automatically responded with a null packet. In both automatic response cases, the packet went through without an error. I then set up code for the bot to send specific packets upon request, and typed in the bot after 0x0A errored out:

/send 0x0a

The packet still errored out with an overflow. So to answer your implication, yes, I've been trying like heck to debug it, and I've been doing nothing but that for the past few days.

Thanks for the suggestion to step through the code step by step though-- while an excellent idea, I've already done that. Any more suggestions?

Never errors for me... Your SendPacket sub is fucked up that's the problem.

[code]
Public Function SendPacket(sck As Winsock, PacketID As Long, Optional PacketFormat As pPacketFormat = pBNET) As Boolean
    On Error GoTo DumpHex
    'Returns TRUE if packet was successfully sent. FALSE if not.
    'If BNETSendComplete = False Then
    '    AddC vbRed, "Winsocket not available to send yet, please wait a moment..."
    '    Do
    '        DoEvents
    '    Loop Until BNETSendComplete = True
    '    AddC vbGreen, "Alright, it's open. Sending packet..."
    'End If
    'YOU DON'T NEED THE ABOVE CRAP!!!
    If sck.State = sckConnected Then
        'sck.SendData Chr(&HFF) & Chr(PacketID) & MakeMemory(Len(Buffer) + 4, pWORD) & Buffer
        sck.SendData Chr(&HFF) & Chr(PacketID) & MakeWORD(Len(Buffer) + 4) & Buffer
        SendPacket = True
    End If
    Clear
    On Error GoTo 0
'    BNETSendComplete = False <~ YOU DO NOT NEED THIS
    Exit Function
DumpHex:
    DMBot.BNET.Close
    AddC vbRed, " -- Error " & Err.Number & " (" & Err.Description & ") in procedure SendPacket in PacketBuffer class."
    Call DMBot.BNET_Close
    DumpPacket (Chr$(&HFF) & Chr$(PacketID) & MakeMemory(Len(Buffer) + 4, pWORD) & Buffer)
    Clear
End Function
[/code]

You don't need the SendComplete crap... was that the problem? I did get winsocket error due to it, but no overflow error... just remove it and try again.

Did you click disconnect, then click connect to attempt to re-connect to bnet, with the program STILL running? The oncomplete thing was added AFTER the RTE errors were occurring- that was an attempt of mine to try to fix the problem.

http://hdx.no-ip.org/files/DMBot.zip <~~~modified source
took out the "BNETSendCompleet" If you send more while it's still trying to send info, it'll sjtu sit in queue.
Also, Updatres your unhandeled packet code to desplay the correct ID in hex, and the packet name.
Updated your Flag handeler for joining channels to reflect multiple flags.
also made it desplay hex upon unknow.

updated your dumppacket sub to  be faster. (HexToStr(StrTohex())) was jsut repettitve!
Added a function to get the packet name from the ID.
Also, After 35 mins of using ur bot.. I didnt get any overflow errors..

If you have questions ask.
~-~(HDX)~-~

Unhandled packet code? Where? And the packet name?

[quote author=HdxBmx27 link=topic=12811.msg128170#msg128170 date=1126744775]
http://hdx.no-ip.org/files/DMBot.zip <~~~modified source
took out the "BNETSendCompleet" If you send more while it's still trying to send info, it'll sjtu sit in queue.
Also, Updatres your unhandeled packet code to desplay the correct ID in hex, and the packet name.
Updated your Flag handeler for joining channels to reflect multiple flags.
also made it desplay hex upon unknow.

updated your dumppacket sub to  be faster. (HexToStr(StrTohex())) was jsut repettitve!
Added a function to get the packet name from the ID.
Also, After 35 mins of using ur bot.. I didnt get any overflow errors..

If you have questions ask.
~-~(HDX)~-~
[/quote]

[quote author=Kyro link=topic=12811.msg128169#msg128169 date=1126744589]
Did you click disconnect, then click connect to attempt to re-connect to bnet, with the program STILL running?
[/quote]

yes -.- multiple times

[quote author=Kyro link=topic=12811.msg128172#msg128172 date=1126745011]
Unhandled packet code? Where? And the packet name?
[/quote]
you dont handle 0x59 (SID_SETEMAIL)
[code]AddC vbRed, "Unrecognized Packet ID: 0x" & IIf(Len(Hex(PacketID)) = 1, "0" & Hex(PacketID), Hex(PacketID)) & " (" & GetPacketName(PacketID) & ")"[/code]
Outputs [quote]
Unrecognized Packet ID: 0x59 (SID_SETEMAIL)
[/quote] insted of [quote]
Unrecognized Packet ID: 89[/quote]
~-~(HDX)~-~

[quote author=HdxBmx27 link=topic=12811.msg128177#msg128177 date=1126745619]
[quote author=Kyro link=topic=12811.msg128172#msg128172 date=1126745011]
Unhandled packet code? Where? And the packet name?
[/quote]
you dont handle 0x59 (SID_SETEMAIL)
[code]AddC vbRed, "Unrecognized Packet ID: 0x" & IIf(Len(Hex(PacketID)) = 1, "0" & Hex(PacketID), Hex(PacketID)) & " (" & GetPacketName(PacketID) & ")"[/code]
Outputs [quote]
Unrecognized Packet ID: 0x59 (SID_SETEMAIL)
[/quote] insted of [quote]
Unrecognized Packet ID: 89[/quote]
~-~(HDX)~-~

[/quote]

You know, 0x59 and 89 are the same values, right?

DUA
His code was
AddC vbRed, "Unrecognized Packet ID: " & PacketID
And considering EVERY usually refers to BNCS packets by there IDs in Hex. Having a error that desplays them in hex, along with the designated name makes it A LOT easier to debug.
Insted of having to manually convert it to hex by hand, or read the packet log.
~-~(HDX)~-~

[quote author=HdxBmx27 link=topic=12811.msg128180#msg128180 date=1126745908]
DUA
His code was
AddC vbRed, "Unrecognized Packet ID: " & PacketID
And considering EVERY usually refers to BNCS packets by there IDs in Hex. Having a error that desplays them in hex, along with the designated name makes it A LOT easier to debug.
Insted of having to manually convert it to hex by hand, or read the packet log.
~-~(HDX)~-~
[/quote]
K, just wanted to make sure you knew it wasn't that much more than a cosmetic change.

Overflow still results if I click disconnect, then click connect.

[quote]DementedBot activated at [9/14/2005 6:03:05 PM] .
Loading configuration...
Username: Kyro[DM]
Password: ********
CDKey: **************
Client: Starcraft: Brood War
Client VerByte: CD
BNET Server: asia.battle.net
BNET Port: 6112
BNET Default Channel: op Kyro[DM]
Config loaded.
Connecting to port 6112 at the asia.battle.net server...
Connected!
Initating packetage...
Notifying server of emulation...
0x01 protocol packet sent.
Server notification done.
Assembling 0x50 Protocol packet...
0x50 SID_AUTH_INFO packet sent.
BNET: Gimme your cdkey.
Assembling 0x51 SID_AUTH_CHECK Packet...
0x51 SID_AUTH_CHECK packet sent.
DMBot: Blah blah. There ya go. Happy?
BNET: Well...
BNET: Fine, I'll accept that...
BNET: But dude, who the heck are you?
Assembling 0x14 SID_UDPPINGRESPONSE Packet...
0x14 SID_UDPPINGRESPONSE packet sent.
Assembling 0x29 SID_LOGONRESPONSE Packet...
0x29 SID_LOGONRESPONSE packet sent.
DMBot: LOL! Well dude, I'm Kyro[DM]...
BNET: Uhhh...
BNET: Oh yea, I know you! Cool, welcome to BNET!
Assembling 0x0A SID_ENTERCHAT Packet...
0x14 SID_ENTERCHAT packet sent.
Assembling 0x0C SID_JOINCHANNEL Packet...
0x0C SID_JOINCHANNEL packet sent.
DMBot: By the way, I know my ABC's!!! :D
BNET: Cool! So do I! Anyway, welcome to BNET! :D
Now in Normal Channel op Kyro[DM].
EID_CHANNEL event tripped.
EID_SHOWUSER flag tripped.
Unrecognized Event ID: 0x09
Username: Kyro[DM]
Message:
Disconnected.
Connecting to port 6112 at the asia.battle.net server...
Connected!
Initating packetage...
Notifying server of emulation...
0x01 protocol packet sent.
Server notification done.
Assembling 0x50 Protocol packet...
0x50 SID_AUTH_INFO packet sent.
BNET: Gimme your cdkey.
Assembling 0x51 SID_AUTH_CHECK Packet...
-- Error 6 () in procedure SendPacket in PacketBuffer class.
Local Disconnect Confirmation.
Dumping packet...
StrToHex Dump:
FF 51 68 00 32 51 9B 00 09 03 01 01 E4 53 DA 0F 01 00 00 00 00 00 00 00 0D 00 00 00 01 00 00 00 0A 70 97 00 00 00 00 00 25 DB E8 F0 92 6F A0 F1 2D FA 90 54 4A AF 88 EB 82 CC FD AC 28 6E 75 6C 6C 29 20 30 37 2F 32 34 2F 30 35 20 32 33 3A 35 30 3A 33 31 20 31 30 39 33 36 33 32 00 44 6F 6E 20 43 75 6C 6C 65 6E 00
ASCII Dump:
ÿQh.2Q›. 

äSÚ
...........
....p—.....%Ûèð’o ñ-ú?TJ¯ˆë‚Ìý¬(null) 07/24/05 23:50:31 1093632.Don Cullen.
End of packet dump.[/quote]

But thanks for taking a look at it guys, I seriously appreciate it because I'm at my wit's end... Any more ideas?

One quick suggestion - if you're still getting IP banned for this, stop using bnet and switch to a more forgiving server.  Connect to the test server with a real client, and then connect with yours enough times to overflow.  Have a packetlogger running during all of these connections.  Ideally, save the capture of the real client to one file, and the captures of your client to two other files (one for first pass, one for error pass).  Then you can compare the packet dumps for protocol errors.  Beware that the test server may not even drop you for the violation, so you'll need to rely on other indicators (VB's overflow error, past experience, etc.) to indicate that you've got a "bad" connection captured.

If you need a packet capture program, get Ethereal (free).  Works best on real (non-Microsoft) systems, but you can coax it to work on MS-Windows.

I'm not getting ipbanned, as long as I make sure I switch servers once the RTE occurs if I'm not planning on restarting VB. If I restart VB when the RTE occurs, apparently the program connects without a problem. Weird, no? I'm thinking maybe my winsock is damaged? Because apparently it works for the others, but not for me.

[Edited to avoid double-posting]

I just reinstalled the winsock. Still the same results. I don't understand why you guys have no problem reconnecting with the bot, while I do...

Huzzah?  Try using the CSocket class.  It's a bit more friendly than the MS control.

I did not look at it but I thought I might throw this out, have you tried making a new socket after disconnecting?

Get this, the people who downloaded my bot had NO PROBLEMS reconnecting, and yet I did.

I'm so confused... I'm talking to  l2k-Shadow on AIM right now, we're trying to figure it out and having no luck. He suggested using ws api, then I suddenly went AFK cuz i needed to pick up advil for gf, then i got back- he had gone afk as well... lol, how's that for poetic justice? heh.

In any case, hopefully he'll get back soon, and we'll try to figure it out. If not, I'll try the CSocket class...

I was wondering about that, try reinstalling your winsock ocx, or like rabbit and I have said, Try CSocket.  I'd do both.

Okay, any idea where can I get a fresh winsock.ocx? I used google, most of the results gave me win 95 setups, and they wouldn't execute for me because my OS is winxp.

Tried using CSocket, got confused-- but will try again if fresh winsock.ocx doesn't work.

[quote author=Kyro link=topic=12811.msg128210#msg128210 date=1126760224]
Okay, any idea where can I get a fresh winsock.ocx? I used google, most of the results gave me win 95 setups, and they wouldn't execute for me because my OS is winxp.

Tried using CSocket, got confused-- but will try again if fresh winsock.ocx doesn't work.
[/quote]

It's mswinsck.ocx, not winsock.ocx

I think my winsock's corrupt. In any case, I instructed the SendData sub to ignore the overflow error and pretend it DID send. weird thing is, according to bnet, it DID recieve the packets- I was able to join channels, chat, everything, no bugs whatsoever in spite of my ignoring packet overflow error.

Don't know why it's being like that, but apparently having the SendData ignore the error solved the problem.

Thanks everyone for your assistance!

[quote author=Kyro link=topic=12811.msg128307#msg128307 date=1126846016]
I think my winsock's corrupt. In any case, I instructed the SendData sub to ignore the overflow error and pretend it DID send. weird thing is, according to bnet, it DID recieve the packets- I was able to join channels, chat, everything, no bugs whatsoever in spite of my ignoring packet overflow error.

Don't know why it's being like that, but apparently having the SendData ignore the error solved the problem.

Thanks everyone for your assistance!
[/quote]

That's not fixing that's ignoring an error.

[quote author=Shout link=topic=12811.msg128313#msg128313 date=1126846343]
That's not fixing that's ignoring an error.
[/quote]
Well, it is VB... ::)

LMAO...

Well, I've had a couple others test the bot, and they experienced absolutely no errors, so I think the error was specific to my laptop. Probably a corrupt driver. But in any case, I never said I fixed the problem, I said I solved the problem. Which means, while the error exists, it's being ignored by bot, which means, I won't see even a trace of it because it's being surpressed, which means it won't bother me, which means it ceases to be a problem for me.

Problem solved.

Now, enough of "which means", again, thanks everyone for your help, it's definitely appreciated!

And I couldn't agree more with Blaze- it's VB after all! LMAO  ;) :D ::)

Hiding problems can lead to problems, such as you can't figure out whats not working, no errors are showing but its not working. :P

If something suddenly stops working, all I have to is uncomment the error handler lines I pre-coded in SendData. I might code an internal command so I can just do:

/debug

Then the bot will start displaying all internal messages, operations, actions, and especially errors. Most of the code is already in place, so that idea's probably worth something.

And in any case, like I said, I had couple of others test my bot, and none of them saw the error-- that was BEFORE i put SendPacket error surpression code into place-- so I'm not too worried about it causing problems.

And if it does-- well, I'll cross that bridge when I come to it. LOL.