On Wed, 2006-10-11 at 20:03 +0200, Brocha Strous wrote:
> I have 2 different implementations. The problem is only with a very
> small number of users so its not server-wide. Possibly related to a
> specific firm-ware version of a Zyxel router - are there any known
> in-compatibility between pcap an
On Thu, 2006-02-16 at 12:42 -0800, Guy Harris wrote:
>
> Require read and write access for appending, open for reading and
> writing, read the header, make sure the link-layer type and snapshot
> length are the same (and fail if they're not), and then seek to the
> end and start writing.
And
There's also the possibility of the SE Linux default configuration
shipped with FC4 causing trouble. Try disabling it and see if the error
persists?
Cheers,
Christian.
--
http://www.
Hi Evan,
if Guy's points aren't a concern for you, you can just use libpcapnav.
It provides pcapnav_get_offset() which does what you want.
http://netdude.sourceforge.net/doco/libpcapnav/index.html
Cheers,
Christian.
--
Hi there,
I'm not sure if it's the cause of the problem but you definitely need to
copy out the values passed into packet_handler instead of assigning the
pointers. You can just assign the pcap_pkthdr; in order to copy the
packet data, obtain the caplen from the header, allocate a chunk of
memory
Hi Ronnie,
On Sat, 2005-06-25 at 20:48 -0400, ronnie sahlberg wrote:
>
> I often work with very very large capture files and often want to only
> extract a very small subset (packets captured between time X and time
> Y).
> This is very very slow with the current fileformats doe to the massive
> a
Hi Loris,
On Fri, 2005-06-03 at 10:10 -0700, Loris Degioanni wrote:
> Guy,
>
> Guy Harris wrote:
> >
> > However, it sounds as if that only applies if the DLL is using a
> > different version, or different instance, of the C runtime:
>
> Yes, but this doesn't solve the problem. You just cannot
On Wed, 2005-04-27 at 11:04 +, soumya r wrote:
> Hello,
> I am doing a sniffer program using "libpcap" as part of my project. How can
> I display the 'packet payload' in 'HEX' and 'ASCII' forms? Please advice.
Just look how tcpdump does it (print-ascii.c), or how I did it in the
hex/ascii wi
On Wed, 2004-06-30 at 12:50, Michael Richardson wrote:
> -BEGIN PGP SIGNED MESSAGE-
>
>
> >>>>> "Christian" == Christian Kreibich <[EMAIL PROTECTED]> writes:
> Christian> proposal that while I personally think an XML capture
> C
Hi,
On Fri, 2004-06-25 at 02:04, Hannes Gredler wrote:
>
> i am a believer that networking dissectors should print data in the order
> they arrive ... header information comes before ip adresses, right ?
> the IMHO bad bad practise of printing header information (old format)
> at the end of the pa
Hi,
On Wed, 2004-04-28 at 13:59, ice ice wrote:
> Hi,
> I have been using tcpdump analyzing trace files. Recently I try to analyze
> some big trace files of several hundreds Mbs to more than 2GB. I am not sure
> why the tcpdump is so slow in processing the file, just a simple command:
> tcpdump
On Wed, 2004-04-21 at 17:09, Christian Kreibich wrote:
> pretty much harmless -- you'll just lose that incomplete last byte in
That should have been "packet"
Hi,
in the pcap file format, each packet is prefixed by a little header
structure that tells pcap details about the following packet.
"truncated dump file" means that at the end of the trace, there's a pcap
packet header that states that a packet of a size follows that actually
is not fully conta
On Wed, 2004-04-14 at 00:06, Jefferson Ogata wrote:
>
> I'm suggesting the pcap storage format be XML. A raw capture, without using
> protocol dissectors, would just be a sequence of base64-encoded (perhaps) frames
> and metadata.
But once you're using raw base64-encoded (or whatever), you're lo
On Tue, 2004-04-13 at 16:09, Jefferson Ogata wrote:
>
> Something keeps bugging me, and I just want to throw it out there for
> the mad dogs to tear into little bloody pieces:
>
> Given all the desirable options people are looking for in this, and the
> need for future growth, I think we should
[I've tried to get this to the list about four times now and it always
came back with a different reason -- I hope this one will make it to
the new list. Thanks.]
On Wed, 2004-03-24 at 03:31, Jefferson Ogata wrote:
> Michael Richardson wrote:
> > This is what I would propose as revision.
> > Note
16 matches
Mail list logo
