Re: [tcpdump-workers] Update configure for libpcap
I was on my phone. I should have been more specific. With ‘ANSI compiler check’ I meant the AC_LBL_FIXINCLUDES m4 macro. I can’t succeed because there isn’t a sys/ioctl.h on win32. AC_PROG_CC_C99, however, works fine with MInGW. > Can automake be used with non-GPLed software? To quote from the docs: “Automake places no restrictions on the distribution of the resulting Makefile.ins. We still encourage software authors to distribute their work under terms like those of the GPL, but doing so is not required to use Automake. Some of the files that can be automatically installed via the --add-missing switch do fall under the GPL. However, these also have a special exception allowing you to distribute them with your package, regardless of the licensing you choose.” https://www.gnu.org/software/automake/manual/automake.html#Distributing > libtool has its own idea of how to name shared library files, so we'd have to > work around that That shouldn’t be a problem. You could link with “-version-info YOUR_OWN_VERSION_STRING_HERE” to hand libtool your preferred version string. You would add that to pcap_la_LDFLAGS in your Makefile.am. From: Guy Harris Sent: Thursday, July 12, 2018 12:23 AM To: Ali Abdulkadir Cc: Petr Vorel; tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] Update configure for libpcap On Jul 11, 2018, at 1:32 PM, Ali Abdulkadir wrote: > Nope. Although it wouldn't be super helpful if they were to remove/update the > ANSI compiler test. That would make libpcap at least *compile* on windows > with the autotools. I think tcpdump's configure script removed that test at > some point. There isn't an "ANSI compiler test". Currently, libpcap *and* tcpdump use the standard autoconf macro AC_PROG_CC_C99, which checks for flags necessary to implement C99 features. We require a subset of C99 features to be available in the compiler, so we *can't* remove that. (Yes, that means older versions of MSVC aren't guaranteed to be able to compile libpcap and can't compile tcpdump. We're not going to change that.) > Linking (shared) is currently not possible though. Fixing that is more > complicated as libpcap's Makefiles are mostly handcrafted (don't use e.g. > automake which would handle OS specific things such as the setting proper > file extensions). Can automake be used with non-GPLed software? (libtool has its own idea of how to name shared library files, so we'd have to work around that "feature" in a platform-dependent fashion, were we to use it.) ___ 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
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] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)
Note, by the way, that, for memory-mapped captures, the Linux kernel appears,
in tpacket_rcv(), to reserve 16 octets of extra space, which is exactly enough
to insert a DLT_LINUX_SLL header, but not enough for a DLT_LINUX_SLL2 header
(and wouldn't even be enough if we *didn't* pad it to put the interface index
on a 4-byte boundary):
if (sk->sk_type == SOCK_DGRAM) {
macoff = netoff = TPACKET_ALIGN(po->tp_hdrlen) + 16 +
po->tp_reserve;
} else {
unsigned int maclen = skb_network_offset(skb);
netoff = TPACKET_ALIGN(po->tp_hdrlen +
(maclen < 16 ? 16 : maclen)) +
po->tp_reserve;
macoff = netoff - maclen;
}
so to support LINKTYPE_LINUX_SLL2 you'd have to add 4 bytes to the tp_reserve
value, which is done with the PACKET_RESERVE, and that's not supported on all
kernels, so, in order to decide whether to support DLT_LINUX_SLL2, you have to
check whether you can do PACKET_RESERVE or not.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
On Jul 11, 2018, at 1:32 PM, Ali Abdulkadir wrote: > Nope. Although it wouldn't be super helpful if they were to remove/update the > ANSI compiler test. That would make libpcap at least *compile* on windows > with the autotools. I think tcpdump's configure script removed that test at > some point. There isn't an "ANSI compiler test". Currently, libpcap *and* tcpdump use the standard autoconf macro AC_PROG_CC_C99, which checks for flags necessary to implement C99 features. We require a subset of C99 features to be available in the compiler, so we *can't* remove that. (Yes, that means older versions of MSVC aren't guaranteed to be able to compile libpcap and can't compile tcpdump. We're not going to change that.) > Linking (shared) is currently not possible though. Fixing that is more > complicated as libpcap's Makefiles are mostly handcrafted (don't use e.g. > automake which would handle OS specific things such as the setting proper > file extensions). Can automake be used with non-GPLed software? (libtool has its own idea of how to name shared library files, so we'd have to work around that "feature" in a platform-dependent fashion, were we to use it.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
> On Jul 11, 2018, at 2:22 PM, Petr Vorel wrote: > > Hi, > > Libpcap's configure script is outdated. > Although I'd prefer remove configure from git and ask user to run autoconf > manually (+ update travis and coverity to run it, of course), That's the first item on their TODO > but maybe you have > some reason for it (problematic autotools instalation on windows?), Nope. Although it wouldn't be super helpful if they were to remove/update the ANSI compiler test. That would make libpcap at least *compile* on windows with the autotools. I think tcpdump's configure script removed that test at some point. Linking (shared) is currently not possible though. Fixing that is more complicated as libpcap's Makefiles are mostly handcrafted (don't use e.g. automake which would handle OS specific things such as the setting proper file extensions). > so I just > update it in this pull request: > https://github.com/the-tcpdump-group/libpcap/pull/730 > > And sorry, you might prefer I include all the info in pull request and don't > write it here. In this case let me know. > > Kind regards, > Petr > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ 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)
On Jul 11, 2018, at 1:14 PM, Denis Ovsienko wrote: > Could the 4-octet field (ifindex) be at the beginning? Yes, but the padding would still be necessary. ___ 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)
On Wed, 11 Jul 2018 19:41:06 +0100 Guy Harris wrote > Currently > > https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html > > has a 2-octet field followed immediately by a 4-octet field. > > This means the 4-octet field isn't aligned on a 4-octet boundary; I'm going > to update the LINKTYPE_LINUX_SLL2 specification to put a 2-byte reserved > field after it. Could the 4-octet field (ifindex) be at the beginning? -- Denis Ovsienko ___ 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)
Currently https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html has a 2-octet field followed immediately by a 4-octet field. This means the 4-octet field isn't aligned on a 4-octet boundary; I'm going to update the LINKTYPE_LINUX_SLL2 specification to put a 2-byte reserved field after it. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
On Jul 11, 2018, at 4:57 AM, Petr Vorel wrote:
> BTW I still wonder for the reason why to version configure.
To quote a comment that used to be in configure.ac:
# XXX - the version is a required argument to AC_INIT and, to quote the
# autoconf documentation, "The arguments of AC_INIT must be static,
# i.e., there should not be any shell computation, quotes, or newlines",
# so we can't get the version from the VERSION file.
so we can't, as indicated, have the configure script get the version argument
to AC_INIT at run time.
The script used to have a place holder that was removed with
commit 263e6ca61e072cd8abe82b58e6b3f6539c2cdaaa
Author: Ali Abdulkadir
Date: Wed Oct 4 04:08:18 2017 +0300
Use a m4 macro to get version string from file
with the place holder inserted in
commit a130d564ba9c9e82dd4ec5afd85f20c1701c7a0a
Author: Guy Harris
Date: Tue Oct 3 13:41:35 2017 -0700
Use a place-holder version in configure.ac, so it doesn't have to
be updated.
And add a comment explaining why, and what we'd have to do if we
decided
to use the real version in AC_INIT(), including updating three files
every time a new version comes out.
after
commit c2e151358d7bc7c77dddb4ca00770034872cd081
Author: Guy Harris
Date: Tue Oct 3 00:16:44 2017 -0700
Don't wire the library name into pcap-config.
With autotools, set the package name with AC_INIT(), which now
takes the
package name and version as arguments, rather than the name of a
file in
the source directory. That sets PACKAGE_NAME.
With CMake, set PACKAGE_NAME to ${LIBRARY_NAME}.
In pcap-config.in, use "-l@PACKAGE_NAME@", rather than -lpcap, as
the
library name.
That means that pcap-config will use -lwpcap, rather than -lpcap, on
Windows, where the library's name is wpcap rather than just pcap.
required it.
Yes, we could, I guess, revert to the old AC_INIT call, and then arrange to set
PACKAGE_NAME and PACKAGE_VERSION elsewhere.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
On Jul 11, 2018, at 4:22 AM, Petr Vorel wrote: > Libpcap's configure script is outdated. > Although I'd prefer remove configure from git and ask user to run autoconf > manually (+ update travis and coverity to run it, of course), but maybe you > have > some reason for it (problematic autotools instalation on windows?), We have CMake support, so, as far as I'm concerned, getting autotools to work on Windows is Somebody Else's Problem, and if Somebody Else cares about it, they can figure out how to make it work (without breaking it on UN*X!) and submit a pull request. I would *personally* prefer that we not have generated configure files in Git and require that autoconf be run (or, if it needs to be run with particular arguments, supply an autopen.sh file and require that it be run); if anybody has an argument against it, let us know. (You can't say "make releasetar" without having run configure, so you can't make a release tarball without having generated configure, so there's nothing special required to ensure that the configure file is provided in the release tarball.) ___ 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)
On Jul 11, 2018, at 7:06 AM, Petr Vorel wrote: > It looks like 1) is impossible the need for both to define > pcap_create_interface(). Currently, the list isn't set in pcap_create(), it's set in pcap_activate(), so it'd be set in pcap_activate_linux(). You would then either 1) have the "cooked mode" read-a-packet code check handle->linktype for DLT_LINUX_SLL or DLT_LINUX_SLL2 and decide based on that whether to use the SLL or SLL2 header or 2) replace the "cooked" member of the private structure with an enum supporting "raw mode", "SLL cooked mode", and "SLL2 cooked mode", and have the read-a-packet code decide how to process a packet based on that. So how is it impossible to implement 1)? ___ 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)
Hi, > > 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. It looks like 1) is impossible the need for both to define pcap_create_interface(). Would it be acceptable implement 2) ? I.e. having LINKTYPE_LINUX_SLL2 as default, but allow to compile LINKTYPE_LINUX_SLL instead of LINKTYPE_LINUX_SLL2. Thanks for comments / ideas / tips. Kind regards, Petr ___ 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)
> [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 JFYI, I remember the beginning of this story from January 2015 well. Paul Evans suggested the original idea and he was going to implement it in code. I did not understand why he specified SLL2 so clearly but didn't implement it, so about a year ago I made an attempt to get some running code along those lines, and I was _not_ successful at that. SLL2 may be one of those problems that are easy to state but difficult to solve, so I would suggest to focus on a working prototype first, then the required props around it can be added as necessary. So far it is a well documented solution that does not exist. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
Hi, > Libpcap's configure script is outdated. > Although I'd prefer remove configure from git and ask user to run autoconf > manually (+ update travis and coverity to run it, of course), but maybe you > have > some reason for it (problematic autotools instalation on windows?), so I just > update it in this pull request: > https://github.com/the-tcpdump-group/libpcap/pull/730 I'm sorry, I used not updated git repository. Closing the ticket, as it has been done: 2b22d207 Update for current VERSION file. BTW I still wonder for the reason why to version configure. Kind regards, Petr ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Update configure for libpcap
Hi, Libpcap's configure script is outdated. Although I'd prefer remove configure from git and ask user to run autoconf manually (+ update travis and coverity to run it, of course), but maybe you have some reason for it (problematic autotools instalation on windows?), so I just update it in this pull request: https://github.com/the-tcpdump-group/libpcap/pull/730 And sorry, you might prefer I include all the info in pull request and don't write it here. In this case let me know. Kind regards, Petr ___ 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)
Hi, > > This requires a numerical value to be assigned to LINKTYPE_LINUX_SLL2 and > > DLT_LINUX_SLL2; no such value has yet been assigned. > It seems it should be 276 (next free number). > I've sent it as a pull request to github (I prefer using git format-patch && > git > send-email to ML as it's kind of archive, but it looks like you're happily > using > pull requests). > https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/11 I also created a pull request in libpcap (as notified by Denis in previous pull request in tcpdump-htdocs): https://github.com/the-tcpdump-group/libpcap/pull/729 Kind regards, Petr ___ 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)
Hi Guy, > (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.) I had some issues with not appearing messages as well :(. > 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. It seems it should be 276 (next free number). I've sent it as a pull request to github (I prefer using git format-patch && git send-email to ML as it's kind of archive, but it looks like you're happily using pull requests). https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/11 > > 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. Make sense. Thanks for clarification. Kind regards, Petr ___ 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 Wed, 11 Jul 2018 06:14:41 +0100 Francois-Xavier Le Bail wrote > 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(). Alright, commit 697b1f7 does that. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
