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

Would a dedicated crate for packet decoding make sense? #54

Closed
little-dude opened this issue Oct 11, 2017 · 7 comments
Closed

Would a dedicated crate for packet decoding make sense? #54

little-dude opened this issue Oct 11, 2017 · 7 comments

Comments

@little-dude
Copy link
Contributor

Hi,

The wire module provides abstractions for packet decoding, which could also be useful outside of smoltcp. For example, I am considering implementing the OpenFlow protocol and I'd like to re-use what you already did for packet parsing and add support OpenFlow headers.

In case I'm unclear, I'd like to see something similar to Golang's gopacket/layers library.

@whitequark
Copy link
Contributor

The wire module provides abstractions for packet decoding, which could also be useful outside of smoltcp.

Why not just depend on smoltcp without any of its features?

@little-dude
Copy link
Contributor Author

I can totally do that. But don't you mind the wire module having code for protocols that are not really used in smoltcp ? For instance, would you accept a PR that add support for decoding OpenFlow headers?

@kpcyrd
Copy link

kpcyrd commented Oct 11, 2017

somewhat offtopic, but pktparse-rs might be an alternative.

@whitequark
Copy link
Contributor

@little-dude Sure why not, if it's up to smoltcp's code quality. We can always split it afterwards.

@kpcyrd That doesn't provide constructors.

@whitequark
Copy link
Contributor

whitequark commented Oct 25, 2017

@little-dude OK, looking closer at gopacket/layers I now see what you mean. It is indeed massive.

Here's what I suggest:

  • You depend on smoltcp for (e.g.) its ip::checksum function, IpAddress enum, and so on.
  • You decode OpenFlow in your own wire module in your own crate. The parsing and serialization itself in smoltcp are extremely lightweight--they do not use some combinators or macros or so on, so there isn't really any code in smoltcp to depend on.
  • Once there's a nontrivial demand of a library like gopacket/layers we branch that out into its own crate, or otherwise decide.

Right now I don't really have the bandwidth to review everything, but I don't see why we can't do this a bit later when we have more contributors.

Sorry, something went wrong.

@little-dude
Copy link
Contributor Author

Thanks @whitequark.
Openflow itself being massive, I started a new crate with smoltcp as dependency, like you said.

Once there's a nontrivial demand of a library like gopacket/layers we branch that out into its own crate, or otherwise decide.

That would be nice yeah :) gopacket is a great library. As far as I know libpnet is the closest thing that exists in Rust so far.

@kpcyrd that's a cool library for decoding packets, but as @whitequark said, I also need constructors to send packets.

Sorry, something went wrong.

@whitequark
Copy link
Contributor

I've considered building smoltcp on top of libpnet but I really dislike their heavy-handed type-based approach. As you can see smoltcp keeps things very simple.

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

No branches or pull requests

3 participants