Re: [tcpdump-workers] libpcap1.1.1 truncates UDP payload, ring buffer problem?
On Jun 1, 2011, at 5:58 AM, mold2010 wrote: > I tried libpcap1.1.1 release libpcap_1_1rel0 from > https://github.com/mcr/libpcap. But found the same issue. Where can I get the > 1.2 branch? Is it git hub: libpcap? Both the 1.2 branch and the trunk can be found on bpf.tcpdump.org, and probably on github as well: http://www.tcpdump.org/#source - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] ifSpeed in sFlow is 64 bits not 32
On May 27, 2011, at 5:59 PM, Rick Jones wrote: > The ifSpeed field of a generic interface counter in sFlow is 64 bits. > The "overlay" definition in print-sflow.c is correct, but the actual > extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS, > which leads to an incorrect report for speed. Checked into the trunk and 4.2 branches (with a fix to the format string to use PRIu64). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] ifSpeed in sFlow is 64 bits not 32
On Thu, 2011-06-02 at 10:57 -0700, Guy Harris wrote: > On May 27, 2011, at 5:59 PM, Rick Jones wrote: > > > The ifSpeed field of a generic interface counter in sFlow is 64 bits. > > The "overlay" definition in print-sflow.c is correct, but the actual > > extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS, > > which leads to an incorrect report for speed. > > Checked into the trunk and 4.2 branches Excellent. > (with a fix to the format string to use PRIu64). Oops - I keep forgetting that all my compiles are 64 bit and so don't remember to check for such things. rick > - > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] ifSpeed in sFlow is 64 bits not 32
On Jun 2, 2011, at 11:10 AM, Rick Jones wrote: > Oops - I keep forgetting that all my compiles are 64 bit and so don't > remember to check for such things. You need an OS and build tools that make it easier to build stuff both ways (and on which recent versions of libpcap and tcpdump default to building it multiple ways). The OS is expensive, but it does come bundled with a computer. :-)- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On Wed, Jun 1, 2011 at 9:24 AM, Gerald Combs wrote: > On 6/1/11 8:10 AM, Mark Johnston wrote: >> Hi Darren, >> >> On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote: >> >>> You might be better off spending some time working >>> on additions to editcap that include concatenating >>> two or more pcap files. >> >> Shouldn't a function that manipulates capture files go into libpcap? I'm >> not trying to solve a problem I'm having at the moment; rather, this >> function has been in our tree for a long time, and I'd like to >> contribute it upstream based on some interest that I saw. I'm happy to >> modify it if that's what I need to do, but I think this functionality >> should be in a library, not in a program. > > N.B. this functionality shouldn't be added to editcap either. It's > already present in mergecap. I'm going to have to disagree with this general idea. I get a fair number of tcpreplay users complaining that my tools have bugs, only to find out the problem is that they have a pcap file which violates basic rules that libpcap enforces (usually the packet caplen > file snaplen, although just today I got a pcap with the packet caplen > packet len). Whenever this happens, I've usually found that someone decided they would re-invent the wheel and write their own libpcap-like library because of some perceived or real limitation in the real libpcap library. Of course, the user almost always points out "Well it looks just fine in Wireshark!" Long story short, adding features like this to libpcap IMHO is likely to reduce the need for others to reinvent the wheel and the inevitable creation of bogus pcaps. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero" - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
