List:Internals« Previous MessageNext Message »
From:Baron Schwartz Date:April 12 2009 9:13pm
Subject:Re: Client Authentication Packet w/ databasename
View as plain text  
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.
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