On 2023-08-01 19:39, Mark Saad wrote:
On Aug 1, 2023, at 7:57 PM, Zane C B-H <v.ve...@vvelox.net> wrote:
On 2023-08-01 18:44, Mark Saad wrote:
On Aug 1, 2023, at 4:39 PM, Zane C B-H <v.ve...@vvelox.net> wrote:
So what is a good way to get all packets passing through that the
kernel currently sees? Apparently any is not support on non-Linux
systems and pflog would require adding log to all rules. Similarly
only logs packets that match a rule.
Just run tcpdump without the -i , iirc this will dump everything.
Nope. This just runs it on the first interface it finds.
- pflog - requires PF, requires adding it to all rules
- ipfw tee - requires ipfw, not bad but it requires some one already
be using ipfw
- deamonlogger - unmaintained... quiet literally dead upstream
- suricata - can't tell it to for example not log packets for TCP port
443, which for most FPC purposes just chew up disk space and all
meaningful info will be in the suricata TLS log
Now as to the question of firing up multiple instances of tcpdump,
this means that you will have duplicate packets where bridges are
involved.
I haven’t tried it personally but maybe with Netgraph you can make a
tap of all of this ?
What is your goal ?
Replacement for daemonlogger given it is dead upstream and no one else
has picked up development. On Linux the same can easily be accomplished
via tcpdump and the pcap rotation options and then just using removing
old files based on age/disk usage. Unfortunately FreeBSD lacks support
for '-i any'. In many ways settled upon tcpdump as it is not likely to
just stopped be developed.
Netgraph looks semiworkable via one2many and setting the interfaces on
the many side or promisc, but this also creates the issue of the
listening interface can also transmit. That said looks like putting the
connected ng_iface in monitor mode at creation should solve that. Been
looking at that on and off today trying to wrap my head around netgraph.
