BNLS question

[brew]

Are the 0x09 and 0x18 packets for BNLS no longer supported? I don't seem to get a response sending them, only with 0x1A would I get a response. :-(

[Hdx]

They should still work.
Sky likes ot keep backwards compatibility
Post some logs.
~Hdx

[brew]

Code Select Expand


Public Sub BNLSSend0x09()
    With pbuffer
        .InsertDWORD GetClient(Bot.Client)
        .InsertDWORD Bot.mpqNumber
        .InsertNonNTString Bot.ChecksumFormula
        .SendBNLSPacket &H9
    End With
End Sub

C > S:
1B 00 09 03 00 00 00 01 00 00 00 CD 7E 2D 28 54  ............~-(T
53 59 F3 EF 8F 53 EC 29 A1 A0 AA                 SY...S.)...

S > C:
No Response
____________________________________________________

Public Sub BNLSSend0x18()
    With pbuffer
        .InsertDWORD GetClient(Bot.Client)
        .InsertDWORD Bot.mpqNumber
        .InsertDWORD 0
        .InsertDWORD GetTickCount
        .InsertNonNTString Bot.ChecksumFormula
        .SendBNLSPacket &H18
    End With
End Sub

C > S:
23 00 18 03 00 00 00 13 00 00 00 00 00 00 00 CA  #...............
F9 4D 00 50 35 BD FE 06 FB 8E 64 21 7E 7C E3 4D  .M.P5.....d!~|.M
FD 50 A9                                         .P.           

S > C:
No Response
________________________________________________________

Public Sub BNLSSend0x1A()
    With pbuffer
        .InsertDWORD GetClient(Bot.Client)
        .InsertDWORD 0
        .InsertDWORD GetTickCount
        .InsertNonNTString Bot.mpqFileTime
        .InsertNTString Bot.mpqName
        .InsertNonNTString Bot.ChecksumFormula
        .SendBNLSPacket &H1A
    End With
End Sub

C > S:
40 00 1A 03 00 00 00 00 00 00 00 BD F0 4E 00 00  @............N..
AC D0 D2 72 FC C6 01 31 30 2E 6D 70 71 00 E6 85  ...r...10.mpq...
E7 C0 BC B0 F3 88 31 A6 2B F9 83 25 DF 85 00 00  ......1.+..%....
E6 85 E7 C0 BC B0 F3 88 31 A6 2B F9 83 25 DF 85  ........1.+..%..

S > C:
29 00 1A 01 00 00 00 00 02 00 02 B7 47 A6 AD 70  )...........G..p
36 21 FB E9 F8 EA 35 D8 26 60 D7 2F 40 63 0D 02  6!....5.&`./@c..
00 BD F0 4E 00 4F 00 00 00                       ...N.O...       



EDIT****
Heh... 0x1A has some pretty good packet handling. It turns out that I forgot I changed the way I parse the 0x50 and get the checksum formula (before i didn't remove the null terminator)  thanks for helping though

[l2k-Shadow]

The legacy version check messages (BNLS_VERSIONCHECK, BNLS_VERSIONCHECKEX) will continue to default to the old-style version check system, for compatibility reasons.
As a result, you must switch to the new version check message if you wish to support products that use the new-style version check system (or future systems).

so you may want to keep using 0x1A

[Hdx]

Your data is ALL messed up!

Code Select Expand

1B 00 09 ... Good
03 00 00 00 .... Good
01 00 00 00 .... Good
CD 7E 2D 28 54 53 59 F3 EF 8F 53 EC 29 A1 A0 AA .~-(TSY...S.)... Umm.. Wheres your null?

Code Select Expand

23 00 18 #..
03 00 00 00 .... Good
13 00 00 00 .... Good
00 00 00 00 .... Good
CA F9 4D 00 ..M. Good (Weird cookie but good)
50 35 BD FE 06 FB 8E 64 21 7E 7C E3 4D P5 FD 50 A9 .....d!~|.M.P. Once again, wheres the null byte?

Code Select Expand

40 00 1A @.. Good
03 00 00 00 .... Good
00 00 00 00 .... Good
BD F0 4E 00 ..N. Good (Once again, wierd cookie)
00 AC D0 D2 72 FC C6 01 ....r... Good (Not sure if right value but format is good)
31 30 2E 6D 70 71 00 10.mpq. I've ever seen '10.mpq' you're extracting the name incorrectly
E6 85 E7 C0 BC B0 F3 88 31 A6 2B F9 83 25 DF 85 00 ........1.+..%... Looks okay
00 E6 85 E7 C0 BC B0 F3 88 31 A6 2B F9 83 25 DF 85  .........1.+..%.. WTF is all this?
You're sending the value string TWICE?
And the 2nd time is without the null terminator.
In short, you're sending the wrong data, and the value strings in 0x09 and 0x18 are null terminated.
~Hdx

[brew]

umm.. i modified my post about that literally 1-2 minutes after i realized my problem  a little late don't you think? also..... if you had read the code you would have found where i got the values for my cookies from...
@Shadow: what bnls packet to use is an option in my bot anyways

[Hdx]

Ya I know where you got the cookie. But a cookie is something that should be constant, so you know exactly what part of the login sequence that packet is for.
Anyways, you should not remove th null terminator a log with the value string, as it is not part of it.
You should look into getting a 'DeBuffer' class.
Whenever you use 'NonNTString' in general, you're doing it a bad way.
~Hdx

[brew]

Ya I know where you got the cookie. But a cookie is something that should be constant, so you know exactly what part of the login sequence that packet is for.

really? i thought a cookie was supposed to help in handling multiple requests

Anyways, you should not remove th null terminator a log with the value string, as it is not part of it.

that entire sentence didn't make sense. no offense sorry.

You should look into getting a 'DeBuffer' class.

No thx

[MyndFyre]

Ya I know where you got the cookie. But a cookie is something that should be constant, so you know exactly what part of the login sequence that packet is for.

really? i thought a cookie was supposed to help in handling multiple requests

Anyways, you should not remove th null terminator a log with the value string, as it is not part of it.

that entire sentence didn't make sense. no offense sorry.

LOL, Hdx actually got told by brew!  I think that's brew's first coherent post!

[brew]

Well... I didn't mean to really tell him off, and I'm sorry Hdx if I had insulted you, I was just in a bad mood when I made that post. Sorry again. But ... honestly. There was absolutely nothing else wrong with my packets except that I changed the way I parsed the checksum formula, and before that I left the null terminator on it. But now I didn't, and I didn't update the bnls packets I personally blame the 0x1A's superior packet parsing methods for not warning me that I'm not null terminating a null terminated string (or just not returning a packet), D'oh! And it doesn't really matter how I'm parsing the mpq name, does it? It's just something to ensure PvPGN server compatibility. I get the same end result of what I need (the mpq number) anyways. Really all I had to do is Val() the mpqname to get the mpqnumber. And since the 0x1A (which is recommended to use by just about everyone here) parses the mpqname and gets the proper result (mpq number!) reguardless of what you have, I don't see any harm done. 

Then there's the late post response time, even when I clearly edited my post to show I found it, I don't need your help, I found my problem, but thanks anyways.
« Last Edit: June 09, 2007, 11:47 AM by brew » 

« Last Edit: June 09, 2007, 12:10 PM by Hdx » 

But then again, here:

You're sending the value string TWICE?

Erm... apparently yes. I'll have to look into that. Not that there's any harm done :-P Look at the code I used to send the 0x1A too.

[Hdx]

Ya I know where you got the cookie. But a cookie is something that should be constant, so you know exactly what part of the login sequence that packet is for.

really? i thought a cookie was supposed to help in handling multiple requests

My bad, constant was the wrong word. Consecutive, simple. Something that would be easily identifiable as the current packet.
I guess GTC works. But I like to do a cookie counter for each packet.
{
Each Send Cookie++
While(Cookie) {wait for packet; remove cooke form list;}
something like that.
~Hdx