proposal: multiple ports, pcap options and isolating capture package #784
Assignees
Labels
enhancement
New feature or feature request
Comments
|
it almost feels like that Pcap capability should be extracted from the raw-input itself, and act like a singleton. So multiple input raw plugins communicate with it via some interface. |
|
About |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
PCAP Options to improve
snapshot length: we have only two possibilities, if
input-raw-override-snaplenis falsethe maximum transmission unitof an interface will become its handler snapshot length otherwise the snapshot length is set to64kbwhich may be problematic to some interface like USB with snapshot length of up to 256kb. the user may also wish to have a smaller snapshot to only capture headers. for this,input-raw-snaplen** can be an unsigned 32-bit integer** which indicates the snapshot length. if its 0, the snapshot will be the MTU (or 64kb if we can't get the MTU) else the snapshot will be equal toinput-raw-snaplenflag.promiscuous, monitor mode: should also be opt-in, this is to say they will not be enabled unless enabled by the user. for this, we need to add a new flag called
--enable-promiscuousand--enable-monitorflag.input raw expires: currently flag
input-raw-expirehas two functions, to set the maximum time to wait for the final packet in TCP and to set the timeout of apcap handler. However, the behaviors of pcap timeout shouldn't be confused by the time we wait for the final packet otherwise there can be some unexpected behaviors likelosing large amount of packetsand it's likely that there will be onlya single read for the entire message. For this, we can have two separate flagsinput-raw-message-expireandinput-raw-buffer-expire. the default value ofinput-raw-buffer-expireis a negative time!Isolating capture package
for the sake of scalability, future improvements, and supporting people who may wish to implement their own sniffer, we can isolate the functionalities of capturing. this is to say package capture will solely be responsible for handling the functionalities of reading packets and it will send data of type gopacket.Packet over channels. there will be other packages like
tcpto handle re-ordering of packets and managing lost packets, this may help users to implementother transport layer protocols. However, Listener will have a field that indicates the transport layer expected(this will help us to setdefault BPFFilterso that listener can capture packet from one type of transport layer). Some other functionalities may be isolated into packages too, likeoutput,inputetc...Multiple ports
pcap may listen to multiple ports when port is
0. range of ports can be configured by using BPF filters e.g:dst portrange 3000-8000 and src portrange 3000-8000. packets handling will be possible but how messages will be handled by the output, in this case, is not yet defined!The text was updated successfully, but these errors were encountered: