Re: [tcpdump-workers] Libpcap on VMWare

On Jan 12, 2010, at 1:42 PM, Dustin Spicuzza wrote: > AFAIK, using environment variables to change the configuration of an > internal ring buffer is only implemented in Phil Wood's patched libpcap > that you mentioned at http://public.lanl.gov/cpw/. Yes, that's the case. > At some point, someon

Re: [tcpdump-workers] Libpcap on VMWare

On Jan 12, 2010, at 7:05 PM, Dustin Spicuzza wrote: > Yes, that was what I meant. We never tried -1. We're running single > threaded with a select loop for pcap on two devices and some network > communications, so we figured on the off chance that -1 would never > return (which I'm sure it would)

[tcpdump-workers] This is a test - ignore

What if I send a mail message with no newline at the end? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Libpcap on VMWare

On Jan 12, 2010, at 5:59 PM, Mark Bednarczyk wrote: > No drops on NON-vmware platforms. So at least some of the problem could involve a code path difference on VMware, e.g. either the VMware code itself or whatever code in the guest OS receives packets from VMware. Is VMware simulating a hard

Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS

On Jan 14, 2010, at 5:15 PM, David Crowcroft wrote: > Does anyone have an example program in C-language that uses the > pcap_inject() funtion of the libpcap library? I've attached some programs I've written as quick tests. They might or might not compile on your UN*X, or on Windows; you might

Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS

On Jan 14, 2010, at 5:45 PM, David Crowcroft wrote: > It looks like you either forgot to attach the files, or majordomo > stripped them off your e-mail. The latter. > (plese resend them off-list to me, if necessary). Will do. >>> For instance, do I need to calculate the FCS in the Ethernet fr

Re: [tcpdump-workers] Capturing stream protocols

On Jan 15, 2010, at 12:30 AM, Justas Poderys wrote: > //Sorry if this is a duplicate It's not a duplicate, the *other* one is. :-) (So it sounds as if your messages were delivered out-of-order.) > What I am doing is a device for capturing data from Common Channel > Signaling link in E1/T1 sys

Re: [tcpdump-workers] bpf filtering for new DLT type

On Jan 15, 2010, at 8:31 AM, Lidwa, Eric (GSFC-582.0)[SGT INC] wrote: > I am trying to find information on what is needed to implement bpf filtering > for a new DLT type (in my case DLT_AOS). > > Initially I added to gencode.c in libpcap the following: > > case DLT_AOS: >

Re: [tcpdump-workers] New libpcap API

On Jan 15, 2010, at 8:17 AM, Mark Bednarczyk wrote: > I'm the developer of a java libpcap wrapper jNetPcap. jNetPcap API > currently provides comparible libpcap functions for almost everything prior > to libpcap 0.9.8 version. I am planning out additional functions that I > think need to be adde

Re: [tcpdump-workers] forces (and sctp) patch

On Jan 19, 2010, at 5:35 AM, sth...@nethelp.no wrote: > Note that the info about TCP sequence numbers is gone. Fixed in the top-of-tree version: commit 1859a4aac8b7c5b7ab64c9e748fc10100199a98f Author: Guy Harris Date: Sun Mar 1 13:57:53 2009 -0800 From Ilpo Järvinen: fix printing

Re: [tcpdump-workers] [PATCH] Add Myricom SNF API support as a new pcap device.

On Jan 11, 2010, at 8:55 AM, Christian Bell wrote: > From: Christian Bell > > This patch adds support for our NICs when run in a specialized capture mode. > It is diffed against the current master. Checked in, with "Sniffer" replaced by "Myricom Sniffer" in some messages (to disambiguate from

Re: [tcpdump-workers] [PATCH] Fix --with-pcap={linux,bpf} when SNF API is present

Checked in (and pushed, as with the previous checkin). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Release schedule?

On Jan 25, 2010, at 12:57 PM, Ken Bantoft wrote: > I'll finalize the packaging Wednesday for an RC, let everyone test it for a > few days and then pull the trigger on the final release on Monday or Tuesday. Would that be from the top of the trunk for tcpdump/libpcap, or from an already-existin

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Jan 31, 2010, at 1:07 AM, Marco De Angelis wrote: > We have an application that uses libpcap for many Linux versions and for Mac > Os X Leopard with an excellent outcome. When tested on Snow Leopard (10.6.2), > it stopped working. I googled a lot and found out about the BPF issues that > yo

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Jan 31, 2010, at 1:07 AM, Marco De Angelis wrote: > I recompiled tcpdump 4.0.0 on my machine, and it works! On which machine? The Snow Leopard machine? If so, does the tcpdump 4.0.0 that comes with Snow Leopard *not* work? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 1, 2010, at 1:08 AM, Marco De Angelis wrote: > The problem is that the packets are not delivered to the application. More > specifically, > it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop as > well) does > not deliver packets to the pcap_handler. What do you

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 1, 2010, at 8:44 AM, Carter Bullard wrote: > Gentle people, > I also am seeing similar behavior with libpcap-1.0.0 on Snow Leopard (10.6.2). > Seems that this just started very recently, possible with the upgrade to > 10.6.2 > but not sure about that. > > In my application, which uses pc

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 3, 2010, at 5:03 AM, Marco De Angelis wrote: > Guy Harris alum.mit.edu> writes: > >>> it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop >>> as well) does not deliver packets to the pcap_handler. >> >> What do you mean b

Re: [tcpdump-workers] Libpcap on mobile Android platform

On Feb 5, 2010, at 3:36 AM, Mark Bednarczyk wrote: > I found a port of libpcap to Android ( > > http://github.com/android/platform_external_libpcap). Android is linux > underneath but java as the main application API. I am trying to figure out

Re: [tcpdump-workers] output query

On Feb 5, 2010, at 6:41 PM, Liu Feng wrote: > when I use tcpdump to capture wifi signals, this is the result I get: > > 15:47:31.547609 285163963350us tsft 1.0 Mb/s 2437 MHz (0x00a0) -98dB signal > -102dB noise antenna 1 [0x000e] BSSID:00:23:69:29:10:5b > DA:ff:ff:ff:ff:ff:ff SA:00:23:69

Re: [tcpdump-workers] output query

On Feb 6, 2010, at 4:41 PM, Guy Harris wrote: > [0x000e]: > > In theory, that would be an indication that there's a radiotap > "presence bit" that tcpdump doesn't know about, except that 0x000e has 3 > bits set. That's a bit number, no

Re: [tcpdump-workers] [patch] IPv6 RA - RDNSS option

On Feb 1, 2010, at 6:27 AM, David Horn wrote: > I have created a patch to support the RFC 5006 IPv6 RA option 25 > (RDNSS) decoding in tcpdump. The patch (against GIT) is available > here: > > https://sourceforge.net/tracker/?func=detail&aid=2942379&group_id=53066&atid=469575 > > I would appre

Re: [tcpdump-workers] pcap_inject()

On Feb 8, 2010, at 1:33 PM, Frank W. Miller wrote: > I'm trying to use pcap_inject over my 802.11 connection. I can receive > packets using pcap_next() fine and when I call pcap_inject() it returns with > the length of the frame to be transmitted except that no frame is seen over > the air. I h

Re: [tcpdump-workers] pcap_inject()

On Feb 8, 2010, at 2:34 PM, Frank W. Miller wrote: > FWIW, packetspammer does not work either. The current top-of-tree version of packetspammer from git://git.warmcat.com/packetspammer uses pcap_inject(), so it's not *too* surprising that it doesn't work. It is a nice small (and open

Re: [tcpdump-workers] pcap_inject()

On Feb 8, 2010, at 2:33 PM, Frank W. Miller wrote: > Stock FC12. Linux kernel 2.6.31.5-127.fc12.1686.PAE #1 SMP What type of 802.11 adapter are you using? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 9, 2010, at 9:41 AM, Carter Bullard wrote: > Just after the call to pcap_open_live(), I set this ioctl. You may not need > the pcap_setnonblock() for > your application. > > if ((pd = pcap_open_live(device->name, snaplen, !pflag, 100, errbuf)) != > NULL) { That's a sub-second timeou

Re: [tcpdump-workers] pcap_inject()

On Feb 9, 2010, at 10:20 PM, Frank W. Miller wrote: > I'm getting the feeling that pcap_inject() isn't well supported? I guess it's a question of which code we're talking about in the code path to the hardware. pcap_inject() - like the rest of libpcap - is implemented atop an underlying mecha

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 9, 2010, at 2:15 AM, Marco De Angelis wrote: > I made an interesting test. > By collecting pcap_stats() after every call to pcap_dispatch and > printing the pcap_stat values out, I could verify that the packets > are received. > E.g. if I filter for ICMP packets, by launching "ping" com

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 10, 2010, at 1:42 PM, Marco De Angelis wrote: > So the call to pcap_dispatch not preceded by a select() could still > cause problems in 10.6.2? It *shouldn't* cause problems, but, from what you and Carter are reporting, it *does* cause problems. > This is the output on my machine: > >

Re: [tcpdump-workers] BPF filter for tcp syn for ipv6

On Feb 11, 2010, at 1:54 PM, Richard Bejtlich wrote: > In situations like this it is helpful to troubleshoot with the -d option > > http://taosecurity.blogspot.com/2004/12/understanding-tcpdumps-d-option-part-2.html ...and especially note the pointer to the BPF paper, which explains the "machi

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 12, 2010, at 11:02 AM, Marco De Angelis wrote: > Guy Harris alum.mit.edu> writes: > >> Can you cut your application down to the smallest code >> snippet that shows the problem, and send that to me? > > I managed to extrapolate the core. It's a little m

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 12, 2010, at 4:52 PM, Guy Harris wrote: > If it shows up in FreeBSD, I'll look at submitting fixes for it and DragonFly > BSD as well. It shows up in FreeBSD 7.0 as well, as I suspected. I've submitted a FreeBSD bug, kern/143855, and a DragonFly BSD bug. - This is the

Re: [tcpdump-workers] libpcap on Mac Os X 10.6 Snow Leopard

On Feb 15, 2010, at 3:55 PM, Marco De Angelis wrote: > I have set the non-blocking mode to 0, expecting > the call to pcap_dispatch to hang when packets are not > collected. But instead, I can see many printouts (Read 0 packets) > which indicate that the pcap_dispatch has exited when no > packet

Re: [tcpdump-workers] standard pcap-1.0.0 with mmap?

On Feb 22, 2010, at 5:40 PM, d00fy wrote: > Does pcap-1.0.0 use mmap to copy packets from kernel space to user spcace as > default? If it's compiled on 1) a Linux distribution with the right headers to allow it to support memory-mapped capture or 2) a FreeBSD release with me

Re: [tcpdump-workers] [PULL] Mark several structs/variables as const and static

On Feb 20, 2010, at 12:47 AM, Kovarththanan Rajaratnam wrote: > Please pull from: > > git://github.com/krajaratnam/tcpdump.git cleanup Pulled and pushed. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Patch to fix libpcap build on recent FreeBSD

On Mar 1, 2010, at 11:42 AM, Wesley Shields wrote: > Recent changes to FreeBSD broke libpcap building[1]. I've got a patch > which fixes the build[2]. Is there any chance this can be committed? Checked in and pushed, with some changes (for example, "int s" should be inside, not outside, #ifdef

Re: [tcpdump-workers] make releasetar on libpcap

On Mar 5, 2010, at 8:48 AM, Michael Richardson wrote: > Does anyone see a problem if I move bpf_filter.c from CSRC > to GENSRC in the libpcap Makefile? The Makefile has a rule to "generate" it, so I'd see that as OK. (It also means that "make clean" would remove the symlink, which is arguably

Re: [tcpdump-workers] Release schedule?

On Mar 5, 2010, at 9:42 AM, Ken Bantoft wrote: > > On 2010-03-03, at 11:55 PM, Darren Reed wrote: > >> On 19/02/10 10:56 AM, Michael Richardson wrote: >>> "Darren" == Darren Reed writes: >>>Darren> Is there a target date for the delivery of tcpdump 4.1 and >>>Darre

Re: [tcpdump-workers] pcap_next_ex() vs pcap_loop()

On Mar 5, 2010, at 3:56 AM, Selçuk Cevher wrote: > As far as I know, in general, pcap_loop() function of libpcap library is > preferred over pcap_next_ex() function in both live and offline capture. > > Is it related to some kind of fact that pcap_loop() is more > robust/reliable/efficient ? It

Re: [tcpdump-workers] Current wireless-testing breaks libpcap: mr_alen should be set

On Mar 2, 2010, at 5:00 PM, Pavel Roskin wrote: > This patch to libpcap helps: > > --- a/pcap-linux.c > +++ b/pcap-linux.c > @@ -1563,6 +1563,7 @@ live_open_new(pcap_t *handle, const char > memset(&mr, 0, sizeof(mr)); > mr.mr_ifindex = handle->md.ifind

Re: [tcpdump-workers] I have problem with libpcap-0.9.4

On Mar 7, 2010, at 10:59 PM, M.Turner Turner wrote: > I have problem with libpcap-0.9.4. > when i compile (configure and make and make install) libpcap-0.9.4 the .so > files don't create > and only libpcap.a create . > why this happend ? Because tcpdump.org's libpcap, in all of the currently rel

Re: [tcpdump-workers] Release schedule?

On Mar 8, 2010, at 11:50 AM, Gianluca Varenni wrote: > Can we wait until tomorrow for the release? I fixed a minor compilation issue > of tcpdump under Windows As per my earlier mail, it looks as if 4.0.1rc3 wasn't made from the top of the tree; should the final 4.1 release be made from the to

Re: [tcpdump-workers] New DLT type.

On Mar 16, 2010, at 7:34 AM, jon_me...@selinc.com wrote: > What type of information do I need to supply in order to have a new DLT > type assigned? A description of the format of the header at the beginning of the packet (so that we can say "this DLT type is for a header that looks like this;

Re: [tcpdump-workers] When will a packet filter be ignored/unused?

On Mar 17, 2010, at 10:54 AM, Jim Lloyd wrote: > So, what does an error code of -3 indicate? #define PCAP_ERROR_NOT_ACTIVATED-3 /* the capture needs to be activated */ > I've done some experimentation and determined that apparently I must call > pcap_activate before callin

Re: [tcpdump-workers] When will a packet filter be ignored/unused?

On Mar 18, 2010, at 8:02 AM, Jim Lloyd wrote: > Perhaps someone can clarify this point for me. When is filtering done? If the packet capture mechanism supports BPF packet filtering in the kernel (and the filter isn't too complicated to fit in the kernel or otherwise incapable of being handled

Re: [tcpdump-workers] When will a packet filter be ignored/unused?

On Mar 18, 2010, at 8:20 AM, Eloy Paris wrote: > "pcap_create() and pcap_activate() were not available in versions of > libpcap prior to 1.0; if you are writing an application that must work on > versions of libpcap prior to 1.0, either use pcap_open_live() to get a handle > for a live capture

Re: [tcpdump-workers] Release schedule?

On Mar 30, 2010, at 1:55 PM, Wesley Shields wrote: > The links on http://www.tcpdump.org are broken. The tarballs are libpcap-1.1.tar.gz and tcpdump-4.1.tar.gz, rather than libpcap-1.1.0.tar.gz and tcpdump-4.1.0.tar.gz. Are we now calling the major releases 1.x and 4.x rather than 1.x.0 and 4

Re: [tcpdump-workers] Fix print-pflog.c

On Mar 31, 2010, at 9:15 AM, Michael Richardson wrote: > Two questions: > 1) is there anything preventing us from processing pflog > format pcap files on any system (i.e. a header I'm missing > on non-BSD systems)? The fact that the header for packets in a DLT_PFLOG file can be (and

Re: [tcpdump-workers] Fix print-pflog.c

On Mar 31, 2010, at 6:41 AM, Wesley Shields wrote: > Looks like commit e8b523758959c1854689d71c7a4686c631e5501c broke > tcpdump on FreeBSD (and probably any other system with PF). The attached > patch fixes the build. Checked into the main branch and, it appears, into the 4.1 branch - I did, in

Re: [tcpdump-workers] pcap_open_live failing with Illegal instruction error

On Mar 31, 2010, at 12:08 PM, krishna manohar wrote: > I am new to pcap.I am writing a sniffer for s3c2440 arm board. > In the process i have cross compile libpcap 1.0.0 and loaded my executable > on the target. > when i run the sniffer application on target pcap_open_live is failing with > Illeg

Re: [tcpdump-workers] Problem with libpcap

On Mar 31, 2010, at 1:10 PM, Chris Maynard wrote: > I encountered the same problem trying to compile the latest libpcap-1.1 > sources > on a RHEL5 system. Odd - it compiled on my Ubuntu 9.10 virtual machine, with a 2.6.31-19-generic kernel. What kernel does your RHEL5 system have? > I fixed

Re: [tcpdump-workers] Raw USB capturing with libpcap 1.1?

On Apr 1, 2010, at 1:04 PM, Chris Maynard wrote: > I was under the impression that libpcap allowed one to capture raw USB traffic > (See http://wiki.wireshark.org/CaptureSetup/USB). However, with libpcap 1.1, > this doesn't seem to work as I get an error from pcap_compile() with > pcap_geterr(

Re: [tcpdump-workers] Fix ./configure --without-chroot for tcpdump

On Apr 1, 2010, at 10:44 PM, Peter Volkov wrote: > ./configure --without-chroot will configure tcpdump with "no" as the > value of chroot directory and cause tcpdump to fail with: > > tcpdump: Couldn't chroot/chdir to 'no': No such file or directory > > Patch in attachment fixes this issue. Ple

Re: [tcpdump-workers] Release schedule?

On Apr 1, 2010, at 10:24 PM, Peter Volkov wrote: > Hi. It looks like tests directory is missed tcpdump-4.1.0.tar.gz. Do you > suggest to avoid running tests for tcpdump or was tarball corrupted > somehow? The Makefile didn't include the tests in the list of files to distribute. I've changed Ma

Re: [tcpdump-workers] Writing pcap files with fake headers?

On Apr 6, 2010, at 7:54 PM, ronnie sahlberg wrote: > Pcap does not have a raw-udp encapsulation, so yours is a reasonable approach. It does, however, have a raw-IP encapsulation; the link-layer type value in the file header would be 101, and the raw packet data begins with the IP header. A li

Re: [tcpdump-workers] capturing multiple packets

On Apr 7, 2010, at 11:52 PM, Vlabs .C wrote: > i am developing a small sniffer using libpcap API's. I want to capture, > process ARP, IP and TCP packets at a time. Right now I am not able find how > to do it using pcap_compile to capture more than one type of packet at a > time. "arp or

Re: [tcpdump-workers] Request for new DLT and LINKTYPE value

On Apr 12, 2010, at 3:18 PM, Edgar, Thomas wrote: > I am posting to request a value for DLT_SERIAL and LINKTYPE_SERIAL for use > with libpcap. I am working on a project to update libpcap and Wireshark to > capture and parse RS232 and RS485 traffic (written such that it could handle > a wide r

Re: [tcpdump-workers] Request for new DLT and LINKTYPE value

On Apr 13, 2010, at 8:53 AM, Edgar, Thomas wrote: > We are targeting framed protocols over serial, such as the serial versions of > DNP3 and Modbus, Then perhaps the right thing to do is to have *multiple* DLT_/LINKTYPE_ values, one for each protocol, and use the particular protocol's framing

Re: [tcpdump-workers] Request for new DLT and LINKTYPE value

On Apr 13, 2010, at 2:34 PM, Edgar, Thomas wrote: > I am open to the possibility of going forward with that approach. Just to > clarify, does this work by the user preselecting the framing mechanism before > the capture is started? Yes. > For instance, I would have to know that DNP3 is being

Re: [tcpdump-workers] Request for new DLT and LINKTYPE value

On Apr 15, 2010, at 9:59 AM, Edgar, Thomas wrote: > After looking at how the pcap_set_datalink process works I think I have > decided to keep my timing method as the default COM interface datalink type. > But I will create it with the capability of setting the datalink type so that > you can

Re: [tcpdump-workers] [PATCH] libpcap: Add datalink-type to match IEEE 802.15.4 ARP hardware type

On Apr 8, 2010, at 1:25 PM, Luca Bruno wrote: > Since Linux 2.6.30, IEEE 802.15.4 interfaces got assigned a proper > ARP hardware type (ARPHRD_IEEE802154 - 804). > This patch introduces the relevant code to match it with its own > DLT type. > There are currently three different types for it, but

Re: [tcpdump-workers] [PATCH] libpcap: Add datalink-type to match

Subject: [tcpdump-workers] DLT-Value request for IEEE 802.15.4 lrwpan > > Hello > > I would like to request a new DLT value for 802.15.4 Low rate wireless > personal area networks. > I am currently working on an project using 802.15.4 and would like to > use libpcap. >

Re: [tcpdump-workers] deduct local IP address from cap-file

On Apr 30, 2010, at 12:14 AM, Andrej van der Zee wrote: > Is it by any means possible to deduct the local IP address from a > cap-file? With local I mean the IP address that is physically bound to > the machine where tcpdump is ran. If you mean "deduce" - i.e., given a capture file, determine wh

Re: [tcpdump-workers] estimate #packets in pcap file

On Apr 30, 2010, at 5:15 PM, Andrej van der Zee wrote: > I am looking for way to estimate the number of packages in a pcap file > without traversing throu all packages with pcap_loop(). It does noet > have to be precise, just an estimate. Is there a way? *IF* you have an idea what the average pa

Re: [tcpdump-workers] Monotonic clock timestamp on packets

On May 3, 2010, at 11:29 PM, Thomas Habets wrote: > Has anyone looked into timestamping the captured packets using > clock_gettime(CLOCK_MONOTONIC, ...)? > > I'm thinking adding a struct timespec to struct pcap_pkthdr pcap_pkthdr is in a file. You cannot add *ANYTHING* to it without breaking

Re: [tcpdump-workers] Fix build on freebsd-sparc

On May 9, 2010, at 2:11 AM, Peter Volkov wrote: > It was reported that libpcap fails to link on freebsd-sparc: > http://bugs.gentoo.org/show_bug.cgi?id=247076 > > Patch in attachment fixes this issue. Please, apply. Is SPARC the only architecture that requires -fPIC? (On what architectures do

Re: [tcpdump-workers] Fix build on freebsd-sparc

On May 9, 2010, at 2:24 AM, Guy Harris wrote: > > On May 9, 2010, at 2:11 AM, Peter Volkov wrote: > >> It was reported that libpcap fails to link on freebsd-sparc: >> http://bugs.gentoo.org/show_bug.cgi?id=247076 >> >> Patch in attachment fixes this issue.

Re: [tcpdump-workers] libpcap-1.0.0 Makefile improvements

On May 9, 2010, at 6:32 AM, Rafe Yer wrote: > To ensure a successfull re-run of > make install > amend > ln > with > ln -f Do all versions of all UN*Xes that support libpcap also support "ln -f"? If not, the Makefile would need to, instead, do an "rm -f" of the old link and an "ln" to re-creat

Re: [tcpdump-workers] Serial port configuration parameters

On May 13, 2010, at 12:57 PM, Edgar, Thomas wrote: > I have updated libpcap to capture traffic from serial COM ports. However, in > order to do this I needed to configure the serial port settings before > starting the capture. The method I have working is to add the port settings > variables

Re: [tcpdump-workers] [RFC PATCH 0/2]: hw timestamp support

On May 24, 2010, at 7:26 AM, Mcmillan, Scott A wrote: > [My apologies if this double posts. The mail server didn't care for the > first submission.] > > This patch adds the capability to select the packet timestamp source. Is there ever any reason *NOT* to use the hardware timestamp if it's a

Re: [tcpdump-workers] [RFC PATCH 0/2]: hw timestamp support

On May 24, 2010, at 7:26 AM, Mcmillan, Scott A wrote: > This patch adds the capability to select the packet timestamp source. It > also adds support for the PACKET_TIMESTAMP Linux kernel setting to specify > the source of packet timestamps. The corresponding Linux kernel patch is > being sub

Re: [tcpdump-workers] [RFC PATCH 0/2]: hw timestamp support

On May 26, 2010, at 9:03 AM, Mcmillan, Scott A wrote: > Both the 'raw' and 'nic' timestamps are in the form of seconds since the Unix > epoch, plus fractions of a second. Please see my response to Darren for more > info on the difference between these two timestamp sources. Which reply was th

Re: [tcpdump-workers] [RFC PATCH 2/2] tcpdump: hw timestamp support

On May 27, 2010, at 9:48 AM, Mcmillan, Scott A wrote: > This is an updated patch for tcpdump-4.1.1 to add the capability to select hw > timestamps via the -j command line option. The usage has been simplified: -j > now takes no argument, and uses the hw timestamp transformed into the system >

Re: [tcpdump-workers] Fix build on freebsd-sparc

On May 10, 2010, at 12:26 AM, Peter Volkov wrote: > In Gentoo linux (sparc arch too) we do not have such problem. OK, so I've checked into the main and 1.1 branches a change that, for SPARCv9 (sparc64) on FreeBSD, uses -fPIC. Regular FreeBSD appears to use -fPIC on SPARCv9 as well. If anybod

Re: [tcpdump-workers] libpcap-1.0.0 Makefile improvements

On May 9, 2010, at 11:42 AM, Guy Harris wrote: > > On May 9, 2010, at 6:32 AM, Rafe Yer wrote: > >> To ensure a successfull re-run of >> make install >> amend >> ln >> with >> ln -f > > Do all versions of all UN*Xes that support libpcap al

Re: [tcpdump-workers] tcpdump self-tests failed on ppc64

On May 31, 2010, at 6:10 PM, Ondrej Moriš wrote: > there are some issues when running self-tests on ppc64, it seems to be > related to little / big endian - packet checksums are "twisted": > > Example (ikev2fourv.out.diff): > > < 192.168.1.2.500 > 192.168.1.1.500: [bad udp cksum ee7a!] isa

Re: [tcpdump-workers] Raw USB capturing with libpcap 1.1?

On May 6, 2010, at 9:43 AM, Chris Maynard wrote: > I had to put this aside for awhile, but revisited it today. While I did > change > the filter to one of the form "{expr} {relop} {expr}" and was able to > successfully capture packets, the capture filter itself doesn't really seem to > do much

Re: [tcpdump-workers] libpcap USB support: udevinfo not available

On May 11, 2010, at 1:01 AM, Peter Volkov wrote: > Although it's rather trivial to fix udevinfo call I think this check > should not exist at all. It is quite common to build package on one > system and deploy on another,thus it is always bad idea to check system > capabilities during build. I gu

Re: [tcpdump-workers] [PATCH] Small fixes to the tcpdump man page

On Apr 9, 2010, at 12:24 PM, Romain Francoise wrote: > Merge back changes from the Debian package: > - fix TCP flags output description, by Christophe Rhodes > Original patch submitted in http://bugs.debian.org/575724 > - two remaining typo fixes, by A Costa > Original patch submitted in http

Re: [tcpdump-workers] [PATCH] When saving with -U, flush the dump file after opening it

On Apr 9, 2010, at 12:24 PM, Romain Francoise wrote: > Reading from a capture file that has not yet received any packets fails > with "truncated dump file"; to avoid this, flush the file (forcing the > pcap header out) immediately after opening it. Checked into the main and 4.1 branches and push

Re: [tcpdump-workers] Cross-Compiling for iPhone

On Jun 22, 2010, at 8:48 AM, Alan Neville wrote: > I have been trying to cross-compile libpcap-1.1.1 for use on the iPhone > (armv6 architecture) to no avail. Note that, in iOS, the BPF devices are probably owned by root and only openable by root, so you will have to run your program as root, w

Re: [tcpdump-workers] libpcap.so.1 => not found

On Jun 23, 2010, at 3:57 AM, Hemal Shah wrote: > I am trying to run tool on linux. What distribution, and what version of that distribution? > It caught into the error : > "/cbm: error while loading shared libraries: libpcap.so.1: cannot open > shared object file: No such file or dire

Re: [tcpdump-workers] Bug in Pcap Compile?

On Jun 23, 2010, at 5:37 PM, Steve Scott wrote: > When I use this pcap compile string, my gcc compiler builds the executable, > but the pcap compile fails at run time: > > "\\(tcp or udp\\) and \\(src host 172.19.18.2 or src host 172.19.18.3\\)" The backslashes are unnecessary. If I do

Re: [tcpdump-workers] About capture Bluetooth packets

On Jul 2, 2010, at 12:43 PM, nehemiah wrote: > wireshark and tcpdump capture packets from network devices. bluetooth is > more similar to a USB device. ...and both Wireshark and tcpdump can, at least on Linux, capture on both Bluetooth and USB if the machine on which you're capturing has:

Re: [tcpdump-workers] libpcap 1.0 huge packet drop?

On Jul 4, 2010, at 7:15 AM, bored to death wrote: > i'm having quite a problem with tcpdump 4.0.0 Combine the previous sentence and the subject line - at this point, you're comparing libpcap 0.9.8+tcpdump 3.9.8 with libpcap 1.0.0+tcpdump 4.0.0, and the problem could be caused by libpcap 1.0.0,

Re: [tcpdump-workers] DLT for IEEE802.15.4 no FCS frames

On Aug 6, 2010, at 11:47 AM, Jon Smirl wrote: > Can I request a DLT for IEEE802.15.4 no FCS frames. > > The ARPHRD for these frames is already in the Linux kernel: > #define ARPHRD_IEEE802154 804 So that's with a standard 802.15.4 header (as opposed to, say, headers with addresses padd

Re: [tcpdump-workers] DLT for IEEE802.15.4 no FCS frames

On Aug 6, 2010, at 12:04 PM, Jon Smirl wrote: > Not all radios provide access to the FCS internally so it is stripped > in the Linux implementation. That's the only difference from the first > one. so we need another DLT > #define DLT_IEEE_802154 230 OK, I've added DLT_

Re: [tcpdump-workers] DLT for IEEE802.15.4 no FCS frames

On Aug 6, 2010, at 2:34 PM, Jon Smirl wrote: > Thanks for adding the DLT. > > Do I need this bit about LINKTYPE? If you want to be able to read 802.15.4-with-no-FCS captures with applications that use libpcap to read capture files, yes. > diff --git a/pcap-linux.c b/pcap-linux.c > index 70068

Re: [tcpdump-workers] libpcap capture performance drop

On Aug 10, 2010, at 3:35 AM, Doktor Bernd wrote: > I am experiencing the same problem as described in > http://news.gmane.org/find-root.php?message_id=%3c972613.6039.qm%40web59701.mail.ac4.yahoo.com%3e > > I have written a software that captures Ethernet frames and forwards them to > different

Re: [tcpdump-workers] libpcap capture performance drop

On Aug 15, 2010, at 6:15 AM, Doktor Bernd wrote: > thanks for the advice. If I use libpcap 1.1.1 compiled with the > HAVE_PACKET_RING stuff commented out, the my softare performs very well. > Ubuntu currently ships with 1.0.0.6 I think. If I use that version my > application has problems captur

Re: [tcpdump-workers] Extra #ifdef's required for pcap-linux.c

tead? Should we just map all of them to DLT_LINUX_SLL? */ in the cases for ARPHRD_RAWHDLC and ARPHRD_DLCI. The current handling of ARPHRD_DLCI (and ARPHRD_FRAD) comes from a patch submitted by Krzysztof Halasa back in 2003; when I asked him about it, he replied > Guy Harri

Re: [tcpdump-workers] [RFC PATCH 0/2]: hw timestamp support

On May 24, 2010, at 7:26 AM, Mcmillan, Scott A wrote: > This patch adds the capability to select the packet timestamp source. It > also adds support for the PACKET_TIMESTAMP Linux kernel setting to specify > the source of packet timestamps. The corresponding Linux kernel patch is > being sub

Re: [tcpdump-workers] pcap_dispatch on linux 2.6 with libpcap 1.1.1

On Aug 21, 2010, at 3:30 PM, Jim Lloyd wrote: > I have tested with the above logic while sniffing traffic on a GigE ethernet > NIC (eth0) and on the loopback device (lo). The test machine is an 8-core > Opteron with 32Gb of RAM running CentOS 5.5 with kernel 2.6.18. The traffic > generator progra

Re: [tcpdump-workers] pcap_dispatch on linux 2.6 with libpcap 1.1.1

On Aug 22, 2010, at 11:44 PM, Guy Harris wrote: > On Aug 21, 2010, at 3:30 PM, Jim Lloyd wrote: > >> Does this mean the 512Mb memory buffer is huge overkill? > > For this application, it might be. Of course, we must bear in mind that the average human has one breast

Re: [tcpdump-workers] BPF syntax extension for GTP-U (mobile ip packet)

On Aug 17, 2010, at 2:21 AM, Ambika Prasad Tripathy wrote: > I am searching a way how to filter GTP packets and hence mobile IP data over > GTP-U. I can do that by applying index based filter for BPF. But can when I > see struct bpf_insn structure I think, if I modify the gencode.c/h and > gramme

Re: [tcpdump-workers] BPF syntax extension for GTP-U (mobile ip packet)

On Aug 22, 2010, at 10:15 PM, Ambika Prasad Tripathy wrote: > But my proposal is to include a filter like VLAN for GTP. Exactly. See my response to your earlier message, except that: > So after support it the above filter will work like > > "Gtp 23456345" to filter all GTP packets with TEID

Re: [tcpdump-workers] 'bogus savefile header'

On Aug 22, 2010, at 4:15 PM, Aaron Turner wrote: > Long story short, tcpreplay allows users to replay traffic in "verbose > mode" which basically involves forking tcpdump and writing each packet > over a socketpair(). This has worked for quite a while (years now) > but recently I've realized som

Re: [tcpdump-workers] [RFC PATCH 0/2]: hw timestamp support

On Aug 23, 2010, at 12:17 PM, Mcmillan, Scott A wrote: > As I was testing your changes, I noticed some very minor build issues, > resolved by this small patch: Thanks. I've checked your fixes into the trunk and 1.1 branches and pushed them. - This is the tcpdump-workers list. Visit https://co

Re: [tcpdump-workers] pcap_get_selectable_fd q

On Aug 24, 2010, at 5:11 AM, Tim mizas wrote: > What kind of FD does pcap_get_selectable_fd return? It returns either 1) the same FD that pcap_fileno() returns, if select() is supported on it or 2) -1, if select() is *not* supported on it (which is the case in, for example,

Re: [tcpdump-workers] 'bogus savefile header'

On Aug 23, 2010, at 8:30 PM, Aaron Turner wrote: > So building the latest tcpdump from git and it won't link against the > latest libpcap from git: > > ld: warning: in /usr/local/lib/libpcap.dylib, file was built for > unsupported file format which is not the architecture being linked > (i386) >

<    9   10   11   12   13   14   15   16   17   >