Date: Wed, 2 Aug 2023 16:04:56 +0200 From: Tino Engel <root@analengel.de> To: Zane C B-H <v.velox@vvelox.net> Cc: Mark Saad <nonesuch@longcount.org>, net@freebsd.org Subject: Re: Is there a FreeBSD equivalent of 'tcpdump -i any' from Linux? Message-ID: <E6CEBD98-6DE5-4C58-87C9-FC21D0977699@analengel.de> In-Reply-To: <3376670f5c14ac160e75420a2c168481@vvelox.net> References: <3376670f5c14ac160e75420a2c168481@vvelox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-4CA96917-BE69-4EE6-887F-7F593EDA9AD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto">Btw I think 'netcat' (<a href=3D"https://ww= w.freshports.org/net/netcat/">https://www.freshports.org/net/netcat/ </= a>) should be in the list, not?<div><br></div><div>Rgds, Tino<br><br><div di= r=3D"ltr"><blockquote type=3D"cite">Am 02.08.2023 um 10:13 schrieb Zane C B-= H <v.velox@vvelox.net>:<br><br></blockquote></div><blockquote type=3D"= cite"><div dir=3D"ltr">=EF=BB=BF<span>On 2023-08-01 19:39, Mark Saad wrote:<= /span><br><blockquote type=3D"cite"><span>On Aug 1, 2023, at 7:57 PM, Zane C= B-H <v.velox@vvelox.net> wrote:</span><br></blockquote><blockquote ty= pe=3D"cite"><blockquote type=3D"cite"><span>=EF=BB=BFOn 2023-08-01 18:44, Ma= rk Saad wrote:</span><br></blockquote></blockquote><blockquote type=3D"cite"= ><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cit= e"><blockquote type=3D"cite"><span>On Aug 1, 2023, at 4:39 PM, Zane C B-H &l= t;v.velox@vvelox.net> wrote:</span><br></blockquote></blockquote></blockq= uote></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>=EF=BB=BFSo= what is a good way to get all packets passing through that the kernel curre= ntly sees? Apparently any is not support on non-Linux systems and pflog woul= d require adding log to all rules. Similarly only logs packets that match a r= ule.</span><br></blockquote></blockquote></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite"><span>J= ust run tcpdump without the -i , iirc this will dump everything.</span><br><= /blockquote></blockquote></blockquote><blockquote type=3D"cite"><blockquote t= ype=3D"cite"><span>Nope. This just runs it on the first interface it finds.<= /span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote ty= pe=3D"cite"><span>- pflog - requires PF, requires adding it to all rules</sp= an><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D= "cite"><span>- ipfw tee - requires ipfw, not bad but it requires some one al= ready be using ipfw</span><br></blockquote></blockquote><blockquote type=3D"= cite"><blockquote type=3D"cite"><span>- deamonlogger - unmaintained... quiet= literally dead upstream</span><br></blockquote></blockquote><blockquote typ= e=3D"cite"><blockquote type=3D"cite"><span>- suricata - can't tell it to for= example not log packets for TCP port 443, which for most FPC purposes just c= hew up disk space and all meaningful info will be in the suricata TLS log</s= pan><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite"><span>Now as to the question of firing up multiple instances of tc= pdump, this means that you will have duplicate packets where bridges are inv= olved.</span><br></blockquote></blockquote><blockquote type=3D"cite"><span>I= haven=E2=80=99t tried it personally but maybe with Netgraph you can make a t= ap of all of this ?</span><br></blockquote><blockquote type=3D"cite"><span>W= hat is your goal ?</span><br></blockquote><span></span><br><span>Replacement= for daemonlogger given it is dead upstream and no one else has picked up de= velopment. On Linux the same can easily be accomplished via tcpdump and the p= cap rotation options and then just using removing old files based on age/dis= k usage. Unfortunately FreeBSD lacks support for '-i any'. In many ways sett= led upon tcpdump as it is not likely to just stopped be developed.</span><br= ><span></span><br><span>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 t= he connected ng_iface in monitor mode at creation should solve that. Been lo= oking at that on and off today trying to wrap my head around netgraph.</span= ><br><span></span><br></div></blockquote></div></body></html>= --Apple-Mail-4CA96917-BE69-4EE6-887F-7F593EDA9AD3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E6CEBD98-6DE5-4C58-87C9-FC21D0977699>