List:Internals« Previous MessageNext Message »
From:Baron Schwartz Date:April 12 2009 11:26am
Subject:Re: Client Authentication Packet w/ databasename
View as plain text  
Hi Eric,

I think if we omit mention of the 0x00 filler byte, I think the
document will be correct then, because the length-coded binary
scramble buffer isn't 0x00-terminated.  Only the databasename is. It's
a good thing it sends the length of the scramble buffer when there's
no password, otherwise how could one tell the difference between the
length-coding byte and the beginning of the database :)

I'm fixing the description for the 4.1 protocol, but I'm not touching
anything about the 4.0 protocol.  BTW, does libdrizzle handle that?

On Sat, Apr 11, 2009 at 11:42 PM, Eric Day <eday@stripped> wrote:
> Hi Baron,
>
> You are correct, there is no NULL byte between the scramble and
> database name. There is actually another ambiguous byte to watch out
> for if you are parsing your own packets. If there is no database
> given, there will not be a NULL character after the scramble. For
> this you need to check the CLIENT_CONNECT_WITH_DB flag (or just check
> remaining packet length). To me, it seems like you could go either
> way with that NULL byte, but this matters if you are checking for
> errors to ensure exact packet. The wiki page mentions it is optional,
> but doesn't mention the WITH_DB flag.
>
> For example:
>
> Without database:
>
>          3a00 0001 85a6 0300 0000 0001    
>  :...........
> 0800 0000 0000 0000 0000 0000 0000 0000  ................
> 0000 0000 0000 0000 726f 6f74 0014 7b22  ........root..{"
> 2f1a 16df 88ca caa4 dcad a913 e3a9 93f6  /...............
> 653a                      
>               e:
>
> With database:
>
>          4300 0001 8da6 0300 0000 0001    
>  C...........
> 0800 0000 0000 0000 0000 0000 0000 0000  ................
> 0000 0000 0000 0000 726f 6f74 0014 7267  ........root..rg
> 7ce8 d7e8 8a47 b353 44a3 8ce1 c636 8ba4  |....G.SD....6..
> a2fb 6461 7461 6261 7365 00            
>  ..database.
>
>
> Also, the packet example is not correct in that it always sends the
> length of the scramble buffer, even when 0:
>
>          2600 0001 85a6 0300 0000 0001    
>  &...........
> 0800 0000 0000 0000 0000 0000 0000 0000  ................
> 0000 0000 0000 0000 726f 6f74 0000       ........root..
>
> Note the NULL byte after username and then a 0-length scramble
> buffer. The example only has one NULL byte.
>
> I ran into these (and a few others I've forgotten) while working on
> the libdrizzle client/server protocol code. :)
>
> -Eric
>
>
> On Sat, Apr 11, 2009 at 10:55:18PM -0400, Baron Schwartz wrote:
>> According to
> http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Client_Authentication_Packet
>>
>> If the client authentication packet includes the initial database, it
>> is preceded by a 0x00 filler byte.  What I'm seeing in tcpdump doesn't
>> seem to match that.  Here's what I see, with the packet header
>> omitted:
>>
>>
> 8da20300000000010800000000000000000000000000000000000000000000006d73616e64626f7800143e05bd06881b5c515a527f5228ccd1afe13ba6a86d7973716c00
>>
>> Which as I see it, is 'msandbox'  (6d73616e64626f78) trying to connect
>> to 'mysql' database (6d7973716c00).  The scramble buffer is a
>> length-coded binary that precedes 'mysql', but there's no 0x00 byte in
>> between the scramble buffer and the database name as the wiki page
>> states.
>>
>> It's a wiki; I feel like I should just fix it myself, but wanted to
>> check here first :)
>>
>> --
>> MySQL Internals Mailing List
>> For list archives: http://lists.mysql.com/internals
>> To unsubscribe:    http://lists.mysql.com/internals?unsub=1
>



-- 
Baron Schwartz, Director of Consulting, Percona Inc.
Our Blog: http://www.mysqlperformanceblog.com/
Our Services: http://www.percona.com/services.html
Thread
Client Authentication Packet w/ databasenameBaron Schwartz12 Apr
  • Re: Client Authentication Packet w/ databasenameEric Day12 Apr
    • Re: Client Authentication Packet w/ databasenameBaron Schwartz12 Apr
      • Re: Client Authentication Packet w/ databasenameBaron Schwartz12 Apr
        • Re: Client Authentication Packet w/ databasenameEric Day12 Apr
          • Re: Client Authentication Packet w/ databasenameBaron Schwartz12 Apr
          • Re: Client Authentication Packet w/ databasenameBaron Schwartz12 Apr
            • Re: Client Authentication Packet w/ databasenameEric Bergen13 Apr
              • Re: Client Authentication Packet w/ databasenameKay Röpke14 Apr
                • Re: Client Authentication Packet w/ databasenameBaron Schwartz16 Apr
            • Re: Client Authentication Packet w/ databasenameKristian Nielsen13 Apr
            • Re: Client Authentication Packet w/ databasenameMichael Widenius13 Apr
  • Re: Client Authentication Packet w/ databasenameKonstantin Osipov13 Apr