search

rust-pcap / pcap

Rust language pcap library
Apache License 2.0
598 stars 138 forks source link

Sendqueue #237

Closed qrnch-jan closed 1 year ago

qrnch-jan commented 2 years ago

Implement support for sendqueue, which is a feature available in winpcap/npcap that allows Windows applications to send raw packets at a high sustained rate.

Stargateur commented 2 years ago

I forget to add this require some tests.

And also you forget update CHANGELOG

Overall, this doesn't look very user-friendly. Need to call reset() "at hand", no much configuration.

qrnch-jan commented 2 years ago

The original sendqueue API is very .. spartan.

It doesn't have any reset at all, and the transmit function doesn't automatically reset. Apparently if the transmit fails, the len is used to keep track of what packet failed. So calling transmit again will retry from that point. To reset one can manually set the len to 0. (Which is what the crate's reset() does).

Also, I learned that the alloc/release functions don't actually allocate any magic buffer -- we could allocate any regular "Rust" buffer instead. I used the sendqueue API's in case that changes in the future. However, npcap's developer was quite clear about that it is safe to completely manage the buffer oneself.

Anywho; I'll work on the remaining points, and with regards to user-friendlieness -- I can make the transmit auto-reset on success. Were there any other changes you had in mind?

qrnch-jan commented 2 years ago

I forget to add this require some tests.

I'm having some trouble with this, because there's no obvious target to send packets to.

These updates are being developed for an application which has both a sender and receiver end, but this is not easily transformed to an isolated test case.

qrnch-jan commented 2 years ago

I've added an example which manually builds raw ethernet packets, queues them up and transmits them. It uses a non-standard ethertype to avoid clashing with existing standard protocols. One could argue that this could interfere with non-standard ethernet devices using ethertype 0x5555, but I figure that anyone looking to send raw ethernet packets is well aware of what this means.

The upside is that one can run a packet capture tool and filter on ethertype=0x5555 on the receiving system to easily see the transmitted packets, without getting noise from regular traffic.

I could make the ethertype configurable, but going by the other examples it looks like the examples are meant to be to-the-point (i.e. act as reference code).