-
Notifications
You must be signed in to change notification settings - Fork 447
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
Comments
Why not just depend on smoltcp without any of its features? |
I can totally do that. But don't you mind the wire module having code for protocols that are not really used in |
somewhat offtopic, but pktparse-rs might be an alternative. |
@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. |
@little-dude OK, looking closer at gopacket/layers I now see what you mean. It is indeed massive. Here's what I suggest:
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. |
Thanks @whitequark.
That would be nice yeah :) @kpcyrd that's a cool library for decoding packets, but as @whitequark said, I also need constructors to send packets. |
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. |
Hi,
The
wire
module provides abstractions for packet decoding, which could also be useful outside ofsmoltcp
. 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.
The text was updated successfully, but these errors were encountered: