linjiangxiao wrote:
the website is a document about the libpcap-0.9.3,but i still cannot
use libcap-0.9.3 to send packets!-
On what OS are you using libpcap? HP-UX (as per the URL you sent), or
some other OS?
What happens when you try to send packets? Does pcap_sendpacket() or
pcap_injec
Albretch Mueller wrote:
1._ how do you log to a syslog client instead of a file?
If you mean "in tcpdump", the only way to do that would be to pipe the
output of tcpdump to the "logger" command (if the UN*X on which you're
running has that command); that would, of course, require that you're
Michal Kepien wrote:
I don't know whether this is the right place to post, but unfortunately nobody
on the usenet was able to help me with this issue. I came across this while
I was writing a simple libpcap-based program. The problem is, after I call any
packet capturing function (pcap_next(), p
rh wrote:
I'm using libnet 1.1.1 and pcaplib 0.8.3 (I believe).
Linux 2.4.20 / 2.6.11 (and later, FreeBSD 5.2).
GCC 3.3
Apologies if this is too off-topic an application for this list.
I'm attempting to use libnet and pcap together to write a client using raw
sockets so that I can gain explic
rh wrote:
Sounds like it's unavoidable. libnet and libpcap seem like they'd
complement each other so well.
libpcap is a low-level library, in that
1) it works at the link layer
and
2) it doesn't deal with dissecting or constructing packets.
As of 0.9.x, it *does* deal with
rh wrote:
If you're going to be sending stuff *that* strange, you shouldn't expect
a receiving machine to run an ordinary networking stack to handle them,
so it seems a bit odd that you're running ttcp on the remote machine,
unless you're trying to use that to test whether your code works if it'
Michal Kepien wrote:
$ tcpdump -h
tcpdump version 3.9.2
libpcap version 0.9.2
I've compiled both libpcap and tcpdump from sources version 3.9.3 (yes, that's
a "3" at the end :))
Could you try running that version of tcpdump, or your application,
under Valgrind, while capturing on a PPP link?
Michal Kepien wrote:
The whole `valgrind --leak-check=yes ./glibc_pcap_error' output can be found
here:
http://kempniu.no-ip.com/files/valgrind.log
Well, after seeing the Valgrind errors and asking why it was complaining
about a buffer of size 1, and then looking at the libpcap code to see
Vossie wrote:
I am using pcap_loop to capture a given amount of packets. That is
easy to implement but now I want to use pcap_loop BUT it must capture
packets for a given amount of time.
PS: According to man I must use pcap_breakloop. But how? Inside the callback
function?-
That depends on
Wilmar SULAIMAN wrote:
Suppose that I've set up a program using libpcap library to capture all
the packet that going to the ethernet card. I was wondering is it possible
that the program can't capture all the packets due to massive network packets.
What I mean by that is that suppose that my
Vossie wrote:
I wanted libpcap to do the following: It must distinguish between
packets that have been sent from its monitoring network card and between
packets that was received on its monitoring network card.
"Distinguish between" those packets in what sense? Do you mean you want
libpcap t
On Nov 2, 2005, at 4:16 PM, Luis Del Pino wrote:
Can i capture radio header 802.11 with promicuouos mode or only
monitor
mode?
I would like to get signal strength, noise strength, etc.
Could i capture this information with libpcap and promiscuous mode?
Not unless the driver supports that.
Mike Kershaw wrote:
Radio level data is only available in monitor mode.
On Linux, at least. From a quick look at the wi driver and 802.11
framework in NetBSD, you should be able to get radio data and 802.11
headers in non-promiscuous, promiscuous, and monitor mode; the 802.11
headers should
On Nov 7, 2005, at 1:08 PM, Rick Jones wrote:
The following change bumps a few limits in scanner.l so it will be
processed by the lex which ships with HP-UX. It is based on
libpcap-2005.10.09. While I was here, I went through to make sure
that utilization of these things was no more than ~
On Nov 7, 2005, at 1:23 PM, Rick Jones wrote:
It seems the compiler I have didn't like the + sizeof(*dh) in the
declaration.
Legitimately so. "void" objects have no size, so "(void *)dh" points
to an "object of unknown size", so advancing the pointer by "sizeof
(*dh)" objects is impossib
On Nov 4, 2005, at 3:11 AM, Karl-Johan Perntz wrote:
When I cross compiled libpcap and tcpdump for the CRIS architecture I
had to make libpcap aware of architecture dependent ar and ld. The
diff
below adds the option to specify which ar and ld to use. I think that
this could be useful for ot
On Nov 9, 2005, at 12:20 AM, Vossie wrote:
Ok in terms of the feature that I wanted to use... Is there a
command that
libpcap can use to detect lost packets?
To quote my earlier message:
"See packet lost" in what sense?
The only types of lost packet libpcap can report on - and it can on
On Nov 9, 2005, at 9:59 AM, Rick Jones wrote:
Vossie wrote:
Sorry guys. I was typing too fast. I mean HTTP packets (that
transfer the
data) and not the TCP ACK's :-)
Looking at a stream of HTTP carried in TCP segments without looking
at the ACKs seems a bit odd, but if you really don't w
On Nov 9, 2005, at 2:53 PM, Rick Jones wrote:
Shouldn't that have then appeared in the 11/09 "current" tar? I
just grabbed that and it doesn't seem to have been there. Operator
error on my part? Grabbing the wrong tar file or something?
It was checked in, but perhaps the tarball was crea
On Nov 9, 2005, at 3:17 PM, Rick Jones wrote:
For fun and excitement :) I tried compiling the 10.09 bits on an
IA64 HP-UX 11.23 system. I'm not _entirely_ certain of the lineage
of the compiler I'm using, having gotten it from an internal depot,
but it did emit some warnings that may or m
On Nov 10, 2005, at 11:05 AM, Rick Jones wrote:
Interesting - last time I looked, 10.09 was the latest. Ironic
coincidence that today happens to be the 10th of November - is the
machine's date off by a month?
Not now:
$ ssh cvs.tcpdump.org
...
% date
On Nov 11, 2005, at 1:48 PM, Evan Hughes wrote:
I'm building a library that indexes packets in libpcap files. In
order to create and use such an index, I'd like to be able to get the
file location that each packet starts at.
Would I be violating encapsulation if I just use pcap_file()
Vossie wrote:
The University of Pretoria uses a firewall to limit access to the
Internet but also a proxy server (for the students). According to
someone I have spoken about my problem the proxy server also uses the
firewall for outside access but it is a kind of a router for the
students. Thus
Vossie wrote:
This was the feature I wanted to implement. I would just mention in my
report that this kind of detection is not practical.
Direct *detection* isn't possible except at the point of packet loss
(although you might be able to get packet loss counts from the switch or
router), but
Albert Chin wrote:
From print-isoclns.c:
static int
isis_print_extd_ip_reach (const u_int8_t *tptr, const char *ident, u_int16_t
afi) {
char ident_buffer[20];
u_int8_t prefix[sizeof(struct in6_addr)]; /* shared copy buffer for IPv4
and IPv6 prefixes */
The prefix definition is
Ian McDonald wrote:
It uses the in6_addr structure because that would be bigger than IPv4
so could hold both. Saves having two different parts of code doing
basically the same thing.
...and breaks builds on systems that don't support IPv6.
As noted, a change was checked in to fix this; all it
Louis-Michel Gelinas wrote:
I ran into an issue using libpcap and tcpdump.
Whenever I enter a filter tcpdump segfaults:
i.e.:
works fine :
#tcpdump
segfault
#tcpdump port 80
That's a rather common filter, I suspect. :-)
I.e., if this were a libpcap bug, unless it's a very new one, it
Evan Hughes wrote:
If I submitted a patch with the change in it, what's the
likelihood that it would be accepted?
A patch with pcap_seek() and pcap_tell()? It'd probably be accepted...
I would, of course, wrap the
position into an opaque typedef, so that stuff like endian-ness could
be
Latha G wrote:
But on my system the link level header is not printd out. -xx option gives
the output same as the -x option.No change in the output.Both are the same.
Is this a bug in tcpdump???
Can anyone help me.
Thanks in advance.
my tcpdump version is: 3.8
...which means that, when it start
Latha G wrote:
In my system,
YYY is EN10MB and
ZZZ is Ethernet.
But for tcpdump -e option gives correct output only.
Means the link level headers are prited out.
Why it happens for -xx , that it is not printing header information.
I'm not seeing that on my system (OS X 10.4.3), which comes wit
Evan Hughes wrote:
Bah! That patch has cruft from an uninteresting file. A slimmer
patch is attached.
Some comments:
fgetpos() and fsetpos() don't return an error code, they returns 0 on
success or -1 on failure and, if they return -1, they set "errno" to the
error code.
If fgetpos() fai
Gianluca Varenni wrote:
Do you have any idea if performance is affected by these patches?
I'd probably expect almost no performance penalty in pcap_ftell() (apart
from the fact that you allocate memory with malloc),
...and might make a system call to get the file position, which could
signi
Evan Hughes wrote:
I haven't done any performance tests. The fgetpos() call is the
only function call I've added on the main path (although I do a little
stack manipulation during the read), but that's during
sf_next_packet(). I'm assuming that is already slow due to IO.
...although real I/
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 wel
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
Hi folks,
Is it possible to get the MAC address of the interfaces present in a machine
using libpcap API's.. If its not possible, can someone point to some code
samples to do it..
With Regards,
C Guy
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
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
501 - 600 of 2513 matches
Mail list logo
