sufei7099 wrote:
I add the #incudesys/types.h in file.h,
I.e., you changed /usr/include/sys/file.h to include sys/types.h?
Does /usr/include/sys/param.h include sys/types.h on your system?
then i make successfully. After i run make install, the result is :
# make install
Bruce Keats wrote:
I have a program that is listening on a radio tap interface that is using
libpcap. It occasionally changes the BPF something like ether host
xx:xx:xx:xx:xx:xx.
...which presumably means it calls pcap_compile() more than once.
Is there a fix for this issue?
Yes:
sherin hagag wrote:
i m student in IGSR in egypt ,i prepare master in streaming
multimedia,i want to ask if tcpdump could be installed on windows
The version of tcpdump compiled for Windows is called WinDump:
http://www.winpcap.org/windump/install/default.htm
Before you install
Tassadaque Zia wrote:
I am using libpcap. I want to perform a task as packet arrive on
network interface. which method of libpap should i use to capture the
packet arrival event
Libpcap doesn't deliver events, it delivers packets.
Therefore, you should just read packets with, for example,
Ignacio, Domingo Jr Ostria - igndo001 wrote:
I inserted a new variable, srtt, into the print_tcp.h header file and
tcp.c source code.
(Presumably you meant tcp.h header file and print-tcp.c source code.)
If you inserted it into the struct tcphdr structure, that's a mistake.
That
On Jul 1, 2008, at 4:32 PM, grarpamp wrote:
Hi. Surely it is not possible to have both 'no flags' and
any_other_flags present at the same time? The man page has a few
references to the dot, particularly in the 'OUTPUT FORMAT - TCP
Packets' example near 'means no flags'.
The man page
grarpamp wrote:
Hi. I think I've found this 'none' printf you speak of.
More precisely it's a none argument passed to bittok2str_nosep() plus the
else {
/* bummer - lets print the unknown message as advised in
the fmt string if we got one */
if (fmt == NULL)
grarpamp wrote:
Hi. Patch inline. I conformed the naming to the RFC's
I assume by naming you are referring not only to the bits used to
print the flags in tcpdump but also the flag values used in libpcap for
filters.
Perhaps a name using the psh abbreviation used by RFC 793 for the
push
On Jul 7, 2008, at 11:04 AM, Jacek Jablonski wrote:
I applied such filter to my sniffer:
tcp and port 8071
The problem is that, outgoing packets are fine, they are captured one
time, but incoming packets are captured twice and they are interpreted
two times.
Does that happen if you *don't*
On Jul 8, 2008, at 3:33 AM, Milosz Marian Hulboj wrote:
I know that it is not possible to use pcap_stats when reading data
from a savefile.
That's because the statistics aren't recorded in the savefile.
I can count the packets returned by the pcap_next_ex, but if I
applied a filter, this
On Jul 13, 2008, at 10:01 PM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
Is there a filter command where we can only specify to capture
specifically the sequence number of a tcp packet header?
If you want to capture packets with a particular value of the sequence
number, try
On Jul 15, 2008, at 12:57 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
I try to modify print-tcp.c and tcp.h source code and header file file
of tcpdump-3.9.8 to include a new option which is th_srtt, a
variable I
added to my linux kernel protocol stacks.
Where did you add that
On Jul 16, 2008, at 12:09 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
Or 2. When the tcpdump do the packet capture, is it looking/utilizing
the kernel variables within the protocol stacks or it is operating
independently from the kernel?
It is *not* utilizing kernel variables in the
On Jul 16, 2008, at 1:08 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
I inspected and studied the linux kernel source codes, tcp_input.c,
tcp_ouput.c, tcp_ipv4.c and tcp.c and it is only on the tcp_input
source
code where there is a provision on TCP options to be added.
No, the
On Jul 16, 2008, at 5:10 AM, Patrick McHardy wrote:
This patch adds support to libpcap to retrieve the tag from
the auxillary data and reconstruct the original VLAN header,
solving a major complaint about the way Linux handles VLAN
offloading.
Unfortunately both the website and CVS is down,
On Jul 30, 2008, at 2:12 PM, Stephen Donnelly wrote:
I recently came across some packets which tcpdump appears to display
incorrectly.
Is tcpdump incorrectly invoking some heuristic dissector, or is there
another reason?
I guess that's what I'd call it.
tcpdump assumes that packets to or
On Jul 31, 2008, at 5:52 AM, U. George wrote:
BUT if i remove the 'port domain' i see all the packets:
[EMAIL PROTECTED] gat]# /usr/sbin/tcpdump -v -n -i eth1 tcpdump:
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
08:49:38.834343 PPPoE [ses 0xea20] [length 48 (4
On Jul 31, 2008, at 10:48 AM, U. George wrote:
why does adding the PORT conditional also modify the wild-card
aspects of ethernet type
To what wild-card aspects of 'ethernet type' are you referring?
If you say port domain, that can only match TCP or UDP packets,
which means it can only
On Jul 31, 2008, at 11:29 AM, U. George wrote:
if i say this:
tcpdump -n -v -i eth1
i get a log of: ether type * and port *, ie the PPPoE data.
What you get is a log of *, i.e. all data. port * is irrelevant;
not all packets that would match ether type * *HAVE* a port number.
On Jul 31, 2008, at 8:53 PM, U. George wrote:
Guy Harris wrote:
On Jul 31, 2008, at 11:29 AM, U. George wrote:
if i say this:
tcpdump -n -v -i eth1
i get a log of: ether type * and port *, ie the PPPoE data.
What you get is a log of *, i.e. all data. port * is irrelevant;
Not so
On Aug 1, 2008, at 12:36 AM, Gert Doering wrote:
On Thu, Jul 31, 2008 at 11:53:27PM -0400, U. George wrote:
Without a detailed study, on my part, I am unable to jump to that
conclusion.
There is nothing to study here, or any conclusion to jump to.
Guy has described the way tcpdump
On Jul 18, 2008, at 10:53 AM, Patrick McHardy wrote:
Please keep me CCed since I'm not subscribed to the list.
commit 6f5556e515578c3e034b176562633987e85782e5
Author: Patrick McHardy [EMAIL PROTECTED]
Date: Fri Jul 18 19:22:52 2008 +0200
pcap-linux: fix invalid rcvbuf size
Libpcap
On Jul 18, 2008, at 11:07 AM, Patrick McHardy wrote:
pcap-linux: reconstruct VLAN header from PACKET_AUXDATA
From: Patrick McHardy [EMAIL PROTECTED]
VLAN packets sent over devices supporting VLAN tagging/stripping in
hardwaredon't have a VLAN header when they are received on packet
sockets.
On Jul 18, 2008, at 11:07 AM, Patrick McHardy wrote:
pcap-linux: convert to recvmsg()
From: Patrick McHardy [EMAIL PROTECTED]
Convert pcap-linux to use recvmsg() as preparation for using
PACKET_AUXDATA
cmsgs.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
On Jul 18, 2008, at 11:08 AM, Patrick McHardy wrote:
pcap-linux: support new tpacket frame header format
From: Patrick McHardy [EMAIL PROTECTED]
The tpacket_hdr is not clean for 64 bit kernel/32 bit userspace and
is not extendable because the struct sockaddr_ll following it is
expected at a
On Jul 18, 2008, at 11:08 AM, Patrick McHardy wrote:
pcap-linux: reconstruct VLAN headers from tpacket2_hdr
From: Patrick McHardy [EMAIL PROTECTED]
Similar to PACKET_AUXDATA for non-mmaped sockets, the VLAN TCI is
present in a new member of struct tpacket2_hdr. Use it to reconstruct
the VLAN
On Jul 18, 2008, at 11:06 AM, Patrick McHardy wrote:
The patches are compile-time and run-time compatible with
old headers and kernels.
After applying the patches, libpcap didn't compile on my vanilla
Ubuntu 7.10 virtual machine, as the tpacket_auxdata structure didn't
have a tp_vlan_tci
On Aug 12, 2008, at 12:05 AM, Francois-Xavier Le Bail wrote:
Try :
tcpdump -r xx log_ftp
less log_ftp
Or just
tcpdump -r xx | less
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Sep 8, 2008, at 6:27 AM, lei wei wrote:
By unacceptable, I mean the number of packets that tcpdump
processed was
only a fraction
of that of it received. I assume that Number of Packets received by
filter
are the packets were
matched by the filter expression,
No.
On systems with BPF
On Sep 9, 2008, at 9:17 AM, lei wei wrote:
Thanks a lot for the reply Guy! According to your explanation, for
libpcap, the status struct:
struct pcap_stat {
u_int ps_recv;/* number of packets received */
u_int ps_drop;/* number of packets dropped */
the ps_recv
On Sep 9, 2008, at 7:02 PM, lei wei wrote:
I'm trying to capture packets from two network interfaces on FreeBSD
using
pcap. From what I read about,
a -i any can be used on Linux to capture from all interfaces. But
FreeBSD
doesnt seem to recognize it.
BPF devices, unlike Linux PF_PACKET
On Sep 9, 2008, at 10:21 PM, Munish Dayal wrote:
I have built Wireshark from source on my Linux RHEL 4 system, that
has libpcap version 0.8.3 installed.
But when I try to run this Wireshark on a Linux system with RHEL 5
(libpcap version 0.9.4), I get an error:
error while loading shared
On Sep 10, 2008, at 4:20 AM, Munish Dayal wrote:
ls -l /usr/lib/libpcap.*
-rw-r--r-- 1 root root 242398 Jul 13 2006 /usr/lib/libpcap.a
lrwxrwxrwx 1 root root 16 Sep 10 16:24 /usr/lib/libpcap.so -
libpcap.so.0.9.4
lrwxrwxrwx 1 root root 16 Jul 9 17:21 /usr/lib/libpcap.so.0 -
On Sep 15, 2008, at 2:05 PM, Dmitry wrote:
Test one:
I've opened dump with wireshark.
Found stream, filtered it out and saved raw data to file 'dump.hex'
What do you mean by raw data? Do you mean raw *binary* data, or raw
data as a hex dump?
And did you save the raw contents of the
On Sep 12, 2008, at 6:30 AM, Christian Peron wrote:
I have included a patch for review. This adds zero-copy bpf support
to libpcap. It should be noted that I've tried to incorporate all
the feedback that I recieved after the previous submission.
Looks good.
I've checked it into the main
On Sep 16, 2008, at 1:00 AM, Guy Harris wrote:
Also, note that there's an API to set the buffer size; perhaps, if
that API was called - i.e., if p-opt.buffer_size is non-zero - it
should set the mapped buffer size based on that.
I've checked in code that should handle that, and also
On Sep 17, 2008, at 2:26 PM, Robert Edmonds wrote:
the comparison succeeds because the large unsigned k-value for this
instruction (0xfff0) is much larger than the number of remaining
bpf
instructions (flen-pc-1).
It's so large, in fact, that its high-order bit is set - so, in
On Sep 18, 2008, at 8:23 PM, Robert Edmonds wrote:
right, but the LSF filter validation code treats it as unsigned.
Doesn't matter - whether the problem is that the branch goes too far
forward, or goes backward, it's not something the kernel can accept
(and we're talking about a 1-sphere
On Sep 18, 2008, at 3:23 PM, arun chhetri wrote:
Can, you guys please tell me how to parse a tcpdump dump file with C+
+.
Use libpcap to read packets from the dump file.
That will give you the raw contents of the packets. Parsing the raw
packet data is left as an exercise to the reader.
On Sep 20, 2008, at 8:42 AM, Ben Greear wrote:
To be a bridge, you have to receive all traffic, so disabling
PROMISC isn't really an option as far as I can tell.
Oh, well. A quick look at the GLD driver in OpenSolaris (/usr/src/uts/
common/io/gld.c; see cvs.opensolaris.org) seems to
On Sep 21, 2008, at 9:18 AM, осьмилис wrote:
I would like to request a new DLT value for 802.15.4 Low rate wireless
personal area networks that will represent packets at PHY level, as
specified
in http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf and
On Sep 22, 2008, at 2:54 AM, Макс Филиппов wrote:
No ASK PHY, only those described in 2003's standard.
So the packet's data will begin with 4 octets of 0 (the preamble),
followed by one octet of SFD, followed by one octet of frame length +
one reserved bit, followed by the MAC-layer
On Sep 22, 2008, at 10:47 AM, Max Filippov wrote:
So the packet's data will begin with 4 octets of 0 (the preamble),
followed by one octet of SFD, followed by one octet of frame length +
one reserved bit, followed by the MAC-layer data, starting with the
2-
octet frame control field?-
Yes,
On Sep 22, 2008, at 8:30 AM, Gisle Vanem wrote:
bzero() and bcopy() are not universally available. But
memset() and memcpy() are AFAICS.
Yes - they're in the ANSI C standard, so if you don't have them you're
using a really old crufty platform.
Attached diffs-5.txt.
Checked into the
On Sep 23, 2008, at 9:01 AM, lei wei wrote:
I mean if there's no traffic currently from the interface, will
tcpdump keep
reading from it until traffic comes?
Yes (or until you interrupt it with ^C or whatever your interrupt
character is).
-
This is the tcpdump-workers list.
Visit
On Sep 25, 2008, at 12:31 AM, Munish Dayal wrote:
I am still facing this problem. Any suggestions?
Do I have to downgrade the libpcap from version 0.9.4 to 0.8.3 on
RHEL-5 system, in order to be able to run Wireshark on it.
(Wireshark rpm built on RHEL-4 system).
Or build Wireshark on
On Oct 3, 2008, at 12:43 PM, Rodrigo Roldan wrote:
I am trying put a label into tcpdump code for identify different
interfaces when i run tcpdump -i any..
Libpcap does not, when capturing on the any device, supply any
indication of the interface on which a packet arrived.
(Note also that
On Oct 7, 2008, at 1:07 PM, Jim Mellander wrote:
All of the above are attempts to overcome the 'one filter per
interface
per process' model that I believe libpcap imposes - or am I wrong? Is
there something I've overlooked?
Depends on what you mean by imposes.
If you want to do filtering
On Oct 7, 2008, at 1:07 PM, Jim Mellander wrote:
All of the above are attempts to overcome the 'one filter per
interface
per process' model that I believe libpcap imposes
So why does it need overcoming? A filter says only deliver me
packets that match the following; would multiple
On Oct 14, 2008, at 9:30 AM, Max Laier wrote:
Depends on the platform you are on. On FreeBSD all you need is read
write
permission to the /dev/bpf* devices.
Also true in NetBSD, OpenBSD, DragonFly BSD, Mac OS X, and, I think,
AIX. (And, at least with some versions of libpcap, all you
On Oct 16, 2008, at 1:06 AM, Guy Harris wrote:
Note to Linux distributions and *BSD systems that include libpcap:
There's now a rule to make a shared library, which should work on
Linux and *BSD (and OS X).
It sets the soname of the library to libpcap.so.1; this is what
it should
(Gerald, you're on tcpdump-workers
On Oct 16, 2008, at 11:32 AM, Phil Vandry wrote:
On Thu, Oct 16, 2008 at 09:07:17AM -0700, Gerald Combs wrote:
Debian and Ubuntu have the following entry in /etc/mime.types:
application/cap cap pcap
It's a start but I
On Oct 16, 2008, at 12:16 PM, Michael Richardson wrote:
Thanks Guy for bringing the shared object support in.
Actually, somebody else contributed the initial shared object support,
which you checked in:
revision 1.97
date: 2003-11-29 20:45:02 -0800; author: mcr; state: Exp; lines:
On Oct 16, 2008, at 12:39 PM, Guy Harris wrote:
(Gerald, you're on tcpdump-workers
(Ignore randomness; I wasn't sure why you were CCed on Phil's
response, but you presumably wouldn't have seen his original message
if you weren't on tcpdump-workers.
Michael, can non-members of tcpdump
On Oct 16, 2008, at 6:34 PM, Phil Vandry wrote:
I was thinking it would belong in the standard tree (RFC4288 3.1).
This
requires writing an RFC.
At least as I read RFC 4288, that applies only to proposals that come
from the IETF; all that's needed is *some* published standard:
4.10.
On Oct 17, 2008, at 4:31 AM, Ken Bantoft wrote:
Yes, it should - I'll put it in for rc3, along with anything else.
I want 4.0.0/1.0.0 released by Halloween... preferably before!
So presumably there will be bug-fix dot-dot releases, such as
4.0.1/1.0.1, 4.0.2/1.0.2, etc..
What would the
On Oct 16, 2008, at 1:13 PM, Tyler J. Wagner wrote:
On Thursday 16 October 2008 20:39:39 Guy Harris wrote:
I've considered biting the bullet and writing up a pcap(5) man page,
as part of libpcap. Libpcap 1.0 will probably come out later this
month, so perhaps it's time to write it.
Do you
On Oct 24, 2008, at 2:59 AM, Tyler J. Wagner wrote:
It sounds as if Guy beat me to it. :)
...although if there's something you think should be changed or added,
send us a patch for it.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Oct 27, 2008, at 6:28 PM, Michael Richardson wrote:
I tried building the library before signing it:
marajade-[Misc/tcpdump/4.0/libpcap-1.0.0] mcr 1039 %make
gcc -O2 -fPIC -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused)) -
c ./pcap-linux.c
./pcap-linux.c: In function
On Oct 27, 2008, at 6:52 PM, Ken Bantoft wrote:
I tried a few different boxes, and have the same issue.
Ubuntu 8.x box builds it with no problems,
Debian 3.1 and CentOS 4 fail with the same error Michael gets.
Maybe r1.90 on pcap-linux.c ?
More like one of
revision 1.156
date:
On Oct 28, 2008, at 2:05 PM, Tyson Key wrote:
Hi, nice to see a shiny new release of libpcap and tcpdump so soon.
Out of interest, is the tcpdump: unsupported data link type
USB_LINUX
bug/issue resolved when trying to capture USB traffic on a Linux box?
If you mean if I try to capture USB
On Oct 29, 2008, at 8:49 AM, [EMAIL PROTECTED] wrote:
Is there a pcap function that will allow me to view the ip addresses
(sending and receiving) of a packet
No. Libpcap doesn't interpret the packet contents; you will have to
do the same thing that tcpdump, Wireshark, Snort, etc. do,
On Oct 29, 2008, at 10:48 AM, Tyson Key wrote:
It seems to work fine now, although I could probably do with
automatically
setting the snaplen somehow.
I.e., defaulting to the maximum (65535) rather than the current
default of 64 (without IPv6) or 96 (with IPv6)?
At least one OS that
On Oct 29, 2008, at 1:16 PM, Tyson Key wrote:
Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
although I'm not sure exactly what to blame) to truncate large
numbers of
USB packets? (I assume this has been hashed to death on the list in
the
past, though).
Paolo?
On Nov 5, 2008, at 10:29 PM, Michael Richardson wrote:
Applied to new git tree.
So the official tree is now in git (i.e., all changes should be
checked into git)?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Nov 8, 2008, at 7:05 PM, David Gibson wrote:
I have a work-in-progress patch to allow libpcap to capture events
from the Linux input layer's evdev interface (/dev/input/event*).
Later I plan to add a wireshark dissector for the packet format.
First, does this seem like a reasonable feature
On Nov 5, 2008, at 8:45 PM, Michael Richardson wrote:
git-cvsimport did a very good job of dealing with all the branches.
git branch lists only a branch master; did the CVS branches turn
into Git branches? The release tags turned into Git tags.
-
This is the tcpdump-workers list.
Visit
On Nov 5, 2008, at 8:45 PM, Michael Richardson wrote:
okay. I did a:
git-cvsimport
on both libpcap and tcpdump.
Unless I'm missing something, a lot of the history seems to have
gotten lost. For example, git log pcap-bpf.c shows:
commit a9ff5b3dcf3eb90f519c70b4be5cd202190b6ce9
On Nov 16, 2008, at 2:11 PM, Guy Harris wrote:
4) somehow that causes pcap_open_live() to fail, rather than just
falling back on reading from the PF_PACKET socket in the normal
fashion.
If so, that's a libpcap bug; I'll try debugging it.
pcap_open_live() doesn't seem to be failing
On Nov 17, 2008, at 10:27 AM, Giovanni Venturi wrote:
memory-mapped capture support? I guess that this is used in libpcap
1.0.0,
right?
It's supported by libpcap 1.0.0, but not *required* by libpcap 1.0.0.
What kernel option do I have to check?
CONFIG_PACKET_MMAP.
However, as
On Nov 16, 2008, at 1:28 PM, Giovanni Venturi wrote:
Hello,
I'm the author of ksniffer a GUI interface under KDE 3 to capture
network
packet.
Till libpcap 1.0.0 (the last stable you released) all was ok in
the packet
capture, but now I get the following error message:
This appears to
On Nov 4, 2008, at 10:14 AM, Peter Volkov wrote:
make DESTIDR=/tmp/libpcap install
fails with the following error:
/usr/bin/install -c pcap-config /tmp/test/home/pva/work/local/bin/
pcap-config
/usr/bin/install: cannot create regular file `/tmp/test/home/pva/
work/local/bin/pcap-config':
On Nov 5, 2008, at 10:29 PM, Michael Richardson wrote:
Peter == Peter Volkov [EMAIL PROTECTED] writes:
Peter Hello.
Peter Currently SITA will be defined and sita code will be tried
to
Peter build even if --without-sita is passed to ./configure. Patch
Peter in attachment
On Nov 4, 2008, at 10:49 AM, Peter Volkov wrote:
Currently if there are bluetooth.h headers installed in the system
libpcap will be built with bluetooth support and it's impossible to
disable it. Attached patch adds --{en,dis}able-bluetooth switches.
So what's the reason for disabling it
On Nov 4, 2008, at 10:58 AM, Peter Volkov wrote:
Currently make install in libpcap never installs pcap/
{vlan,bluetooth}.h
headers. Attached patch makes it install them in case support was
built
in into libpcap.
Checked into the main and 1.0 CVS branches.
-
This is the tcpdump-workers
On Nov 7, 2008, at 10:28 AM, Michael Richardson wrote:
Peter == Peter Volkov [EMAIL PROTECTED] writes:
Peter Hello.
Peter tcpdump-4.0.0 fails to build with --disable-ipv6. Patch to
Peter fix the issue is in attachment.
I've applied your fix to the git tree,
Propagated to the
On Nov 9, 2008, at 5:34 PM, Michael Richardson wrote:
Peter == Peter Volkov [EMAIL PROTECTED] writes:
Peter Currently it's impossible to build tcpdump without libsmi on
Peter system with libsmi installed. The patch in attachment adds
Peter --with{,out}-smi configure switch which
On Nov 11, 2008, at 5:49 AM, Gabor Z. Papp wrote:
Compiling tcpdump 4.0.0 without ipv6 - linking against ipv6less
libpcap too - generates the following error:
Peter Volkov's fix (same as your fix) has been checked into the git
tree and the main and 4.0 CVS trees.
-
This is the
On Nov 13, 2008, at 3:57 PM, David Gibson wrote:
Did this go past on the list (I can't see it on gmane), or has that
gone into a tree somwhere (I can't see it on the default CVS branch)?
It was only in git; I've propagated it to the main and 1.0 CVS branches.
-
This is the tcpdump-workers
On Nov 14, 2008, at 7:08 PM, Michael Richardson wrote:
No, I actually hadn't allocated it or commited it until I wrote the
email to see if the text made sense.Guy hadn't allocated one, so I
did. I'm actually not certain that I did it right.
You did, although updating the list of
On Nov 18, 2008, at 1:26 AM, Peter Volkov wrote:
This helps to test build/runtime of libpcap without bluetooth on
systems
with bluetooth.h installed.
I.e., it's for cross-building?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Nov 17, 2008, at 3:24 PM, Giovanni Venturi wrote:
int result = 9;
result = pcap_next_ex(m_pcapfp, hdr, (const u_char **)p);
Sometimes I get 9, sometimes I get 1, ...
How can it be possible that the return value doesn't change result
variable?
If you *truly* set a variable to, say, 9,
On Nov 18, 2008, at 1:06 PM, Giovanni Venturi wrote:
I don't have hardware problem, so we have just the second
possibility. I used
gcc (GCC) 4.2.4 . What compiler have you used to compile libpcap
1.0.0?
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
-
This is the
On Nov 17, 2008, at 1:46 PM, Giovanni Venturi wrote:
To make the pcap_next/pcap_ex non blocking under Linux I use:
FD_ZERO(m_fdset);
FD_SET(m_pcap_fd, m_fdset);
m_fdtimeout.tv_sec = 0;
m_fdtimeout.tv_usec = CAP_READ_TIMEOUT*1000;
selRet = select(m_pcap_fd+1, m_fdset, NULL,
On Nov 17, 2008, at 3:15 PM, Giovanni Venturi wrote:
just block told me that:
SIOCGIFHWADDR: No such device
I've checked a fix for this into the main and 1.0 CVS branches.
If I use NULL no block tell me that there is a problem. I got crash on
(FD_SET):
Crash meaning your program
On Nov 19, 2008, at 9:43 AM, Giovanni Venturi wrote:
Alle mercoledì 19 novembre 2008, Guy Harris ha scritto:
I've checked a fix for this into the main and 1.0 CVS branches.
Mmm. If you can... Can you send me a patch against 1.0.0 version?
I've attached it to this message.
Yes my
On Nov 19, 2008, at 3:17 PM, Giovanni Venturi wrote:
I don't find it. Maybe you forget to attach it? :)
Sorry - here it is:
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Nov 23, 2008, at 9:52 AM, rmkml wrote:
I have a little pb when I compile tcpdump v4.0.0 with libpcap v1.0.0
on FreeBSD v7.0 Release without IPv6.
That should already be fixed in the top of the main and 4.0 CVS
branches - try checking out with -rtcpdump_4_0 from anonymous CVS.
At some
On Oct 29, 2008, at 7:27 PM, Jean-Louis wrote:
transfer direction in text mode is broken...
in accordance with usbmon.txt transfer direction is in
endpoint_number rather than transfer type
ther'is premature stop when capture traffic on linux with text
mode due to incorrect check of urb
On Nov 24, 2008, at 1:27 PM, Tyson Key wrote:
Hi, any chance that a usbany (or similar) pseudo-device could be
added in
a future version to capture on all USB buses, similar to the
standard any
device for non-USB interfaces?
The any device works in Linux because you can open a PF_PACKET
On Dec 1, 2008, at 9:08 AM, Albert Chin wrote:
pcap-dlpi.c in pcap_activate_dlpi() conditionalizes the `ss' variable:
#ifdef HAVE_SYS_BUFMOD_H
bpf_u_int32 ss;
but then uses it unconditionalized:
ss = p-snapshot;
Patch attached.
Checked into the main and 1.0 branches (with an additional
On Dec 1, 2008, at 9:16 AM, Albert Chin wrote:
pcap_activate_snoop() in pcap-snoop.c uses the variable `handle' to
access opt.buffer_size instead of what it should, `p'.
if (handle-opt.buffer_size != 0)
v = handle-opt.buffer_size;
Patch attached.
Checked into the main and 1.0 branches.
On Dec 1, 2008, at 9:18 AM, Albert Chin wrote:
dlpisubs.c uses `DL_IPATM' and `MAXDLBUF' but doesn't define them like
in pcap-dlpi.c if unavailable. This is a problem for Solaris 2.6 and
HP-UX.
Patch attached.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
Visit
On Dec 11, 2008, at 12:26 PM, Michael Richardson wrote:
application/pcap-capture
makes more sense to me.
Yes:
1) .pcap is sometimes used as a suffix, but I've not seen .libpcap;
2) on Windows, it's called WinPcap;
3) not all pcap-format files are written by
On Dec 11, 2008, at 6:38 PM, Jefferson Ogata wrote:
I agree. For one thing, another MIME type might eventually exist for
filter specifications. It is not sufficient to describe a capture
file as simply pcap.
But what I think is missing is a version number. Given the talk in
recent years
On Dec 12, 2008, at 5:02 PM, Jefferson Ogata wrote:
I still think current and ng pcap formats should be distinguished
in MIME type name.
So do I, which is why I said it'd be something such as application/
pcap-ng-capture.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/
On Dec 10, 2008, at 10:02 AM, Ken Bantoft wrote:
Request for another DLT value - see below.
On 10-Dec-08, at 1:58 PM, Michele Marchetto wrote:
Hi ken.
I'm the openbsd developer who is coding the support for mpls.
We need to set up a virtual interface mpe(4), and we
would like to have the
On Dec 17, 2008, at 11:10 AM, Dustin Spicuzza wrote:
Is there currently a way to save protocol headers (and by this, I mean
ARP/IP/TCP/UDP/ICMP headers) to a file *without* the remaining
payload?
There's no way to do *exactly* that.
You can, however, specify a snapshot length with -s that
On Dec 15, 2008, at 3:15 AM, Michele Marchetto wrote:
Il giorno dom, 14/12/2008 alle 17.43 -0800, Guy Harris ha scritto:
What will the lowest-level header (link-level header) for the mpe
interface's packets be?
It will be a standard MPLS Shim header.
Just one label, or a full stack
On Dec 15, 2008, at 1:25 PM, Bjoern Hoehrmann wrote:
You might want to consider using a IANA
registry for the `network` field, but that shouldn't be necessary.
If we used an IANA registry (akin to the snoop datalink types
registry), would that require us to go through the IANA to assign
601 - 700 of 1903 matches
Mail list logo
