[tcpdump-workers] Re: capture and inject device capabilities in libpcap
On Nov 18, 2024, at 12:15 PM, Michael Richardson wrote: > Denis Ovsienko wrote: >> One complication here is that in some cases libpcap may not be aware of >> a device capability until it gets an error from the OS (as is the case >> with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findalldevs() >> would not be able to set "this device can capture" and "this device can > > Are there any operating systems can provide this info? More than just operating systems - the DAG card drivers are from Endace, not the OS supplier. > Maybe this becomes an upstream (Kernel) request. I think most platforms support capturing and injecting on all network interfaces (as long as you have permission to open them). ___ 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: Returned mail: Data format error
On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote: > The message about the spam was in fact spam. So what is the purpose of those types of spam? Testing a list's spam detectors? ___ 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: Returned mail: Data format error
--- Begin Message --- On 18/11/2024 21:55, Guy Harris wrote: > On Nov 18, 2024, at 9:08 AM, Michael Richardson wrote: > >> The message about the spam was in fact spam. > > So what is the purpose of those types of spam? Testing a list's spam > detectors? The sender may have sent an infected document as an attachment, as indicated in the message, but list processing has deleted the document. --- 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] Re: Returned mail: Data format error
On 11/18/24 9:08 AM, Michael Richardson wrote: The message about the spam was in fact spam. But, it forged a valid From: so it got through. I'd like to fix the SPF/DKIM/spam-filter such that it more aggressively kills this kind of forgery, assuming that wireshark.org has the right policies set. This kind of thing is fraught with false-positives, but there are some reasonable howtos. wireshark.org should have valid SPF and DKIM records. If the problem is limited to my address, I can subscribe from another one and you can just block my wireshark.org address if that's easier. ___ 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: capture and inject device capabilities in libpcap
Denis Ovsienko wrote: > One complication here is that in some cases libpcap may not be aware of > a device capability until it gets an error from the OS (as is the case > with PCAP_ERROR_CAPTURE_NOTSUP in pcap-linux.c), so pcap_findalldevs() > would not be able to set "this device can capture" and "this device can Are there any operating systems can provide this info? Maybe this becomes an upstream (Kernel) request. > inject" flags reliably. So it seems to make more sense to declare what > would certainly *not* work, such as: > PCAP_IF_NO_CAPTURE -- capture is guaranteed not to work > PCAP_IF_NO_INJECT -- inject is guaranteed not to work Yeah, that sounds reasonable for now. ___ 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: Returned mail: Data format error
The message about the spam was in fact spam. But, it forged a valid From: so it got through. I'd like to fix the SPF/DKIM/spam-filter such that it more aggressively kills this kind of forgery, assuming that wireshark.org has the right policies set. This kind of thing is fraught with false-positives, but there are some reasonable howtos. ___ 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: capture and inject device capabilities in libpcap
On Nov 18, 2024, at 11:54 AM, Denis Ovsienko wrote:
> The current approach in libpcap is such that an application at some
> point tries to activate a device, and if the device does not support
> capturing packets, pcap_activate() fails with the
> PCAP_ERROR_CAPTURE_NOTSUP error code. One drawback of this is that the
> application has no means to tell a capture-capable device without
> trying to activate it, another is that telling an inject-capable device
> takes trying to use the device after pcap_activate() succeeds. It would
> be useful to have a shorter feedback loop for these capabilities.
So "even neither" devices could either not be shown in pcap_findalldevs() or be
shown with both of the "not supported" flags set. One argument for showing it
might be that, if the device isn't shown, a user might have reason to expect it
to be there, and report this as "why isn't device XXX not showing up?", which
doesn't indicate what the problem is, and turns into a question-and-answer
session, whereas if the device is present, the user will see the device,
attempt to capture or inject on it, and get a "{capturing,injecting} traffic
isn't supported on this device" error, and if they report *that*, at least it's
known what the problem is, shortening the Q&A session and getting an answer
more quickly.
> Does it make sense?
Sounds good to me.
___
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
