Closed stephanbuys closed 5 years ago
Hi Stephan,
I had no special reasons for writing my own, except as a learning exercise & I wanted to see how far I could get without allocating any memory. It was one of those "I can write this over a weekend" projects, that spiraled out of control.
I actually never looked at libpnet before. So I can not provide you with a detailed analysis, but after having a short look at the documentation libpnet looks pretty good.
Pnet supports more protocols & also gives you a bunch of other features. The interface listening support also looks pretty cool. Pnet seems to also allow the in mutable slice modification of packages, which etherparse also does not have.
My lib seems to have more extensive error types providing a reason why the parsing or slicing of a package failed. But otherwise I see no reason you should choose etherparse over libpnet.
It ultimately comes down to your use-case and personal preference.
Greets Julian
I found that it's much easier and less error-prone to use etherparse
than libpnet
because when using libpnet
you need to care about checksums, header/payload/packet lengths and much more, also it's very hard to read the libpnet's sources because of a plenty of macros.
I felt that the resulting etherparse code was easier to read for parsing packets, and that it compiles for IOS without changes which libpnet did not
To add to this list: My IDE happily does code completion for etherparse, whereas it borks on libpnet's macros. This makes etherparse much more convenient to use in my case. :)
Hi Julian, I'm currently hunting for a good ethernet frame parser, I like your crate a lot but am leaning towards libpnet as it has so much other low-level support. Is there a reason why you decided to roll your own?