Date: Tue, 01 Aug 2023 22:49:32 -0500 From: Zane C B-H <v.velox@vvelox.net> To: Mark Saad <nonesuch@longcount.org> Cc: net@freebsd.org Subject: Re: Is there a FreeBSD equivalent of 'tcpdump -i any' from Linux? Message-ID: <3376670f5c14ac160e75420a2c168481@vvelox.net> In-Reply-To: <E3D42774-9C4D-44AC-8331-BA9F4B670834@longcount.org> References: <cb86f295fd30f94b57aaebb3ed8d6351@vvelox.net> <E3D42774-9C4D-44AC-8331-BA9F4B670834@longcount.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2023-08-01 19:39, Mark Saad wrote: > On Aug 1, 2023, at 7:57 PM, Zane C B-H <v.velox@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.velox@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3376670f5c14ac160e75420a2c168481>