[enhancement] Add MySQL client/server protocol layer in scapy.contrib (MVP)

[pablogonzalezpe]

Title: [enhancement] Add MySQL client/server protocol layer in scapy.contrib (MVP)

Hi Scapy maintainers,

I would like to contribute a new protocol module for MySQL in scapy.contrib to simplify parsing and crafting MySQL packets during analysis and testing.

Reference style I plan to follow:

• scapy/contrib/postgres.py
• Existing UTScapy contrib tests in test/contrib/*.uts

Motivation

• MySQL is common in lab traffic and security assessments.
• Having native packet classes would make dissections and crafted exchanges easier than manual byte handling.
• A contrib module seems appropriate as a first step before considering broader scope.

Proposed scope (MVP)

• Add scapy/contrib/mysql.py with:
  • MySQL packet header (payload_length on 3 bytes + sequence_id)
  • Initial Handshake (Protocol::HandshakeV10) parsing/building
  • Handshake Response (client) basic parsing/building
  • Core server responses: OK_Packet, ERR_Packet, EOF_Packet
  • COM_QUERY packet support
  • TCP binding on port 3306
• Add regression tests in test/contrib/mysql.uts with deterministic byte fixtures.

Out of scope for MVP

• Full command set coverage
• Full capability/auth plugin matrix
• Compression protocol and all optional extensions
• Complex session reassembly edge cases beyond base packet framing

Design goals

• Keep API Scapy-like and minimal.
• Avoid external runtime dependencies.
• Keep implementation and tests small and reviewable.

Questions for maintainers

• Is scapy.contrib the right location for this protocol initially?
• Is the MVP scope above acceptable for a first PR?
• Any preferred naming conventions for MySQL packet classes/fields before implementation starts?

If this direction looks good, I will open a first Draft PR with the MVP and UTScapy tests.

[pablogonzalezpe]

Hi maintainers,

I wanted to gently follow up on this proposal in case you have any initial feedback on the scope or preferred design.

I have already started working on a first MySQL layer prototype on my fork, but before going too far I would be very happy to align with your expectations. If you would prefer a smaller MVP, a different module structure, or a different direction altogether, I would be glad to adjust.

Thanks again for your time and for maintaining Scapy.

[gpotter2]

Hi & sorry for the delay in answering,

Is scapy.contrib the right location for this protocol initially?

Yes !

Is the MVP scope above acceptable for a first PR?

The general rule is as follows: we will not merge something that is so incomplete it's unusable "as-is". If your PR is well built enough so that it can, for instance, parse most of a pcap, it's fine. If really it implements something like 10% of the spec, it's "unusable" and should remain a PR until more evolved. When you have a protocol with gazillions commands (e.g. Bluetooth), it is fine if a whole bunch of them are unimplemented, but the basics should (must) be.

Any preferred naming conventions for MySQL packet classes/fields before implementation starts?

Keep as close the spec as possible.