-[ Sat, Jan 08, 2011 at 04:42:40PM +0900, Andrej van der Zee ]
> Hi Cedric,
>
>
> > Looks very similar to :
> >
> > http://github.com/securactive/junkie
> >
> >
> Is the intention of junkie to follow TCP streams and reassemble complete
> HTTP requests/responses from the packets? How far is th
I've been using Squeeze libpcap (ie. 1.1.1) to capture some traffic from
a gigabit ethernet adapter today, connected straight to another gigabit
adapter of another host that was sending a pcap file with tcpreplay.
receive buffer was resized up to 60Mb (with proper rmem_max).
And I also experienced
-[ Mon, Feb 07, 2011 at 06:40:40PM +0100, ri...@happyleptic.org ]
> And I also experienced a huge packet drop whenever the throughput raised
> above 50MB/sec (up to 100MB/sec). By huge, I mean almost 50% of total
> received packets (ie. one third of the packets were lost according to
> pcap sta
-[ Wed, Apr 13, 2011 at 10:21:52PM +0900, Andrej van der Zee ]
> It works fine except when
> DCERPC-packets are found in the middle of a data-transfer between an
> HTTP client and server (example of such a DCERPC-packet see below,
> captured with Wireshark).
>
> (...)
>
> [Unreassembled Packet
I see you're using pthreads.
Your malloc may not be thread-safe on the embedded platform?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-[ Fri, May 20, 2011 at 12:02:42PM -0700, Guy Harris ]
> The packet-ring stuff has fixed-length slots, which means that the number of
> slots is the buffer size divided by the size of the slots.
Very interresting information!
Which brings the question: how one could find out the MTU of a
pca
-[ Mon, May 23, 2011 at 12:38:43AM -0700, Guy Harris ]
>
> On May 23, 2011, at 12:31 AM, ri...@happyleptic.org wrote:
>
> > Which brings the question: how one could find out the MTU of a
> > pcap_handle in order no to set caplen to 65535 ?
>
> See pcap-linux.c in the top of the trunk or of t
In defense of the OP, I must say I like the idea of a
pcap_dump_append().
Your arguments against it are a lot more valid with regard to the
tcpdump tool, for which an "--append" parameter seams dubious, than for
the libpcap itself which can be used by many different programs for many
different pur
-[ Wed, Sep 14, 2011 at 09:56:59AM -0700, Rick Jones ]
> What are the issues/benefits/downfalls one way or t'other between the
> two schemes - over ssh and a specific connection - when it comes to
> making certain that this thing forwarding captured traffic isn't simply
> chasing its own tai
If you are willing to do this on a regular basis, the junkie sniffer [1]
(build atop libpcap) can do this with a somewhat complex command line
such as:
junkie -p /usr/local/lib/junkie/writer.so -i phy0 -i phy1 --file capture.pcap
If you are not doing this regularly, and considering you are doing
Hi!
> I was using pthreads for two interfaces, but I am trying to optimize now. I
> have 15% memory usage.
So you were capturing traffic on two threads with two distinct pcap handlers?
Looks fine to me. What's eating 15% of your RAM, exactly?
> I am trying to use select, as it seems the most bas
-[ Sat, Dec 10, 2011 at 12:59:26PM -0800, Guy Harris ]
> > Unfortunately, I don't know any way to
> > associate a file descriptor with a pcap handle portably. :-(
>
> pcap_get_selectable_fd() if present in your libpcap, pcap_fileno() otherwise.
Thank you for the correction.
> > Yes junkie us
I did not remember what select() uses to return the readable file
descriptors, but I do remember that any select can be interrupted
while still waiting, and that the error is then EINTR, so you have
to catch this particular error and ignore it (ie. merely loop on
it).
Googling for "non-restartable
-[ Sun, Dec 11, 2011 at 11:36:14AM -0500, abhinav narain ]
> the return value of error is -1,
> EINTR is 4.
errno is EINTR.
If select returns -1, check for errno. If errno == EINTR, just retry.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
> I captured packets using linux's 'any' interface. At the time of
> capturing, only 'lo' was active. I used 'nc' to generate packets on
> 'lo'.
The "any" device is not an ethernet device, but a virtual thing
that will bring you (at least on Linux) a "Linux Cooked" header
instead of an ethernet he
> I am running on RHEL 6.1 with Selinux disabled.
And AppArmor disabled as well right?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-[ Tue, Feb 14, 2012 at 03:26:21PM +0200, Moshe Matitya ]
> Any ideas as to what may be causing this would be much appreciated.
Calling pcap_loop() after it returned something else than 0 ?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Maybe your device is actually receiving these jumbos and the driver does
not discard them for some reason?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Also, We've seen such strange things happen on some card (broadcom) when
changing the MTU: the internal ring buffer (the one in the card not the one
in libpcap) was not handling dynamic resize properly, and reported batch of
strange things.
What's your network adapter?
-
This is the tcpdump-worker
-[ Thu, May 10, 2012 at 04:43:50PM +0200, Wiener Schnitzel ]
> I need to perform packet sniffing on several interfaces at the same
> time.
> My natural approach would be to open a pcap_t object for each
> interface and place a "select" - considering Linux -call to deal
> with packet dispatching
I'd like to be able to read a pcap in a loop.
There are two options I know of:
- either close the pcap_handle when the pcap_dispatch/pcap_next function
returns the error-code for signaling end of file, and reopen it.
- or retrieve the pcap FILE* with pcap_file(), and rewind by hand (ie. seek
I have a set of pcap files which packets are not stricly ordered according to
packet timestamp.
I'd like a tool to reorder such packets according to timestamp (without
altering packet timestamp
by by swapping packets in the file).
I couldn't find such tool - should I write one or did I missed so
intermixed but not completely random).
[1]: http://github.com/rixed/robinet/blob/master/examples/pcap_reorder.ml
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
> are there any workaround for this? or any other libraries which can capture
> packets destined to a specific local port?
There exist several more involved sniffers (based on libpcap) that do IP
fragmentation reassembly (and often also TCP reordering). They may be more
complex to use that tcpdump
24 matches
Mail list logo
