Evan Hughes wrote:
I can do some timings on the cost of the fgetpos(), but I don't
have a large number of platforms available to test on, just debian
boxes and windows machines.
I could test on Solaris 7, assorted versions of Debian, assorted
versions of FreeBSD, and OS X 10.3.9 and 10.4.3
Evan Hughes wrote:
I'm confused. ftell() took a long time because of the fseek()?
No, ftell() took a long time because of the *l*seek(). (V6 UNIX had a
"tell()" system call, along with "seek()"; V7 replaced both with "lseek()".)
I agree. I like this idea the most, as it allows us to
On Nov 22, 2005, at 8:18 PM, Latha G wrote:
But the format of the header information obtained by [-e] option
and that
obtained by [-e -xx] option looks same.
If by "the header information" you mean the
09:39:55.889089 00:0d:60:08:29:ed > Broadcast, ethertype ARP (0x0806),
length
richard wrote:
I am using tcpdump version 3.8.3, with libpcap 0.8.3. This has
worked for me on various versions of solaris, aix, and linux,
but crashes when I use it in Fedora Linux
version 2.6.13-1.1532_FC4smp.
Perhaps there's a compiler bug in FC4. Libpcap isn't crashing on other
platforms
David Rosal wrote:
Yes it does. Thanks.
But a question arises: If my network card is stripping the FCS (and it
seems to do so), may I suppose that this is done for all packets?
On that particular adapter, yes.
You can't suppose that it's done on all adapters on all platforms,
however; in pa
Evan Hughes wrote:
Regarding return values: I'll make the changes that you suggested.
I'm using -3 to indicate that a stream [can't be seeked on]. Would it be
acceptable to create a define for that value? It's a pain to memorize
those negative values...
Yes, #defines for the various return
Latha G wrote:
Hi all,
Can any one explain me about the outputs of tcpdump -xx and -XX options.
The outputs for these options looks like:
tcpdump -xx:
15:56:04.440349 arp who-has 172.16.38.3 tell 172.16.16.110
0x: 0003 4724 f364 0806 0001 G$.d
0x0
dalmasso cedric wrote:
I use Linux Mandriva 2006 and as I describe in subject with tcpdump
50% of received packet are missing! I provide many test and it's also
the same I capture 1/2 of received packets.
...
923 packets captured
1846 packets received by filter
There's a bug in lib
Guy Harris wrote:
What happens if you compile libpcap with GCC's optimizer turned off? I
suspect this is a bug in the version of GCC in FC4.
And it appears there *is* a bug in the GCC 4.0 in FC4; Google for
fc4 compiler bug gcc libvgahw
for some reports of it. You might wa
Guy Harris wrote:
I'd advise you to talk to the Fedora team about this, and mention that
this stuff *doesn't* crash on any other platform.
...and that there is already one known FC4 compiler bug - Google for
fc4 compiler bug gcc libvgahw
for some reports of it. That bug
Nicolao Renè wrote:
Hello, I'm using libpcap 0.8 on FreeBSD 5.4, is it possible in some way
to reset the pcap stats?
If you mean "in an application using libpcap, which calls pcap_stats()
before it stops capturing, is there any way to reset the statistics
counters to 0, so that subsequent cal
I don't know whether anonymous CVS is working now, but the snapshots
seem to be up-to-date again.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
I don't know whether anonymous CVS is working now
I'm able to check out via anonymous CVS on my machine; your mileage may
vary depending on firewalls/reverse DNS entries for your machine/etc..
-
This is the tcpdump-workers list.
Visit https://lists.sandel
On Nov 29, 2005, at 3:04 PM, Antoine Tremblay wrote:
I have a problem with pcap_dispatch
I wish to use it in blocking mode , in a thread, but the problem is
that
when there is no data to sniff it will block forever in pcap_dispatch
Even with a timeout set in open_live ,
To quote the man p
On Dec 3, 2005, at 8:51 AM, Gisle Vanem wrote:
The print-dccp.c file is rather gcc centric in the way it uses
declarations after code statements. E.g.:
TCHECK2(*dh_ack,8);
u_int32_t ack_low = dh_ack->dccph_ack_nr_low;
Which doesn't work in MSVC7.
The attached patch also removes the dccp_
(Blah blah blah wrong from address blah blah blah defeat duplicate
message detection blah blah blah blah.)
On Dec 3, 2005, at 8:07 AM, Gisle Vanem wrote:
The recent (?) -G option requires gettimeofday() which isn't
available on Win32. Attached is a patch to util.c which adds this
function.
(Sent from the wrong address, so it bounced; resent from the right
address, with extra crud added so that it doesn't get bounced again
as a duplicate message.)
On Dec 4, 2005, at 8:37 PM, BinaryChen(TP/SH) wrote:
I have captured some raw PPP data from serial driver, and I want
use libpcap
On Dec 5, 2005, at 6:55 PM, BinaryChen(TP/SH) wrote:
It is framed with escape characters.
I.e., there are flag bytes (0x7e) at the beginning and end of each
frame, and bytes with the values 0x7e and 0x7d are represented as
0x7d 0x5e and 0x7d 0x5d in the byte stream?
If so, then, yes, PP
On Dec 7, 2005, at 5:37 PM, Rebekah Taylor wrote:
However tcpdump has fallen over a few times with either of the
follwing
errors
tcpdump: read: A memory address is not in the address
space
for the process
tcpdump: read: Bad address
Do you know what causes this fa
Rebekah Taylor wrote:
I have attached the output of the config and make runs
Do I need some prerequisite libraries or something?
It appears that Bison isn't correctly installed on your machine -
configure finds it:
checking for bison... bison
and it is, in fact, present, but one of its d
Hannes Gredler wrote:
found the openBSD tcpdump tree meanwhile ...
have added the desired functionality to HEAD.
Do we want relative time stamps (-ttt, for secs/usecs since previous
packet, and -t, for secs/usecs since first packet) to be printed as
HH:MM:SS.UU, or seconds.UU?
On Dec 13, 2005, at 6:05 AM, Hannes Gredler wrote:
Guy Harris wrote:
Do we want relative time stamps (-ttt, for secs/usecs since
previous packet, and -t, for secs/usecs since first packet) to
be printed as HH:MM:SS.UU, or seconds.UU?
in the sense of having an indicator wether
(I'm on tcpdump-workers, so you don't need to CC me - just ask
tcpdump-workers questions such as this.)
Amitesh Singh wrote:
what should be the string to pass a filter program in
pcap_setfilter() to capture only ACK packets.?
Do you mean "ACK-only" TCP packets, i.e. TCP segments that have
Amitesh Singh wrote:
what should be the string to pass a filter program in
pcap_setfilter() to capture only ACK packets.?
BTW, you don't pass a string to pcap_setfilter(); you pass a string to
pcap_compile() and pass the filter you get from pcap_compile() - *IF* it
succeeds - to pcap_setfi
On Dec 14, 2005, at 1:27 PM, Alexander Dupuy wrote:
Is there a compelling reason why this returns a long, rather than
an off_t (ftello style)?
Googling for
off_t site:microsoft.com
found
http://msdn2.microsoft.com/en-us/library/323b6b3k.aspx
which appears to claim that "S
Alexander Dupuy wrote:
The configure.in code that checks for SSLeay stuff can end up putting
multiple copies of -I include directives in the compiler flags (once in
CPPFLAGS, and again in V_INCLS)
So CPPFLAGS is used only to set the Makefile variable DEFS, and the
Makefile variable DEFS is us
Guy Harris wrote:
Makefile variables DEFS, set only from V_DEFS (the configure
variable DEFS doesn't appear to be set at all),
It's a Special Magical Variable:
http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/autoconf.html#SEC23
so we'd k
Scott Stoddard wrote:
Hi all, I hope this is the right place to post this but I could not find
a users tcpdump list.
This is the only list we have - it's for users and developers of tcpdump
and libpcap.
I am trying to capture traffic between two hosts
at a point where the traffic is encapsu
Sven Ubik wrote:
But I have a problem to get IPv6 packets with this version of
libpcap or tcpdump (I don't know where is the problem), it reports:
# tcpdump -n -vvv mpls and ip6
tcpdump: ip6 not supported
By default, the configure scripts for libpcap and tcpdump don't enable
IPv6 filters (in
Jason Duan wrote:
When I ran "tcpdump -r tcpdump.log", the output is more or less
"human readable" but it is not so good for machine reading (for
example extracting packet size etc). I am not sure if I am missing
something in the command line or tcpdump does not print in machine
readable form
On Jan 5, 2006, at 12:30 AM, zze-DALMASSO Cedric RD-BIZZ-SOP wrote:
I look for a means to make a capture at long time. But it's
impossible since the file's size grow up.
Do you know a means to cut it by duration, for example each hour a
new file (it's simpler to use file with duration cut ra
Daniele Orlandi wrote:
I have a small patch which would complete support for vISDN capturing,
however, netdev's people doesn't want to allocate an ARPHRD_ constant unless
vISDN is integrated into mainline kernel (to avoid pollution) and I don't
plan to propose vISDN for integration in the sho
On Jan 9, 2006, at 9:12 AM, alexander medvedev wrote:
As far as i understood NTAR is an implementation of the pcap-ng
standard,
At least as I understand it, it's an implementation of *part* of that
standard - it handles the general structure of pcap-ng files (the
"general block structure
Gianluca Varenni wrote:
- Original Message - From: "Guy Harris" <[EMAIL PROTECTED]>
To:
Sent: Monday, January 09, 2006 12:09 PM
Subject: Re: [tcpdump-workers] where to get libpcap-ng?
...
At least as I understand it, it's an implementation of *part* o
On Jan 12, 2006, at 3:29 PM, Gianluca Varenni wrote:
BUT..is pcap library able to manage safety multi
process (or maybe multi thread) calls with the same
pcap_t handle in each process ?
No. The pcap_t handle is not guaranteed to be thread-safe.
Specifically, every packet returned by pcap_ne
On Jan 12, 2006, at 5:03 PM, Michael Richardson wrote:
You could perhaps, do just load the filter and fork.
You'd be sharing the same file descriptor, and if your kernel
returns one-packet-per-read (some mmap'ed interfaces do not!),
Some non-mmapped interfaces don't, either, e.g. BPF on v
On Jan 12, 2006, at 3:11 PM, computational_complex-
[EMAIL PROTECTED] wrote:
- every process executes an infinite loop in which
pcap_next() is called.
- every process executes a pcap_loop() call.
So does each process execute a pcap_open_live() call?
Or do you do that in the main process an
On Jan 13, 2006, at 6:37 PM, SPYRIDON PAPADOPOULOS wrote:
i am creating a packet capture tool on a FreeBSD 5.4 - RELEASE for
my dissertation using pcap. I am using the system headers in /usr/
include/net/ and /usr/include/netinet/ directories to start
decoding EN10MB, ip, tcp, udp, icmp etc
On Jan 16, 2006, at 1:33 AM, Latha G wrote:
I had given "tcpdump -c 1 -s 40 > file", after that i checked the
file
size using "ls -l file",
what i got the file size is some 83 bytes.
There are several issues here.
For one thing, as you didn't use the "-w" option:
tcpdump -c 1 -s
Mikhail Manuylov wrote:
All I wonder is why tcpdump still hasn't any binary dump append feature.
Because nobody who needed that capability wrote code to implement it and
contributed it to tcpdump-workers?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Feb 16, 2006, at 12:06 PM, Stephen Donnelly wrote:
The biggest problem I imagine is that the resulting file would have
only
one header block, so the configuration of the capture for the appended
records would have to be the same as for the original file.
I'm not sure how you could check f
Latha G wrote:
I am using tcpdump. As I want to capture the tcpdump output ,
I am usingtcpdump -c 1 > filedump
It is finely working.
But unfortunately now it is not working. Even -w option also not working.
I mean the expected ouput file doesn't contains the output, it was just
empt
Andrea Bittau wrote:
The DCCP service code is a u32 in network byte order. The current DCCP code
does not call htonl() or equivalent.
Fix attached.
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Latha G wrote:
Please any one help me to understand the tcpdump -T option..
Actually why is this necessary to interpret one packet to be of other type,
Because, for TCP segments and UDP datagrams, tcpdump bases its decision
of which protocol's running atop the transport protocol on the TCP or
J.O. Leger wrote:
If I have an application that opens two packet capturing sessions(ie
eth0 and eth1) using the ring buffer version of libpcap, does libpcap
create two separate ring buffers?
If by "the ring buffer version of libpcap" you mean Luca Deri's:
http://luca.ntop.org/
ring b
kashif javed wrote:
As pointed out by Richard Stevens in the chapter 26 of
his book " UNIX Network Programming vol1: 2nd
edition", pcap supports packets while reading. I want to
ask is there any way to write datalink packets?
Libpcap 0.9.x has pcap_inject() and pcap_sendpacket() to send packet
Hannes Gredler wrote:
pls try a "make clean;make" - /hannes
Or even try "make distclean; configure; make".
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
PRITHU wrote:
I was trying to install tcpdump 3.8.3 in freeBSD
5.4,
The current version is 3.9.4; you might try that instead.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
rmkml wrote:
Hi Guy,
sorry for direct post,
Im use tcpdump394 (and previous version)
Im found icmp echo request but this is not code 0
possible add warn on tcpdump if echo request but not code 0 ?
There are probably other "should be zero" fields that tcpdump doesn't
check as well. Is this one a
On Feb 21, 2006, at 6:42 PM, axi wrote:
When tcpdump receives a packet with prism headers recognized as above
:
" listening on ath0, link-type PRISM_HEADER (802.11 plus Prism
header),
capture size 96 bytes"
always prints "[|802.11]", with data, control or administration
packets. The
size
David Young wrote:
In principle, the radiotap header length is variable, but in practice, it
is virtually always 64 bytes; this is an accomodation for libpcap/tcpdump,
which historically could not handle variable-length headers. (I haven't
been paying close attention to notice whether libpcap/t
Alexander Dupuy wrote:
The crux of the problem is that the line with
*stats = handle->md.stat;
was replaced with
stats->ps_recv = handle->md.packets_read;
stats->ps_drop = 0;
...rather than being executed, followed by a "return 0;", if we succeed
in getting the statistics from
Latha G wrote:
And one more thing, we are using tcpdump -w dump.pcap
means the whole raw packet will be stored or only 96 bytes(default) of the
packet will be stored in dump.pcap??
It means that all the captured bytes will be stored - but, as no "-s"
flag was given, the limit on the per-packe
Latha G wrote:
what is the reason for this behaviour?
The reason is that somebody decided to make one of the checking for
snapshot truncation report "truncated-arp" rather than the usual
"[|arp]". I don't know why they decided to do that; "truncated-ip", for
example, is printed if the leng
Latha G wrote:
Can we simultaneously run tcpdump many times...
I mean, I opened two terminals, Is it possible to run tcpdump on both these
terminlas simultaneously?
Yes.
And if it so, is both the outputs same?
Yes, unless, for example, a particular packet or packets are dropped by
one ins
Latha G wrote:
The purpose of tcpdump -q option is given as Print less protocol
information so output lines are shorter.
Less protocol Information means how much less?
It depends on the protocol.
For example, for TCP, without "-q", tcpdump 3.8.3 prints
12:05:11.208835 IP client.60784 > s
Latha G wrote:
Is this behaviour depends on the tcpdump version or on the underlying
operating system..?
The tcpdump version; later versions will print out "IP" or "IP6"
(presumably so that, on a network with a mixture of IPv4 and IPv6
traffic, you can tell whether a given TCP segment was se
Gisle Vanem wrote:
This file is needed by print-bgp.c, print-ldp.c and print-rip.c, but
missing
from the tar-ball. Should it be generated by configure?
No - it, and af.c, should probably be generated from the stuff removed
from print-bgp.c.
I've checked in versions of af.c and af.h generate
Luis Del Pino wrote:
When I capture an UDP datagram from a well-known source, Could the checksum
be incorrect?
Yes, if the packet was corrupted. (I assume you're capturing with libpcap.)
do I have to calculate it?
If you want to check whether the packet was corrupted, yes. See
tcpdump's
On Mar 16, 2006, at 3:32 PM, J S wrote:
I am trying to setup active tcp probing b/w two nodes, however I am
facing
difficulty in setting up tcpdump filter. I would like to capture
the tcp
data packets which I am generating.
when I use this filter
'tcpdump src host SRC and dst host DST and
Luis Del Pino wrote:
> What function do I have to use to convert a struct timeval (struct
> pcap_pkthdr {struct timeval ts;...}) to timestamp units(u_int32)?
>
> i like calculating jitter in RTP streams.
So by "timestamp units" do you mean IP/TCP time stamp units (which,
according to RFC 791, are
On Mar 21, 2006, at 2:21 PM, J S wrote:
But is it possible to collect info for all the required packets and
then
distinguish them based on their sender/reciever inside my pcap
program (in
one process)?
Yes.
Does pcap header contains information about sender/reciever or is it
possible to
On Mar 24, 2006, at 1:35 PM, Don Morrison wrote:
My apologies, what I said was incorrect. Running the command does not
crash tcpdump, but the outputfile ("clean.pcap") will crash Ethereal,
so while both files are clean enough for tcpdump to display and not
crash, not so for Ethereal.
That do
Harley Stenzel wrote:
However, on HP-UX, that same call returns rc 0.
I was not able to find a pre-existing bug for this
problem, however I was able to find this message:
http://www.tcpdump.org/lists/workers/2004/03/msg00103.html
indicating that at least in 2004, HP-UX send would not
work
On Apr 4, 2006, at 8:51 AM, Harley Stenzel wrote:
On 4/3/06, Rick Jones <[EMAIL PROTECTED]> wrote:
I believe this is a long-standing limitation of promiscuous mode
support
in HP-UX - only one process may have a promiscuous stream open on an
interface at one time. I believe that is the cas
(blah blah blah original reply sent from the wrong address blah blah
blah text to fool the duplicate message detector blah blah blah blah).
On Apr 3, 2006, at 6:20 AM, David Rosal wrote:
It would help if that would be any way to close the old file
asynchronously, but I guess that pcap_dump_c
kashif wrote:
I have configured my PC running RedHat Linux 9.0 into a router by
turning on the ip_forwarding facility of it. It got TWO LAN cards...and if i
run two instances of *pcap* one for each LAN card for capturing
packets, it works fineBut i intend writing an application wherein
i nee
On Apr 6, 2006, at 2:22 PM, J S wrote:
I am developing an active monitoring system, which implements pcap
filter.
What do you mean by "implements pcap filter"?
The requirement is to send probes with a high monitoring rate e.g.
40 msec
and the probe packets have data of 12 bytes. For each
Hannes Gredler wrote:
checked in - thanks for the submission - /hannes
On Wed, Jan 19, 2005 at 05:35:13PM -0800, Rick Jones wrote:
| A while back I think I posted something asking about what to do about TSO
| (large send) and how it generated "IP bad-len 0" output when tracing on a
| TSO-enab
Hannes Gredler wrote:
you may want to check the text2pcap utility
that comes along with ethereal for learning about
conversion to a libpcap readable format.
Or, alternatively, with newer versions of libpcap (those with
pcap_open_dead(), so you can write to a libpcap file without having a
lib
On Apr 7, 2006, at 10:08 AM, Rick Jones wrote:
As for checking against the normal MTU, does tcpdump/libpcap have
that information?
Only to the extent that it could infer that from the link-layer
type. (Jumbo frames might make that tricky.)
Does libpcap/tcpdump have any way of knowing th
On Apr 24, 2006, at 3:23 AM, Sumit wrote:
printf("packet time/caplen/len %u %u %u\n", header-
>ts, header->caplen, header->len);
You can't do that. "header->ts" is a structure, and you can't print
a structure with "%u". What that statement actually does is
implementation
On Apr 24, 2006, at 3:23 AM, Sumit wrote:
Main difference is extra 2 bytes at the first of pcaket. Also there
is not having proper destination H/W Addr; i.e. my machine's MAC,
in starting bytes of packet. Do I need to set something or call
some pcap routines?
One thing you need to do, if
On Apr 24, 2006, at 10:37 PM, Sumit wrote:
I submitted libpcap-0.9.4-1.i386.rpm but no-one care about it. Can
you tell me if maintainer interested on that part? I got a auto
reply about size of mail. Please send me some personal address to
send it to.
To whom did you submit it? And wha
On Apr 24, 2006, at 10:44 PM, [EMAIL PROTECTED] wrote:
So I want to add support for unix socket to Pcap library. As pcap uses
DLT_xxx for identifying the type of interface and Linux uses the ARP
hardware type.
In case of unix socket what value should be given, is there any value
already defined
On Apr 28, 2006, at 2:12 PM, Cove Schneider wrote:
As far as I can tell fwrite() will occasionally write short. I'm
assuming because my pipe is "backed up" and libpcap can't write
anymore data to it (though I would expect it to block in that case,
so I'm not really sure what's causing it t
the
duplicate-message dissector.)
Cove Schneider wrote:
Guy Harris wrote:
Either
1) the pipe is or other network connection is in non-blocking mode
(in which case it *won't* block in that case)
or
2) there's a bug in the OS on which you're running this.
I believe
Lan Qing wrote:
hello,
I read the fllowing words in the c header file
I.e., the header that came with your OS, not the header that comes with
tcpdump?
/* Internet address. */
typedef uint32_t in_addr_t;
struct in_addr
{
in_addr_t s_addr;
};"
the struct in_addr have only one variable
Cove Schneider wrote:
Guy Harris wrote:
Either
1) the pipe is or other network connection is in non-blocking mode
(in which case it *won't* block in that case)
or
2) there's a bug in the OS on which you're running this.
I believe it's 1 here, the other end of
On May 18, 2006, at 9:18 PM, sandeep nitta wrote:
can anyone help me out with how a tcpdump -w command works.
I want to know what library functions are invoked if i use a -w
option and
the structures used.
It uses:
pcap_open_live() to open the capture device;
pcap_dump_op
Felipe Kellermann wrote:
> This fixes the problem to me. Does anyone know why 0x << (32 - 0)
> is resulting in 0x in mcode?
To quote the ANSI C89 standard, section 3.3.7 "Bitwise Shift Operators":
If the value of the right operand is negative or is greater than or
equal to th
Felipe Kellermann wrote:
> Thanks. I will look at the resulting assembly in the different toolchains
> and processos and systems and eventually discuss this subject with the GCC
> or binutils people.
I.e., suggesting that they standardize on a particular behavior for shifts
greater than the widt
axi wrote:
> My driver/card in monitor mode sends to libpcap a frame with FCS,
> when tcpdumps ( version 3.9.4 ) parsers i.e a valid Beacon Frame, it's
> identifies FCS part as a Tagged Parameter in a Management Body, and
> sometimes when pass TEST2 check, caused by that prints [|802.11] instead
>
On Jun 12, 2006, at 11:53 AM, [EMAIL PROTECTED] wrote:
I am trying to read file generated by 'tcpdump -r '
"-r", or "-w"? "tcpdump -r " reads the file in question
and prints the packets it reads. "tcpdump -w " captures
packets and writes them to a file in binary format.
I would real
On Jun 12, 2006, at 7:07 PM, [EMAIL PROTECTED] wrote:
The part I am confused about is where and when does ethernet comes
into picture. I got my program to print the header values, but I
was looking to know the type and everything I can find about the
ethernet frame wrapped in the packet.
On Jun 13, 2006, at 7:18 PM, [EMAIL PROTECTED] wrote:
I get a packet which is of type 802.1d at regular intervals.
I was eager to know the packet type of this particular packet.
I am catching this packet as unknown type.
I assume that's "802.1D", capital "D".
If so, they're probably Span
David Rosal wrote:
I've tried to use a class function member as a callback for pcap_loop(),
but the compiler complains that arguments don't match. The code is
something like this (I have simplified it):
...
Should I avoid C++ and use C instead (don't say that please...)
Should you
[EMAIL PROTECTED] wrote:
I wanted to access IP packet and then subsequently UDP/TCP/ICMP/IGMP
packet information. Are there any explicit function which I can call to
get information like version, IHL, source port, destination port, etc.
to get that information for each IP type of packet.
No
On Jun 26, 2006, at 12:03 PM, [EMAIL PROTECTED] wrote:
I am trying to disect ARP/RARP packet.
Basically I am looking for this information: Operation code,
Sender HW address, Sender Protocol address, Destination HW address
and Destination Protocol address.
Is there a direct way using pca
On Jun 24, 2006, at 10:50 PM, Richard Hansen wrote:
I have one thread that sits in pcap_loop() and another thread that
calls pcap_breakloop() when it is time to shut down. My code works
well on Windows (WinPcap 3.1).
Well, sort of. I suspect that pcap_breakloop() doesn't *immediately*
Fabian Schneider wrote:
I thought (and i have a programm running with this) that you can use the
to_ms value in pcap_open_live() to set such a timeout. The value won't be
interpreted by some OS'ses like FreeBSD or if you are using the
libpcap-mmap patch, resulting in a normal behaviour. But wi
Eloy A. Paris wrote:
So, according to a comment from Guy in the CVS log for pcap-bpf.c,
select() should work on BPF devices on Tiger.
It works as well as it does on older versions of other BSDs.
This means that you can do a select() on it, and, if the BPF buffer
fills up, the select() will r
Eloy Paris wrote:
Wow, I feel like an idiot. Looks like I didn't do my homework well.
Further digging on the mailing list archive gave me the answer:
BIOCIMMEDIATE
Doing an ioctl() for BIOCIMMEDIATE on the file descriptor returned
by pcap_get_selectable_fd() completely fixes the problem.
It w
David Rosal wrote:
ip_off is an u_short, so byte order issues apply. Try this:
printf("%d|", ntohs(ippkt->ip_off));
...and then remember that the upper 3 bits of that 16-bit field are flags:
#define IP_RF 0x8000/* reserved fragment flag */
#define IP_DF 0x4000
Adam M. wrote:
This is probably a FAQ++, but I'm having trouble using Pcap for
savefiles that were captured from a loopback device.
There are 2 problems here:
1) In general, how is one supposed to determine what the layer-2
protocol is?
Call pcap_datalink() on the pcap_t. It'll indicate what
On Jul 28, 2006, at 12:51 PM, Harley Stenzel wrote:
Show that this happens when 2 threads use pcap_t at the same time:
libpcap is, for better or worse, not thread-safe, in the sense that
no locking is done on the pcap_t structure to prevent concurrent
accesses from stepping on each other,
Aaron Turner wrote:
Sorry if this is a little offtopic, but I'm in the process of ripping
out libnet from my code and replacing it with libpcap since it can now
inject frames. One thing I'm stuck on though is trying to figure out
a reliable, cross platform way to determine the MAC address of th
Naveen N Rao wrote:
I am trying to get packet transmission working using pcap_inject() on AIX
5.3. I haven't had any success using BPF and DLPI. With BPF, I get "send:
Error 0"
That means that the write() done to the BPF device returned -1 but
didn't set "errno" to a valid error value.
Give
[EMAIL PROTECTED] wrote:
when given a rule consisting of a set of sub rules to pcap, if a packet
matches the rule, how do I know which sub rule it matches?
libpcap will not tell you that. As far as it's concerned - and as far
as the kernel is concerned, on those platforms where the packet
tvfbfdb uyvy wrote:
I developing a tool for dumping all the data from a packet interference
engine into a log. I have undestood that in pcap_read_packet(), the
recvfrom function stores all the data from the socket (related to the
file descriptor specified) to a buffer,
Not on the computer o
501 - 600 of 2521 matches
Mail list logo
