You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The only invocation of setfilter() on the capture device (pcapy.Reader class) is based on the initial_bpf from the first plugin on the chain.
Because of this, any efforts to expand the filter are moot. Narrowing of the filter seems effective through manipulating compiled bpf filters on the plugin objects, but only the packets pulled from the wire or file (governed by the pcapy.Reader filter) are ever passed to the feed_plugin_chain function.
It seems we may need a mechanism to update the Reader filter when bpf filters are changed in the plugin chain. But this is not trivial, because recompiling bpf happens in the plugin object and the instantiated Reader appears only in decode.py.
I initially noticed this because the automatic vlan wrapper wasn't working with any plugin on vlan tagged PCAP files, but it has potential effects also in chained plugins and plugins that dynamically alter their bpf filters.
The text was updated successfully, but these errors were encountered:
From my understanding plugins further down the chain only receive packets that the earlier plugins have not filtered out. This is by design. They are layered.
To get what your describing, dshell would need to able to support parallel plugin chains. Although, it would probably be simpler to just do multiple runs of dshell if you are just processing pcap files.
Much of the reason we have not responded to this issue is because we do not know of a quick way to fix it, or if such a fix is desirable. @amm3 is correct that plugins on the chain cannot expand the filter of what enters the chain.
If, for example, Plugin B decides it needs packets from an ephemeral port, it has no way of telling Plugin A to expand its filter. However, it might not be possible to expand Plugin A's filter, if it was written to expect a static filter.
If anybody has suggestions, we would be happy to hear them!
The only invocation of
setfilter()
on the capture device (pcapy.Reader
class) is based on theinitial_bpf
from the first plugin on the chain.Because of this, any efforts to expand the filter are moot. Narrowing of the filter seems effective through manipulating compiled bpf filters on the plugin objects, but only the packets pulled from the wire or file (governed by the
pcapy.Reader
filter) are ever passed to thefeed_plugin_chain
function.It seems we may need a mechanism to update the Reader filter when bpf filters are changed in the plugin chain. But this is not trivial, because recompiling bpf happens in the plugin object and the instantiated Reader appears only in
decode.py
.I initially noticed this because the automatic vlan wrapper wasn't working with any plugin on vlan tagged PCAP files, but it has potential effects also in chained plugins and plugins that dynamically alter their bpf filters.
The text was updated successfully, but these errors were encountered: