Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for #[derive(Serialize, Deserialize)] for all major structs? #69

Open
robs-zeynet opened this issue Jul 10, 2023 · 2 comments
Open

Comments

@robs-zeynet
Copy link
Contributor

I've run into some issues where I've wanted to write packets to disk in their parsed form, not in their on-the-wire format. What are folks thoughts about peppering all of the major structs (PacketHeaders, PacketSlice, and transitively) to auto-derive Serialize and Deserialize? Happy to write it myself - just wanted to ask first.

@JulianSchmid
Copy link
Owner

Hi @robs-zeynet ,

Sure I would love it.

Here are some notes from my side:

  • Add serde as non default feature, and make it optional (the PR bellow already does this).
  • You can have a look at Add serde derive macros where applicable #45 where someone already started. Note that this PR is currently not building (I just did a quick and dirty rebase of it) and is missing custom serialize implementations for the types with buffers (see next note). You don't have to use the PR, but feel free to if you want to.
  • You will have to implement the Serialize and Deserialize traits manually for structs that contain a buffer (e.g. for header options). Specifically you will have to do it in a way so only the actually used data gets serialized and deserialization fails if the data is not fulfilling the length constraints for. I think the following headers will need a custom implementation: Ipv4Options, TcpOptions, Ipv6RawExtHeader, IpAuthHeader.

Greets
Julian

@robs-zeynet
Copy link
Contributor Author

Hmm... I guess I never did this; ended up hacking around it in my own code. Sorry to bait and switch here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants