[tcpdump-workers] Re: upcoming tcpslice 1.8
On Mon, 09 Sep 2024 15:13:49 -0400 Michael Richardson wrote: > Denis Ovsienko wrote: > > Let me suggest making tcpslice 1.8 release in 1-2 weeks to > > avoid yet another oversized change log section. If anyone sees > > a good reason not to, please make your point before long. > > Who are the users of tcpslice? > Are there any heavy users that would like to identify themselves, and > verify the releases? My guess is that tcpslice does not have many users, but from the occasional bug reports is seems some people still use it. Many distributions have a package for it, although many packages are badly outdated. Sometimes I notify one or another package maintainer about a new version, but still in this department it is not uncommon to measure the feedback loop in years. I revived tcpslice in 2020 during a COVID lockdown with the intent to convert some spare time to a few simple bug fixes. In 2021 it turned out to be the best guinea pig for the CI improvements (build matrix etc): it uses libpcap and has a very low build time compared to tcpdump, so in this department the feedback loop can be measured in minutes, not hours. Its purpose since then has been to provide a testing ground for various improvements (e.g. handling of various warnings/errors, man page formatting, posix_fadvise(), static builds, git for releasetar etc) before they are ready to apply to libpcap and tcpdump. So, I am going to make the next release anytime soon. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: [Ext] Re: IP Address Anonymization Feature in tcpdump
--- Begin Message --- On Tue, 03 Sep 2024, Denis Ovsienko wrote: > On Mon, 10 Jun 2024 14:39:01 -0500 > Alberto Perez Bogantes via tcpdump-workers > wrote: > > > We believe that this functionality is well suited for tcpdump because > > much of the logic used to print an IP address for a specific packet > > can be reused to access that IP and anonymize it. The logic for > > dissecting packet headers can be slightly adapted to implement this > > feature, including anonymization of application headers. For example, > > much of the code written to print an IP address offered by DHCP can > > be used to access that address and anonymize it. > > Better late than never. Nik Sultana discussed this feature with me in > April. Whilst trying to explain difficulties of the earlier pull > request 615, I (rather unexpectedly for myself) came to the same point > of view as above. Let me paste a copy of my off-list message to > clarify: [snip] Thank you Denis for the great feedback. We'll try to address those points. In the meantime, we wanted to share a 10-minute video prepared by Alberto to explain and demo this work: http://www.cs.iit.edu/~nsultana1/files/tcpdump-cryptopANT.mp4 Best, Nik -- http://www.cs.iit.edu/~nsultana1 --- End Message --- ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] tcpdump -i - not just for Windows any more!
ubu22-04$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS" ubu22-04$ ifconfig -a ens33: flags=4163 mtu 1500 inet 172.16.135.246 netmask 255.255.255.0 broadcast 172.16.135.255 inet6 fe80::eee8:133e:43dd:472b prefixlen 64 scopeid 0x20 ether 00:0c:29:1c:d8:7f txqueuelen 1000 (Ethernet) RX packets 637 bytes 651687 (651.6 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 544 bytes 80233 (80.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ... wlx0013eff12e78: flags=4099 mtu 1500 ether 00:13:ef:f1:2e:78 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I'm not going to type *that* string as an argument to -i. ens33, OK, but not wlx0013eff12e78. ubu22-04$ tcpdump -D 1.ens33 [Up, Running, Connected] 2.mon0 [Up, Running, Wireless, Associated] 3.any (Pseudo-device that captures on all interfaces) [Up, Running] 4.lo [Up, Running, Loopback] 5.wlx0013eff12e78 [Up, Wireless, Not associated] 6.nflog (Linux netfilter log (NFLOG) interface) [none] 7.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none] 8.dbus-system (D-Bus system bus) [none] 9.dbus-session (D-Bus session bus) [none] tcpdump -i 5, however, not too bad. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Assistance with Capturing cURL Request using tcpdump
Hi, I am using Postman to invoke a REST API call. Is there a way to capture the cURL (https://curl.se/) request (including headers and body) initiated by the Postman REST API client to the application server running RHEL 8.10 OS, and then to the backend server/system using tcpdump and analyze the packet capture (.pcap) file in Wireshark? The flow is as follows: Postman → Application server → Proxy server → Backend server. Headers: Contain metadata about the request, such as content type, user agent, etc. Body: Contains the data that we want to send (if any). Typically used with POST and PUT methods. Please guide me. Thanks in advance. Best Regards, Kaushal ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
