On Jul 31, 2008, at 11:11 AM, U. George wrote:
[EMAIL PROTECTED] MyRblsmtpd]# /usr/sbin/tcpdump -n -v -i eth1
pppoes and port domain
tcpdump: syntax error
PPPoE is not in my tcpdump man page :{
To quote my original mail:
If the DNS requests are on PPPoE, then, *at least with a
suffici
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 numbe
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 *" i
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 descr
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.
V
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 VLA
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 B
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 l
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 ->
l
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 pac
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 an
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 t
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
effect
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 19, 2008, at 8:16 PM, Ben Greear wrote:
I noticed that pcap_setdirection doesn't appear to work on Solaris.
Anyone know if it would be possible to get this functionality
implemented?
Libpcap runs atop DLPI in Solaris. In my experience with at least one
version of Solaris, if you
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 indica
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
http://standards.ieee.org/g
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 data,
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 mai
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 https:/
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 the
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
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 filterin
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 pack
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 ne
On Oct 15, 2008, at 6:50 PM, Ken Bantoft wrote:
I uploaded Release Candidate 2 to http://www.tcpdump.org/beta this
evening - please give it a test and make sure it works as you
expect. I'm want to ship it by the end of the month (this time, I
promise!), as it's been stable for quite some
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
(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 don't
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, c
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
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 23, 2008, at 11:34 AM, Ken Bantoft wrote:
I uploaded Release Candidate 3 to http://www.tcpdump.org/beta this
afternoon - only changes since rc2 are Guy's revised man pages for
libpcap - nothing changed in tcpdump (other than the version#).
If there continues to be no complains, I'll
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 'pcap_read_packet
: 2008-08-06 01:29:07 -0700; author: guy; state: Exp; lines:
+13 -4; commitid: XwUjIqsQYkhIGHdt;
Check whether the tpacket_auxdata structure has a tp_vlan_tci member
before using that member.
Don't define variables if we aren't going to use them.
If
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 U
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, and
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 d
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? Cou
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 featur
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.
Visi
e5cd202190b6ce9
Author: Michael Richardson <[EMAIL PROTECTED]>
Date: Sun Nov 9 17:57:45 2008 -0500
replaced CVS/RCS $Header tags with non-active version, leave the
strings in, and SCCS what tags.
commit a46e7e14dbce2eab3ac7383049f09cb52e7b4ed4
Author: guy
Date: Tue Sep 16 18:43:02
On Nov 16, 2008, at 1:09 PM, Giovanni Venturi wrote:
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:
can't create rx ring on packet socket 4: 92-Protocol not available
What does it mean?
It means that
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 t
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 indicated
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': No
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 attachme
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 when
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 list
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
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 wh
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 tcpdump-work
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 lis
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 updat
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 tcpdump-w
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, NU
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 crashe
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
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 ur
On Nov 24, 2008, at 10:53 AM, Guy Harris wrote:
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 cap
On Oct 29, 2008, at 7:29 PM, Jean-Louis wrote:
*** pcap-usb-linux.c29 Oct 2008 14:17:44 - 1.2
--- pcap-usb-linux.c29 Oct 2008 15:03:27 - 1.3
***
*** 67,78
#define USB_LINE_LEN 4096
- #define PIPE_IN 0x80
- #define PIPE_ISOCHRON
On Oct 29, 2008, at 7:32 PM, Jean-Louis wrote:
in "text mode" ther'is direction check, I don't know how I can use
this "filter", but the check is broken
It can only be used by calling pcap_setdirection() in an application.
I don't know what the motivation is for inverting the direction on
On Oct 29, 2008, at 7:35 PM, Jean-Louis wrote:
Added possibility to set "snaplen" also in "mmap mode"
Checked in (with a variable name change to make it clear that the
variable in question is the maximum length).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubs
On Oct 29, 2008, at 7:38 PM, Jean-Louis wrote:
in accordance with usbmon.txt in "mmap mode" the data is at
&mmap_area[vec[i]] + 64;
rather than
&mmap_area[vec[i]] + 48;
with mmap ther'is 16Byte filled with 0 first to the real data...
so if i.e. I have caplen = 18Byte, in file.pcap I have 1
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_PA
On Nov 26, 2008, at 8:51 PM, Harald Welte wrote:
please make that LINKTYPE_GSMTAP_UM and LINKTYPE_GSMTAP_ABIS in
order to
indicate that all messages will be prefixed by a 'gsmtap' header,
before the actual payload in the Um / Abis format.
DLT_GSMTAP_UM/LINKTYPE_GSMTAP_UM: 217
DLT_GSMTAP_A
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 year
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 DL
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" tha
On Dec 17, 2008, at 12:18 PM, Matthew Luckie wrote:
could -s become a parameter that takes words as well as numbers, and
have the compiler return the appropriate number of bytes in each
case?. so -s udphdr -s tcphdr would return 14 + 20 + 8 for UDP
packets on ethernet,
Not all link laye
On Dec 17, 2008, at 12:43 PM, Dustin Spicuzza wrote:
... as long as you trust that the header
values are ok (making sure that they stay in the bounds of the actual
packet size).
Don't do that. Check against the incoming caplen, and check the
sanity of length fields.
-
This is the tcpdump-
On Dec 17, 2008, at 2:30 PM, Dustin Spicuzza wrote:
Speaking of which, is there something in tcpdump that can figure out
how
long the header is... I see that the printers figure out this
information, but its not done separately as far as I can see.
No, it's not.
If you could have the vario
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
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 new
On Dec 21, 2008, at 1:25 AM, Gianluca Varenni wrote:
When I run it, I get
./a.out: error while loading shared libraries: libpcap.so.1: cannot
open shared object file: No such file or directory
I'm not an expert about linux shared objects, maybe I'm doing
something wrong.
I'm not, eith
On Dec 21, 2008, at 2:50 AM, Michele Marchetto wrote:
Il giorno ven, 19/12/2008 alle 17.04 -0800, Guy Harris ha scritto:
Just one label, or a full stack?
Just one label.
OK, I've assigned 219 as DLT_MPLS/LINKTYPE_MPLS.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.c
On Dec 22, 2008, at 1:51 AM, Matthias Wenzel wrote:
we have a set of opensource tools that read and write pcap files
from/to
DECT devices. The SW will go public still this year. We're working
with
both gnuradio USRP and a dedicated HW.
Could the code to capture DECT traffic go into libpca
On Dec 22, 2008, at 1:58 PM, Matthias Wenzel wrote:
I just had a look, and thanks for pointing me there. But that seems
very
device independant. To me it seems its a generic way to record URBs
on a
USB bus in pcap, but correct me if I am wrong.
I think he meant to look at it as an example
1001 - 1100 of 2513 matches
Mail list logo
