Question: Why not use the parsers at libpnet?

[stephanbuys]

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?

[JulianSchmid]

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

[Hirrolot]

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.

[balboah]

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

[mhils]

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. :)