Re: [tcpdump-workers] about pcap_set_protocol()
On 11/07/2018 04:15, Guy Harris wrote: > On Jul 10, 2018, at 1:31 AM, Denis Ovsienko wrote: > >> I have been looking at the man page for pcap_set_protocol() for some time. >> The man page explains the function is a Linux-specific extension. Would it >> be better to rename the function to something like pcap_set_linux_protocol() >> before it is too late? The function was added to the master branch in June >> 2017 (libpcap pull request #595) and it has not made it into a libpcap >> release yet. > > Or pcap_linux_set_protocol()/pcap_set_protocol_linux(); perhaps in cases > where we add platform-specific functions, put the platform name after pcap_ > or at the end of the name, to have a general pattern (it's too late for some > of the Windows-specific ones, but many of them are either obsolete with > generic replacements, Windows-specific because of inherent UN*X vs. Windows > differences so it's somewhat implied, or no longer supported). I'd rather pcap_set_protocol_linux(), because we already have functions like pcap_activate_linux(), pcap_can_set_rfmon_linux(), pcap_cleanup_linux(), pcap_inject_linux(), pcap_read_linux(), pcap_set_datalink_linux(), pcap_setdirection_linux(), pcap_setfilter_linux(), pcap_stats_linux(). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] about pcap_set_protocol()
On Jul 10, 2018, at 1:31 AM, Denis Ovsienko wrote: > I have been looking at the man page for pcap_set_protocol() for some time. > The man page explains the function is a Linux-specific extension. Would it be > better to rename the function to something like pcap_set_linux_protocol() > before it is too late? The function was added to the master branch in June > 2017 (libpcap pull request #595) and it has not made it into a libpcap > release yet. Or pcap_linux_set_protocol()/pcap_set_protocol_linux(); perhaps in cases where we add platform-specific functions, put the platform name after pcap_ or at the end of the name, to have a general pattern (it's too late for some of the Windows-specific ones, but many of them are either obsolete with generic replacements, Windows-specific because of inherent UN*X vs. Windows differences so it's somewhat implied, or no longer supported). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)
(Re-sending, from my real e-mail address rather than my forwarding-for-life e-mail address, because the latter had issues and required moderation.) On Jul 10, 2018, at 9:34 AM, Petr Vorel wrote: > I'm playing with implementing LINKTYPE_LINUX_SLL2 [1] as a part of [3] > in libpcap and using it in tcpdump. This requires a numerical value to be assigned to LINKTYPE_LINUX_SLL2 and DLT_LINUX_SLL2; no such value has yet been assigned. > 1) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2, compile > both (having one of them as default for linux, second allow to use with -y > switch > in tcpdump). > 2) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2 but > compile only one of them (allow to chose via --with-pcap). > 3) Replace LINKTYPE_LINUX_SLL with LINKTYPE_LINUX_SLL2. > > I've got somehow working 3), but some tcpdump tests are failing and I guess > that's not what would be accepted due backwards compatibility. > I guess 1) is what is wanted, Yes. It allows somebody to produce a capture file that can be read by software that doesn't yet support SLL2. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Packet capture of SSL traffic
(Re-sending from my real e-mail address as opposed to my forwarding-for-life address, as the latter was causing issues and required moderation.) On Jul 5, 2018, at 11:18 AM, Kaushal Shriyan wrote: > Is there a way to run tcpdump to do packet capture on SSL traffic? Yes. Plug the machine running tcpdump into a network on which SSL traffic is being sent, in a fashion that allows it to see that traffic (bearing in mind, for example, that capturing third-party traffic on a switched network may be difficult or impossible), and run tcpdump, with the -w flag, so that it saves the traffic to a file, and either with no filter or with a filter that matches the SSL traffic. If you mean "is there a way to run tcpdump so that it can *dissect* SSL traffic", rather than just being able to put undissected raw packet contents, including SSL packets, into a file to be read by another program, the answer is "no" - tcpdump doesn't currently include the ability to decrypt SSL traffic. (I.e., there's more to being able to analyze traffic than just being able to capture it) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Test mail - no need to reply
On Jul 10, 2018, at 10:08 AM, Guy Harris wrote: > OK, I guess the universe hates "email for life" services, so I'm going to try > giving up on g...@alum.mit.edu for this list. > > Testing to see whether my current direct e-mail address now works. Testing to see whether it still works, having unsubscribed g...@alum.mit.edu. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Test mail - no need to reply
OK, I guess the universe hates "email for life" services, so I'm going to try giving up on g...@alum.mit.edu for this list. Testing to see whether my current direct e-mail address now works. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)
Hi, I've sent my first email into ML yesterday, but it's not in ML. I'm sorry to these who might read it twice. I'm playing with implementing LINKTYPE_LINUX_SLL2 [1] as a part of [3] in libpcap and using it in tcpdump. I wonder what is a correct solution for libpcap: 1) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2, compile both (having one of them as default for linux, second allow to use with -y switch in tcpdump). 2) Keeping LINKTYPE_LINUX_SLL [2] altogether with LINKTYPE_LINUX_SLL2 but compile only one of them (allow to chose via --with-pcap). 3) Replace LINKTYPE_LINUX_SLL with LINKTYPE_LINUX_SLL2. I've got somehow working 3), but some tcpdump tests are failing and I guess that's not what would be accepted due backwards compatibility. I guess 1) is what is wanted, that's what I'm working on. Thank you for your comments / opinions / recommendations. Kind regards, Petr [1] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html [2] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html [3] https://github.com/the-tcpdump-group/libpcap/issues/127 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] about pcap_set_protocol()
Hello list. I have been looking at the man page for pcap_set_protocol() for some time. The man page explains the function is a Linux-specific extension. Would it be better to rename the function to something like pcap_set_linux_protocol() before it is too late? The function was added to the master branch in June 2017 (libpcap pull request #595) and it has not made it into a libpcap release yet. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
