Commit b1a2fda0 authored by Brickner_cp's avatar Brickner_cp

Added more description for the flags in PacketDeviceOpenAttributes.

Taken from http://www.winpcap.org/docs/docs_412/html/group__remote__open__flags.html
parent df042104
...@@ -15,26 +15,44 @@ namespace PcapDotNet { namespace Core ...@@ -15,26 +15,44 @@ namespace PcapDotNet { namespace Core
/// <summary> /// <summary>
/// Defines if the adapter has to go in promiscuous mode. /// Defines if the adapter has to go in promiscuous mode.
/// Note that even if this parameter is false, the interface could well be in promiscuous mode for some other reason
/// (for example because another capture process with promiscuous mode enabled is currently using that interface).
/// On on Linux systems with 2.2 or later kernels (that have the "any" device), this flag does not work on the "any" device;
/// if an argument of "any" is supplied, the 'promisc' flag is ignored.
/// </summary> /// </summary>
Promiscuous = 1, Promiscuous = 1,
/// <summary> /// <summary>
/// Defines if the data trasfer (in case of a remote capture) has to be done with UDP protocol. /// Defines if the data trasfer (in case of a remote capture) has to be done with UDP protocol.
/// Use this flag if you want a UDP data connection, don't use it if you want a TCP data connection; control connection is always TCP-based.
/// A UDP connection is much lighter, but it does not guarantee that all the captured packets arrive to the client workstation.
/// Moreover, it could be harmful in case of network congestion.
/// This flag is meaningless if the source is not a remote interface. In that case, it is simply ignored.
/// </summary> /// </summary>
DataTransferUdpRemote = 2, DataTransferUdpRemote = 2,
/// <summary> /// <summary>
/// Defines if the remote probe will capture its own generated traffic. /// Defines if the remote probe will capture its own generated traffic.
/// In case the remote probe uses the same interface to capture traffic and to send data back to the caller,
/// the captured traffic includes the RPCAP traffic as well.
/// If this flag is turned on, the RPCAP traffic is excluded from the capture,
/// so that the trace returned back to the collector does not include this traffic.
/// </summary> /// </summary>
NoCaptureRemote = 4, NoCaptureRemote = 4,
/// <summary> /// <summary>
/// Defines if the local adapter will capture its own generated traffic. /// Defines if the local adapter will capture its own generated traffic.
/// This flag tells the underlying capture driver to drop the packets that were sent by itself.
/// This is useful when building applications like bridges, that should ignore the traffic they just sent.
/// </summary> /// </summary>
NoCaptureLocal = 8, NoCaptureLocal = 8,
/// <summary> /// <summary>
/// This flag configures the adapter for maximum responsiveness. /// This flag configures the adapter for maximum responsiveness.
/// In presence of a large value for nbytes, WinPcap waits for the arrival of several packets before copying the data to the user.
/// This guarantees a low number of system calls, i.e. lower processor usage, i.e. better performance, which is good for applications like sniffers.
/// If the user sets this flag, the capture driver will copy the packets as soon as the application is ready to receive them.
/// This is suggested for real time applications (like, for example, a bridge) that need the best responsiveness.
/// </summary> /// </summary>
MaximumResponsiveness = 16 MaximumResponsiveness = 16
}; };
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment