Proposals for v6, v7

[kayoub5]

Remove CaptureDeviceList

The idea is to avoid having stateful non-thread safe singletons
The API would like something like this

var inf = PcapInterface.GetAllPcapInterfaces().First();
using var device = LibpcapDriver.Open(inf, new DeviceConfiguration() {....});
// methods Open and Close of the device would be removed.
// a device is either Open or Disposed
// This would match other .NET APIs like Stream, See https://docs.microsoft.com/en-us/dotnet/api/system.io.file.open?view=net-5.0 for example.

Helper Functions

LibpcapDriver.Open(NetworkInterface networkInterface);
LibpcapDriver.OpenStatistics(PcapInterface pcapInterface);
LibpcapDriver.OpenStatistics(NetworkInterface networkInterface);

Use IObservable

• This would simplify the Capture API surface, no more event handlers and Start/Stop Methods.

Managed implementation of PCAP/PCAPNG reading

• Having to install third party drivers just to open a file seems to be an overkill for some end users.
• Some use cases like seeking and multiple interfaces support in PCAPNG, are not topics that I would not expect libpcap to solve any time soon.

See example https://github.com/awalsh128/PcapngFile

Remove dependency on PacketDotNet

• The dependency of SharpPcap on PacketDotNet just for LinkLayers enum feels unnecessary.

[chmorgan]

@kayoub5 IObservable looks like a great fit to simplify the capture API. It's new in 5.0?

On managed pcap/pcapng reading I had seen that library a little while back. Agreed on them not solving the problems soon but these are solved in that library? Should we approach the author to join the organization and then leverage the library as a new dependency? I'd also like us to open a ticket or tickets against libpcap with at least some of the requests we have so they are aware of the need. It may be that someone would implement them but there hasn't been the time. Alternatively we could implement them but then we'd also have to wait for the release cycle to make use of them... anyway, I'd still like if you could report the gaps to them if they aren't already aware of them. We are a relatively well known user of libpcap and the devs have been responsive in the past.

How to remove the dependency on PacketDotNet for that type while ensuring the type is the same across libraries? Or do we not and instead return a number that has to be cast or something?

[kayoub5]

@kayoub5 IObservable looks like a great fit to simplify the capture API. It's new in 5.0?

Been around since .NET Standard 1.0

[kayoub5]

How to remove the dependency on PacketDotNet for that type while ensuring the type is the same across libraries?

Move that type to its own assembly/package, that way both would depend on a base package that is less likely/frequently to change.

Or do we not and instead return a number that has to be cast or something?

Also valid.

[kayoub5]

On managed pcap/pcapng reading I had seen that library a little while back. Agreed on them not solving the problems soon but these are solved in that library? Should we approach the author to join the organization and then leverage the library as a new dependency?

sounds like a good plan, but I would prefer merging code bases instead of dependency if possible.

[chmorgan]

On managed pcap/pcapng reading I had seen that library a little while back. Agreed on them not solving the problems soon but these are solved in that library? Should we approach the author to join the organization and then leverage the library as a new dependency?

sounds like a good plan, but I would prefer merging code bases instead of dependency if possible.

It could be quite a few lines of code. Looking at https://github.com/ryrychj/PcapngUtils for example.

[chmorgan]

@kayoub5 would the IObservable improve the behavior seen in that recent access exception?

[kayoub5]

depends on how you implement it, the interface alone is not enough to guarantee such errors don't happen.