I was wondering if there is a way to use the WinPCap libraries from
Visual Basic? I've been unable to connect to the Wpcap.dll at all (file
not found error),
Which version of WinPcap are you using?
Versions prior to 2.1 didn't *have* a shared version of the WinPcap
library, i.e. there
How are the following fields specified in PCAP v2.4 ?
PCAP-sigfigs (timestamp accuracy? What scale ? in comparison to what ?)
How about "hardwired to 0"? Perhaps, at one point in time, libpcap
bothered to set "sigfigs" to a value other than 0, but it doesn't do so
now.
PCAP-snaplen (max
I just updated to pcap 0.6.2, and it seem the behavior of
the to_ms agument passed to pcap_open_live has changed.
In my application, pcap_dispatch never return...
here are some sample code :
[...]
dev-pd = pcap_open_live(dev-name, config.snaplen, 1, 1000, err);
The timeout value, on
([EMAIL PROTECTED] and [EMAIL PROTECTED] are now forwarded to
[EMAIL PROTECTED]; libpcap and tcpdump development are now
done by The Tcpdump Group - see
http://www.tcpdump.org/
.)
On Tue, Jul 10, 2001 at 10:40:03AM +0530, Neeta Srivastava wrote:
I am using libPcap for packet capturing
On Sun, Jul 08, 2001 at 08:52:44PM +, Subba Rao wrote:
I have Linux kernel 2.2.19 on one system
That doesn't say what version of what OS it is, it just says what
version of the Linux kernel the kernel in that OS is based on (it
doesn't even guarantee that the distributor hasn't applied
I have downloaded the latest Libpcap and Tcpdump source files. Libpcap was
a very clean install. Tcpdump had this one warning message:
could you tell us which platform are you using?
Probably Linux. For some reason, the configure script prefers
sigset() to sigaction(), even on
How can I call pcap_open_dead() from a program that isn't libpcap,
when the defines are in savefile.c.
Or should I be using DLT_EN10MB ??
Use DLT_EN10MB, or whatever the appropriate DLT_ type value is.
The name of the argument is linktype, but it's a DLT_ linktype, not a
LINKTYPE_
P means the packet is going to some other host (and it was probably
captured by promiscuity). If you dump IP tunnels, the tcpdump might
wrongly check the interior datagram, and believe it's meant to someone
else.
At least on Linux, tcpdump doesn't check the datagram, the kernel does -
the
On Sat, Jul 21, 2001 at 03:12:49PM +, Giora Engel wrote:
Please try this bigger file.
Please try version 0.6.2 of libpcap. If it crashes only in 0.5,
but doesn't crash in 0.6.2, it's probably the bug in question, in which
case...
If it doesn't crash I'll try to diff the versions.
Does
On Sat, Jul 21, 2001 at 04:08:45PM -0700, Guy Harris wrote:
On Sat, Jul 21, 2001 at 03:12:49PM +, Giora Engel wrote:
Please try this bigger file.
Please try version 0.6.2 of libpcap. If it crashes only in 0.5,
but doesn't crash in 0.6.2,
I tried backing the fix to the optimizer out
On Wed, Jul 25, 2001 at 10:29:02PM -0400, Scott Barron wrote:
Here is the patch I made for getting the stats from the Linux 2.4.x kernel.
Checked in, with some changes - for example:
pcap-linux.c
Removed the dependancy on netpacket/packet.h
Don't bother incrementing ps_recv if pulling
On Wed, Aug 01, 2001 at 10:58:22PM +0200, [EMAIL PROTECTED] wrote:
I started writing this code but put it in the case OUI_CISCO: around
line 224; was I missing something that required it being outside the
case?
I think it would work just fine to have it there.
If that's checking for the
On Sat, Aug 04, 2001 at 10:37:45AM +0200, Rafal Wojtczuk wrote:
BTW, if we know the data link type, is there a simple way to determine the
link layer header size (other than manually checking each physical medium
documentation ?)
No.
If not (I think not) is there an authoritative document
(The LBL folks aren't maintaining libpcap and tcpdump any more;
[EMAIL PROTECTED] and [EMAIL PROTECTED] are now being redirected to
[EMAIL PROTECTED], so I changed the CC to go there directly.)
OS: Red Hat Linux release 7.0 (Guiness) with kernel 2.2.16-22 on an i686.
Errors: in pcap.c line
On Thu, Nov 29, 2001 at 05:20:20PM +0900, ÃÖÈ«¹Î wrote:
I'v known that libpcap and tcpdump implementation on SunOS 5.x is done in user level.
So I want to apply BPF to SunOS 5.x to improve performance.
Is there some way to do that?
There is, in theory, a way to do that.
If exists, ... let
When i run tcpdump without any arguments, according to my understanding, it
is supposed to sniff on all devices.
No.
That's what the version of tcpdump that comes with some versions of
Linux does, but it's not what the version of tcpdump from tcpdump.org
does (even on Linux).
Can you please
windump works great, but it is 12:30pm and the windump timestamp is
reporting the time as 13:30. It should be 12:30.
By the way, I have the latest version of WinPcap (2.2) installed on my
Windows 2000 desktop here, and have just downloaded the latest version
of WinDump, and it shows correct
On Thu, Aug 23, 2001 at 03:05:10PM +0200, Sebastian wrote:
Wouldn't a malloc(snaplen) in pcap_open_live() suffice?
(Presumably you mean malloc(handle-bufsize + handle-offset).
Yes, a buffer malloc() in pcap_open_live() would suffice; that's why
my patch does that...
Malloc-calls can be
On Tue, Aug 14, 2001 at 08:06:39PM -0500, Bill Dodd wrote:
OK, in pcap_read_packet(), there is this code:
packet_len = recvfrom(
handle-fd, handle-buffer + offset + handle-offset,
handle-md.readlen - offset, MSG_TRUNC,
Good question. I was wondering about that as well after I sent my original
note. This was on a 16Mb token ring network, and the apparently default
mtu for the driver I'm using is 2000. I was regularly seeing packets that
were between 4000 and 4500 bytes. I changed the mtu to 4500, but would
I hope I`m sending this to the right place, I got this email
from the winPcap website about where to send bugs reports.
If you look at the home page of WinPcap:
http://netgroup-serv.polito.it/winpcap/
it says:
Please send bug reports to [EMAIL PROTECTED]
On Sun, Aug 05, 2001 at 03:50:55AM -0400, Scott Gifford wrote:
The structure used to store the interface looks like this:
struct pcap_inet_if {
#ifdef IF_NAMESIZE
char name[IF_NAMESIZE+1];
#else
char name[sizeof(unused_ifreq-ifr_name)+1];
#endif
Another problem with returning non-up interfaces is that you may get
errors when trying to get addresses on them:
% ./iflist
iflist in free(): warning: modified (chunk-) pointer.
Error in pcap_findalldevs: SIOCGIFNETMASK: lp0: Can't assign requested
address
The problem is I don't have 0 length link layer, but I invented a specific
IP Filter link layer header, which can contain for example the IP Filter
flags (fr_flags), the direction (IN/OUT) and the interface.
Then you need to invent a specific DLT_ name for that link-layer
header, and add
(Reply redirected to [EMAIL PROTECTED], as that's where
[EMAIL PROTECTED] and [EMAIL PROTECTED] are now redirected.)
since you open in non-promisc mode it might happen that
theres no packet to capture and pcap_dispatch() never returns.
Its blocked in a slow systemcall.
You may use select()
On Sat, Sep 08, 2001 at 05:54:00PM +0430, Mehdi Kianpour wrote:
Is there any developer's manual for libpcap and tcpdump available? I
want to write network applications using libpcap but I couldn't even
find libpcap's API. May someone help me about this?
There's no developer's manual for
From: Hannes Gredler [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: complete isis support + isis over ppp support
[1 text/plain; us-ascii (7bit)]
hi tcpdump developers,
pls find attached a patch for complete [except IPv6] isis support.
the
On Fri, Sep 07, 2001 at 03:07:42PM -0700, Guy Harris wrote:
If you do so, please use 116 as the value for that DLT_ name, and send
us the name you chose (e.g., DLT_IPFILTER). Otherwise, we can't
guarantee that the value won't later be assigned to some other DLT_
name.
The way you add
On Sun, Sep 09, 2001 at 10:05:56AM +0200, Hannes Gredler wrote:
is fixed now. tx for the help;
Checked in, with some cleanups.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
On Sun, Sep 09, 2001 at 01:33:48PM -0400, Nickolai Zeldovich wrote:
Thanks for the comments; attached is an updated patch which should
hopefully address the concerns you mentioned.
Checked in.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
On Sun, Sep 09, 2001 at 01:24:10PM +0200, Frank Volf wrote:
2) I would like to use struct pcap_sf_pkthdr and sf_write_header(),
Is there some reason why you're not just using pcap_dump_open() and
pcap_dump() to write out a file in tcpdump format? If it's important
to flush out the standard I/O
On Sun, Sep 09, 2001 at 11:29:09PM +0300, Hugh Daniel wrote:
I just tryed the current (2001.09.09) tcpdump/libpcap on my HDLC
(T1, Link encap:(Cisco)-HDLC) link and it failed again (rather badly,
I was getting LOTS of bogus output that looked like serious DDoS and
was just plain bogosity).
On Mon, Sep 10, 2001 at 12:55:13AM +0300, Hugh Daniel wrote:
- : Unresonable output:
hugh@burpelson $ so tcpdump -e -n -i hdlc0
15:21:39.562131 0:0:0:0:0:0 0:0:0:0:0:1 ip 62: 217.2.192.181.4663
192.171.112.89.www: S 668895481:668895481(0) win 8760 mss 1460,nop,nop,sackOK (DF)
hugh@burpelson $ so tcpdump -e -n -i hdlc0
15:21:39.562131 0:0:0:0:0:0 0:0:0:0:0:1 ip 62: 217.2.192.181.4663
192.171.112.89.www: S 668895481:668895481(0) win 8760 mss 1460,nop,nop,sackOK (DF)
15:21:39.562144 0:0:0:0:0:0 0:0:0:0:0:0 ip 62: 217.2.192.181.4663
192.171.112.89.www: S
On Mon, Sep 10, 2001 at 10:27:06PM +0100, Ben Harris wrote:
Thanks. I'll do that.
If, as, and when you add support to libpcap and tcpdump, please send us
patches so we can incorporate them into our CVS tree.
-
This is the TCPDUMP workers list. It is archived at
On Thu, Sep 13, 2001 at 05:07:43AM +0200, rooty wrote:
The problem is i hve a libpcap application with
pcap_setfilter() and pcap_compile().
If the Pcap_setfilter() is used i can't write any more on the
standart output STDOUT /*linux of course*/.
(of course? Linux isn't the only OS with
On Sat, Sep 15, 2001 at 12:47:12PM +0430, Mehdi Kianpour wrote:
In the paper titled: Development of an Architecture for Packet Capture
and Network Traffic Analysis found in
http://netgroup-serv.polito.it/winpcap/docs/default.htm
http://netgroup-serv.polito.it/winpcap/docs/default.htm the
On Sun, Sep 16, 2001 at 08:26:01PM +0430, Mehdi Kianpour wrote:
I've tested tcpdump and windump on Redhat 7 vs Windows 98. Windump had
packet loss above 20% when working on a network with 10% utilization but
tcpdump had no packet loss.
Are you using the packets dropped by kernel message from
On Thu, Sep 13, 2001 at 01:08:21PM -0600, Phil Wood wrote:
So, there are at least two things wrong here. The obvious, is that the
code needs to be patched so that length goes to zero in our life time,
The current code in CVS does a separate check for a zero-length
attribute.
and the other
On Wed, Sep 19, 2001 at 11:19:14PM -0400, Ashley Thomas wrote:
In the struct pcap which is defined in pcap-int.h,
there is a variable : int cc;
do you know what is the use of that variable ?
It's used to remember how many packets in the buffer have not yet been
processed. pcap_dispatch()
... I'm asking if you are interested in joining the win32 code with the
sources of tcpdump and libpcap.
Are you suggesting that we pick up only the changes to tcpdump and
libpcap, or are you also suggesting that we pick up the drivers and
packet.dll?
The former makes sense to me; the latter,
On Sat, Sep 22, 2001 at 07:54:18PM +0430, Mehdi Kianpour wrote:
Do you know any graphical tools other than ethereal for analyzing
tcpdump output files?
Ethereal is graphical, currently, only because it has a graphical user
interface; it doesn't yet have any code to draw graphs.
Another packet
On Sun, Sep 23, 2001 at 02:04:30PM -0300, Mercia Eliane Bittencourt Figueredo wrote:
Congratulations! You've managed to find *two separate* bugs in
tcpdump's cip_print() routine!
:)
I've checked in some changes that should fix those bugs - as well as
making it just call the LLC print
Due to severe problems in our internal network, the server that hosts
WinPcap and Analyzer is no currenctly reachable.
We hope that our technicians will solve the problem as soon as possible;
however they didn't give us any indication about that.
We are really sorry for the inconvenience.
On Thu, Sep 27, 2001 at 09:51:59AM +0200, Ryad BEN EL KEZADRI wrote:
I've recently found out a binary package of tcpdump for AIX and I
install it. It worked. But when I execute the binary I'm getting the
following error :
tcpdump: Could not get major number for bpf
I don't see the string
On Sun, Sep 30, 2001 at 08:18:32PM -0400, Michael Richardson wrote:
How do you feel about me making a 3.6.3 branch *now*?
I'd see 3.6.3 as something made from the 3.6 branch, which has some bug
fixes since 3.6.2. (Or maybe they're in the 0.6 branch of libpcap.)
I'd see something branched
The CVS copy of tcpdump has lines in pcap-dump-trunc.c that say:
#include netinet/ip_var.h
[ ... ]
#include netinet/udp_var.h
[ ... ]
#include netinet/tcpip.h
We should be using the local copies of those files, if the sole reason
for including them is to get protocol
On Tue, Oct 02, 2001 at 03:47:52PM +0900, Motonori Shindo wrote:
I don't see any reason why this many header files need to be
#include-ed, first of all.
I agree - I looked at the code, and it's not doing any protocol
operations.
I also noticed that this file has DOS line
style (terminated
On Tue, Oct 02, 2001 at 06:56:49PM +0900, Motonori Shindo wrote:
Thanks for leaving interface.h to be included. You're right. But
before including interface.h, we need to include config.h.
Patch attached.
Checked in.
-
This is the TCPDUMP workers list. It is archived at
By the way, is there some compelling reason why dump_and_trunc(), and
the routines it uses, are in a separate file, rather than being in
tcpdump.c?
And shouldn't dump_and_trunc() just call pcap_dump() to write the
record to the capture file, rather than copying the code in
pcap_dump()? (For one
useless, and the fencepost error in packet_ring_recv
means that even if, as Guy Harris suggests, you use select or poll
before calling pcap_dispatch() and you only ask for one packet, you may
end up blocking waiting for the second packet that you didn't ask for.
With a narrow filter and/or low
I will tag 3.7 tonight.
I haven't yet checked in the get a list of interfaces and addresses
API; do we want that for libpcap 0.7?
If so, and you tag 0.7 before I check it in, should I slip the tag, or
check it in to the branch as well?
-
This is the TCPDUMP workers list. It is archived at
On Tue, Oct 16, 2001 at 11:56:28AM -0400, Michael Richardson wrote:
Guy == Guy Harris [EMAIL PROTECTED] writes:
Guy Should we slip the tag on print-bgp.c so this fix (and the fix checked
Guy in just before that) show up in 3.7?
Yes.
Done.
-
This is the TCPDUMP workers list
On Tue, Oct 16, 2001 at 08:38:12PM -0400, Kaarthik Sivakumar wrote:
The for loop should be
for (i = 0; i bgpo.bgpo_optlen; /* Nothing */ ) {
since i is getting incremented within the for loop. This results in
the i going one value too far into the options list and so memcpy of
On Wed, Oct 24, 2001 at 09:29:45PM +, ashley thomas wrote:
Is it possible to listen on the network-interface
without configuring an ip-address for the interface ?
It should be, on at least some OSes; you may get a warning because it
couldn't get an IP address or netmask for it, which means
On Thu, Oct 18, 2001 at 05:07:28PM -0700, Crist J. Clark wrote:
I made a quick patch to print-ip.c to print the protocol for
fragments. I built and tested the patch on FreeBSD. I am not sure how
portable it would be, but it serves as a demonstration.
Well, we also use getprotobynumber() in
On Fri, Oct 12, 2001 at 06:54:58PM +0300, Pekka Savola wrote:
The patches, or at least almost all of them, have been posted on here too,
I believe. Sometimes with none, sometimes with little feedback.
I looked at the fixes in the tcpdump-3.6.2-9.src.rpm SRPM, and:
- AFS printing security
On Mon, Oct 29, 2001 at 06:10:20PM +0330, Mehdi Kianpour wrote:
Is there any option to find out the number of errors occuring in the
network using winpcap?
I.e., link-layer errors such as CRC errors on Ethernet?
WinPcap has libpcap's not-very-powerful pcap_stats() call, which gives
only
On Wed, Oct 31, 2001 at 04:00:41PM +0900, Motonori Shindo wrote:
I found one small bug in print-pptp.c (sorry, it was my fault). I
enclosed a patch to fix it.
Checked in.
BTW, how about the patch I posted about a week ago to clean up
print-l2tpc? It may look a big change, but the decoding
On Thu, Nov 01, 2001 at 01:38:11PM -0600, Gilbert Ramirez wrote:
My code creates libpcap-style files. I need a new DLT value for
the linktype, for 2 reasons. First, the packet I write to the file
will contain some extra initial information which contains
the true, per-packet link type. That
On Mon, Nov 12, 2001 at 05:04:59PM -0800, Bill Fenner wrote:
However, it's not clear that comparisons with bits of
the packet should always be signed,
I suspect most of them should be unsigned; fields in packets seem
largely to be unsigned if they're integers (as opposed to, in effect,
just
I've compiled and installed tcpdump from tcpdump.org. It is running on
AIX 4.3.3 maintenance release 08.
The basic functionality is ok, but if I do 'tcpdump host hostname'
tcpdump reports:
tcpdump: /dev/en0: No such file or directory
AIX does not use special device files in
On Fri, Nov 16, 2001 at 04:33:28PM -0800, Guy Harris wrote:
For some reason, a number of people who have sent in fixes to the DLPI
support in libpcap for AIX haven't reported that problem, and haven't
sent in fixes for it, perhaps because they used
tcpdump -i /dev/dlpi/en0
On Fri, Nov 16, 2001 at 04:33:28PM -0800, Guy Harris wrote:
1) the AIX BPF is very annoyingly non-standard (BIOCGDLT returns
SNMP ifType values rather than DLT_ values, and the time
stamps on packets are in seconds and nanoseconds rather than
seconds
On Sat, Nov 17, 2001 at 10:40:49PM -0800, [EMAIL PROTECTED] wrote:
Hi, has tcpdump been tested on Mac OS X.
Was this with the current CVS snapshot, a 3.7 beta snapshot, or 3.6.2?
If it was with 3.6.2, try it with one of the 3.7 beta snapshots.
It was packaged with the
operating system but
On Sun, Nov 18, 2001 at 03:40:38PM -0800, [EMAIL PROTECTED] wrote:
On Sunday, November 18, 2001, at 03:20 PM, Guy Harris wrote:
On Sat, Nov 17, 2001 at 10:40:49PM -0800, [EMAIL PROTECTED] wrote:
Hi, has tcpdump been tested on Mac OS X.
Was this with the current CVS snapshot, a 3.7
I belive the error codes mean the same in both winpcap and libpcap. SO I
added pcap_strerror in libpcap and got the strings for the error codes...
for example:
1- operation not permitted.
2- no such file or directory
3- no such process ... and so on.
pcap_strerror() expects a UNIX-style
I'm just writing a program to read DNS A? requests off the wire with
libpcap. I didn't find an easy way to do this in the manpage or on the web.
Well, there's a libpcap tutorial at
http://www.cse.nau.edu/~mc8/Socket/Tutorials/section1.html
(there's a link to it from the related
On Mon, Oct 01, 2001 at 04:14:09PM -0400, Michael Richardson wrote:
Guy Should we check in the changes to add the API for getting a list of
Guy interface names and addresses, to put that into libpcap 0.7? Or
Yes!
OK, I've checked that in.
-
This is the TCPDUMP workers list. It is
On Thu, Oct 04, 2001 at 12:06:00AM -0700, kino skin wrote:
In case one needs to add support for a new
Link type to pcap, what are the steps that need to be
taken.
The first step is to figure out how to use that link type on the
platform on which you're adding support.
On Solaris 8
Pcap
On Mon, Oct 08, 2001 at 01:14:03AM -0400, Michael Richardson wrote:
It looks like a simple case of hacking aclocal.m4 a la places
above it.
Presumably you mean hacking it to do something along the lines of
places=`ls $srcdir/.. | sed -e 's,/$,,' -e 's,^,../,' | \
On Mon, Oct 08, 2001 at 03:03:50PM +0100, Georgios Papadopoulos wrote:
I was wondering (since live capturing of frame relay packets using the
libpcap packet driver is depentant on various factors) how feasible is it to
dissect frame relay packets on sniffer capture files (e.g. capture a
Can you tell me, if the TCP length is advertised as 73 characters,
will tcpdump -X just print out 73 characters, or it will it pad to a
74th?
You might want to try running tcpdump with the -e flag; it should
cause tcpdump to print the length of the packet, as reported to it by
Sorry to keep coming back, but I am trying to run some programs
against LIBPCAP.
Are those programs 32-bit or 64-bit programs?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
I've got a somewhat less obfuscated version (uses EXTRACT_* instead
of SVAL, IVAL, etc) to which I've added some TCHECK()'s. It still
needs some work, and lots of testing -- anyone care to help?
I have a pile of SMB captures, which I can trim to a snapshot length of
68, so that I can do at
I use SuSE.7.0 and under Linux select works.
Then use select().
Put the file descriptor for the pcap device into non-blocking mode - use
pcap_fileno() to get the file descriptor, and use fcntl() to set
O_NONBLOCK - and then, in the input loop, use select() on both that
file descriptor and
On Tue, Oct 16, 2001 at 09:23:58PM -0700, Jitendra Sankpal wrote:
I have a question about libpcap.
Can libpcap be used for packet filtering? If yes how?
Packet filtering in what sense? In the sense that a firewall, for
example, filters packets? If so, no, as it receives from the underlying
On Tue, Oct 16, 2001 at 09:22:10PM -0700, Jitendra Sankpal wrote:
We know that libpcap uses BPF for packet filtering.
Only on BSD. It uses other mechanisms on other OSes.
Can we use/change the code of BPF so as to use libpcap
bpf for packet filtering FIREWALL.
No, that wouldn't be
I can't get the tcpdump stuff to run on a QNX machine.
That's because none of us with commit privileges have, as far as I know,
any idea what the QNX mechanism for packet capture is (I certainly
don't), and nobody's sent us a patch to add support for libpcap.
I get the following error
#
The question is this sample is programed to exit from loop
when the program received TERM signal. Could you please
teach me the way to program to exit right after line 16.
The problem of this sample is even if program received
TERM signal, pcap_dispatch() blockes until libpcap
recognize
The fact that you sent mail to [EMAIL PROTECTED] suggests that you
may be using an old version of libpcap. The LBL folks aren't
maintaining tcpdump or libpcap any more; tcpdump.org is now doing that,
and their mailing lists are being forwarded to
[EMAIL PROTECTED]
I just ran into a problem
On Mon, Dec 03, 2001 at 07:39:39AM +0900, [EMAIL PROTECTED] wrote:
i'm not saying it is a bug in tcpdump. is it mandatory for BPF to
return an aligned packet? if so, it is a bug in netbsd.
Well, the FreeBSD 3.4 man page for BPF says
The bh_hdrlen field exists to account for
On Sun, Dec 02, 2001 at 11:34:02PM +0100, Pepa Flores wrote:
First : Could you explain to me how do tcpdump and linux kernel work? It
means, Can I know the time between the Ethernet card 'hears' the packet and
the timestamp for this packet is printed?
Tcpdump uses libpcap to capture packets;
On Sun, Dec 02, 2001 at 03:30:41PM -0800, Bill Fenner wrote:
I think it's unstated (except in the comments you removed). I guess
since there's no one BPF, there's no way to say what the design goals
are any more.
...and since there's no guarantee that the packets delivered to tcpdump
came
On Sat, Dec 01, 2001 at 09:13:57PM +0100, Hannes Gredler wrote:
hi all,
pls find attached IPv6 TLV support for IS-IS as well as
some bugfixes/cleanups;
Checked in, with:
-#ifndef lint
-static const char rcsid[] =
-@(#) $Header: /tcpdump/master/tcpdump/print-isoclns.c,v 1.31
According to this trace, the stack is currupted.
It said that pcap_loop () is invoked from snss7btnup. which is false.
No, it's saying that it's *located* in snss7btnup.c:
#4 0x8e9b0 in pcap_loop () at snss7btnup.c:2074
it's saying that it's invoked from util_packet_scheduler__FUi():
#5
On Sat, Dec 08, 2001 at 02:45:32PM -0700, Phil Wood wrote:
--- pcap-linux.c-2001.12.08 Sat Dec 8 20:22:32 2001
+++ pcap-linux.c Sat Dec 8 21:05:23 2001
@@ -626,17 +626,45 @@
pcap_stats(pcap_t *handle, struct pcap_stat *stats)
{
#ifdef HAVE_TPACKET_STATS
+if (handle-fd -1)
On Sun, Dec 09, 2001 at 04:20:19AM +0100, Hannes Gredler wrote:
pls find attached support for the IS-IS
restart signaling TLV #211;
Checked in.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL
On Sat, Dec 08, 2001 at 02:45:32PM -0700, Phil Wood wrote:
By the way, for some reason when tcpdump quits normally (like after -c
pktcnt)it will not dump the stats. However, if you just let it run
and then break out you get the stats.
It's because main() doesn't call info(1) before exiting.
On Sat, Dec 08, 2001 at 02:45:32PM -0700, Phil Wood wrote:
I discovered an intermittent problem with pcap_stats which was the result
of an incorrect length value. Actually, I think it was related to what
gcc/libc combo was in effect when pcap was built. 'cause it worked on
some boxes, and
On Mon, Dec 10, 2001 at 10:17:56AM +0330, Mehdi Kianpour wrote:
Does anyone know how can I see CRC error using libpcap?
Unfortunately, on most if not all platforms on which libpcap runs, there
is, as far as I know, no way to configure the network card drivers to
supply packets with bad CRCs to
What exactly do you mean by an aligned packet?
uname -sr
FreeBSD 4.1-RELEASE
man bpf
...
BPF HEADER
The following structure is prepended to each packet returned by read(2):
...
The bh_hdrlen field exists to account for padding between the header and
(tcpdump-announce is not a mailing list to which questions about
tcpdump or libpcap should be sent; it's for announcements sent out by
the tcpdump/libpcap developer's group. Questions should be sent to
tcpdump-workers only.)
How can i make to tcpdump log only the firast 50 package.
Use the
On Mon, Dec 17, 2001 at 11:54:39PM +0100, Hannes Gredler wrote:
pls find attached a bugfix in order to properly
assert the checksum TLV #12 for artifically
long, and hence stripped frames;
Checked in.
-
This is the TCPDUMP workers list. It is archived at
On Mon, Dec 17, 2001 at 11:35:01AM -0800, Ken Keys wrote:
1) plugs the leak caused by repeated compilation;
It works for your expression
(which used to run out of registers on the 15th compile)
and the expression I'd been testing with
(which used to run out of registers on the 5th
On Sat, Dec 08, 2001 at 07:52:01PM -0800, Guy Harris wrote:
On Sat, Dec 08, 2001 at 02:45:32PM -0700, Phil Wood wrote:
By the way, for some reason when tcpdump quits normally (like after -c
pktcnt)it will not dump the stats. However, if you just let it run
and then break out you get
On Sun, Dec 09, 2001 at 09:42:40PM -0700, Michael Richardson wrote:
Why do we still care if there is native IPv6?
I thought that we now had all of the stuff in the tcpdump packet (headers,
etc.) that we need.
Well, most of them.
I tried getting rid of all the #ifdefs for INET6, but the
On Mon, Dec 24, 2001 at 09:54:13AM -0600, Michael D. Schleif wrote:
I need to compile tcpdump and libpcap or a linux distribution using
kernel 2.2.19 and glibc 2.0. I have built a debian slink system on
which to develop.
I have what I believe to be a workable compile; but, I am confused on
How about adding a pcap_is_packet_waiting() which will perform the test
for you.
The app would call pcap_dispatch() only if
pcap_is_packet_waiting() returns true, and the app can get on with other
things on false.
Arguments could be a pcap_t struct, and perhaps a timeout in
microsecs. It
On Wed, 2002-01-09 at 01:00, Guy Harris wrote:
Are you talking about the bug where polling() a BPF devices won't return
until the device read buffer is full
Yes.
(only happening when linking to libc_r it seem) ?
No. It happens even if you don't link with -lc_r, but as the current
-lc_r
1 - 100 of 600 matches
Mail list logo
