libpcap, at least as built on a 32-bit, current Gentoo system does not use 64-bit file offsets. This means that in the case (which is relatively common for me) that I find myself capturing more than 2GB of data, or opening a capture file with more than 2GB of data, tcpdump aborts. There is an easy fix, and I'm going to propose it to upstream, but I hoped in the meantime it might make it into a Gentoo ebuild, as currently I'm maintaining my own to fix this problem. Reproducible: Always Steps to Reproduce: 1.Compile libpcap. 0.9.5 is current and displays this problem. 2.Capture more than 2GB of data (or try to open a >2GB capture file) with tcpdump. 3.tcpdump dies. I've been fixing this by modifying the src_compile section to be the following...note that this is likely not the best way (a patch of the Makefile after configure is run, maybe?) and I'm not sure that both LARGEFILE_SOURCE and FILE_OFFSET_BITS=64 need to be defined, but it works at least. src_compile() { econf $(use_enable ipv6) || die "bad configure" cd {$S} sed -i -e '47s/HAVE_CONFIG_H /HAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64/' Makefile emake || die "compile problem"
Here's a better way of doing this, using the largefile USE flag. I don't know if that would be the preferred one, but as I have a bug open for the same thing with wireshark as well (as libpcap large file support doesn't affect it), I figure coordination might be good...that's bug #176251: --- /usr/portage/net-libs/libpcap/libpcap-0.9.5.ebuild 2007-04-22 18:36:12.000000000 -0400 +++ libpcap-0.9.5.ebuild 2007-04-27 10:49:41.000000000 -0400 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/net-libs/libpcap/libpcap-0.9.5.ebuild,v 1.12 2007/04/22 22:14:42 kanaka Exp $ -inherit eutils multilib toolchain-funcs +inherit flag-o-matic eutils multilib toolchain-funcs DESCRIPTION="A system-independent library for user-level network packet capture" HOMEPAGE="http://www.tcpdump.org/" @@ -12,7 +12,7 @@ LICENSE="BSD" SLOT="0" KEYWORDS="~alpha ~amd64 arm ~hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd" -IUSE="ipv6" +IUSE="ipv6 largefile" DEPEND="!virtual/libpcap" PROVIDE="virtual/libpcap" @@ -38,6 +38,12 @@ die "LIBPCAP_PCAP is not set" fi fi + + if use largefile; then + elog "Enabling >2GB file support" + append-flags -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 + fi + econf $(use_enable ipv6) ${MY_OPTS} || die "bad configure" emake || die "compile problem"
a better way is to put AC_SYS_LARGEFILE into configure.{ac|in}
I see this on all 32bit installations even on current installs.
Yeah, sucks, don't it. 2GB isn't that much traffic in these days of gigabit Ethernet connections everywhere.
Created attachment 142115 [details, diff] ebuild patch: adds local useflag "largefiles" and enables libpcap to handle files >2GB This patch enables libpcap to handle files larger than 2 GB. I used Daniels tip from #2 (add AC_SYS_LARGEFILE to configure.in)
Why do we need USE flag for largefile support? Why don't let configure to check and enable it if required? BTW, this was added UPSTREAM: http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/configure.in?r1=1.138.2.4&r2=1.138.2.5
fixed in libpcap-0.9.8-r1
