List:Internals« Previous MessageNext Message »
From:Eric Bergen Date:April 12 2009 11:10pm
Subject:Re: Client Authentication Packet w/ databasename
View as plain text  
I think wireshark (formerly ethereal) speaks mysql protocol. It may be
easier to use that than to write a custom parser for mysql binary
protocol.

I remember reading some of the network code and noticing that
individual row writes are buffered and sent as larger packets. I think
it's in net_serv.cc my_net_write()

-Eric

On Sun, Apr 12, 2009 at 2:13 PM, Baron Schwartz <baron@stripped> wrote:
> OK, so peeking into the protocol is making me think about all sorts of
> things I hadn't before.  For one thing, I assume (but haven't any
> proof) that not only can a network packet contain multiple protocol
> packets, but a protocol packet could be fragmented across network
> packets.  An IPv4 packet can't be bigger than 65k, but a protocol
> packet can be up to 16MB.  True/false?
>
> If I keep going on this, I'm going to read some source code :-)
>
> For those who are curious, I'm looking at what information I can
> extract from tcpdump.  As consultants, we often need to mine what we
> can without touching the system in pretty much any way -- including
> installing Perl modules or what have you.  So I'm trying to write a
> tool that can get as much information as conveniently possible from
> the following scenario:
>
> tcpdump -i eth0 ..... -w traffic.log
> scp traffic.log some@othermachine:traffic.log
> # go to othermachine
> tcpdump -r traffic.log <options> | my_parser_tool
>
> Of course, tcpdump isn't necessarily going to dump full packets.  And
> I don't really want to spend a ton of effort looking for how many rows
> were in the result, etc (which would be futile anyway if the packets
> are truncated by tcpdump).  Plus, if a 16M packet is fragmented -- or
> if there are multiple packets for sending some even larger value -- I
> don't think that's worth fooling with.
>
> Right now I've got a working implementation that pulls out queries to
> the server, including a bunch of information from the protocol. That
> is, I'm not just doing something like "strings" to extract queries.
> And I'm watching the conversation to determine timing of the response,
> but not really investigating anything about the response itself other
> than success or failure; it's stateful enough to track sessions, but
> that's about all.  I'm thinking if I have the full response at both
> the IP level and the MySQL protocol level, I might as well go ahead
> and look at the final EOF packet and see what it has -- for example,
> the "Rows affected" message is an easy target for parsing.  Too bad
> "rows sent" isn't sent redundantly too ;-)
>
> Any thoughts are welcomed.
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals?unsub=1
>
>



-- 
Eric Bergen
eric.bergen@stripped
http://www.provenscaling.com
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