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:
+3
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
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: 20
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
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
Au
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 updating the list of LINKTYP
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
On Dec 22, 2008, at 1:18 PM, Matthias Wenzel wrote:
Guy Harris wrote:
So DECT and DECT 6.0 are close enough that they can use
LINKTYPE_DECT/DLT_DECT?
Yes. DECT has 10 radio channels, DECT 6.0 has 5, they all fit into one
0-63 channel table scheme in ETSI EN 300 175-2, Annex F (mostly
On Dec 23, 2008, at 1:04 AM, Matthias Wenzel wrote:
OK, thanks for clarification, I was thinking about a lower layer
there...
Generally I don't disagree with pulling our stuff in libpcap, but how
could we reflect very DECT-specific settings in the pcap API, such as
setting a radio channel,
On Nov 27, 2008, at 3:49 AM, Jean-Louis wrote:
this means request a new DLT_ value like i.e. DLT_USB_LINUX_MMAPPED,
Yes. I've added DLT_USB_LINUX_MMAP.
add
a new struct in libpcap/pcap/usb.h similar to pcap_usb_header with
last
field for padding i.e.
typedef struct _usb_header_mmapped
On Oct 30, 2008, at 10:25 AM, Tyson Key wrote:
Hi Jean-Louis, just applied the patches and it compiles and installs
successfully.
Still looks like certain packets are being truncated (mostly
URB_ISOCHRONOUS
ones from what I can tell).
Try it with an unpatched top-of-tree libpcap, as well a
On Dec 23, 2008, at 12:39 PM, Guy Harris wrote:
On Nov 27, 2008, at 3:49 AM, Jean-Louis wrote:
this means request a new DLT_ value like i.e. DLT_USB_LINUX_MMAPPED,
Yes. I've added DLT_USB_LINUX_MMAP.
I've renamed it to DLT_USB_LINUX_MMAPPED in the main and 1.0 branches.
On Apr 3, 2007, at 7:42 AM, Jon Smirl wrote:
diff with -u attached
Checked in, with some changes.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Dec 28, 2008, at 5:30 PM, lijx wrote:
The following call is wrong:
--
#!/bin/sh
parameters=" -s 96 \'ip host 192.168.0.80\'"
tcpdump $parameters -n -w /opt/nec/wbmc/tcpdump/file.tmp
The filter expression is not specified w
On Dec 31, 2008, at 9:01 AM, Diego Woitasen wrote:
These two patches apply against libpcap and tcpdump. They add
the feature of print interface names, which is useful when you
use "-i any" to detect weird network/routing problems.
I added the switch -P i
On Dec 30, 2008, at 5:09 AM, Tassadaque Zia wrote:
I want to implement a cross layer approach. i want to pass the network
information such as delay from the MAC layer to Network layer.
Are you talking about doing this in a network-layer protocol
implementation in the Linux kernel (for examp
On Dec 31, 2008, at 7:07 AM, Tassadaque Zia wrote:
Can i calculate per hop delay using pcap liberary using pcap_stats
or with some other function
No.
The only statistics pcap_stats() are those relevant to libpcap, such
as the number of packets dropped when capturing.
To calculate per-ho
On Jan 12, 2009, at 8:44 PM, David Murray wrote:
I am writing an application using the libpcap library that is
capable of caching and replaying frames. I originally wrote and
tested this program using a embedded ALIX system that runs a 500Mhz
Geode processor. I felt that the slow performan
On Jan 12, 2009, at 8:31 PM, David Murray wrote:
Perhaps an important difference between the two systems is that on
the ALIX embedded system, packet injection is happening over a WiFi
NIC whereas on the desktop system packet injection is happening on
the Desktop NIC.
Yes. See my earlier
On Jan 12, 2009, at 9:05 PM, David Murray wrote:
Good point. However, the packets that I am capturing are going
end-to-end and they are being replayed to the same receiver.
Subsequently, the payload size of the frame should be less than 1500.
What *is* the payload size of a frame that's not b
On Jan 12, 2009, at 11:09 PM, liu.yongf...@zte.com.cn wrote:
I use tcpdump to capture the packets of one RTP stream in my rtsp
server,
So you're running tcpdump on the server, trying to capture the traffic
on that RTP stream?
If that's true, what filter are you using when you're capturin
On Jan 15, 2009, at 12:30 PM, Bibudh Lahiri wrote:
Is it a problem with the file itself,
It's a problem of some sort with the file or the packets in the file -
or *possibly* a bug in tcpdump. We'd have to see the file in order to
see what the problem or bug is; were can that file be do
On Jan 15, 2009, at 12:54 PM, Bibudh Lahiri wrote:
I downloaded the file from the following location:
https://data.caida.org/datasets/passive-2008/equinix-chicago/20080319/
I don't have an account, so I can't download the file.
I downloaded the file by simply using the Firefox brow
On Jan 21, 2009, at 10:52 PM, Y, Bhaskarakiran wrote:
I am trying to install Net-Pcap perl module and it required
libpcap-devel package. I have searched on net but could find only
RPM's.
Why is it a problem if you only have RPMs?
Is it because you're not running Linux, or because you're ru
On Jan 22, 2009, at 4:05 PM, Chris Morgan wrote:
Hello.
I wasn't sure if this question was answered anywhere, I've searched
via google and looked on the mailing lists but haven't seen any
answers.
How does one get a ipv6 address from the sockaddr struct pointed to by
pcap_addr?
Welcome to t
On Jan 24, 2009, at 6:36 AM, Andreas Rieke wrote:
I have seen a strange behavior of pcap_next_ex where a buffer is
overwritten. When pcap_next_ex has finished, it returns a buffer for
the
packet header and one for the packet data.
No. pcap_next_ex() returns a pointer to a packet header an
On Jan 24, 2009, at 11:01 AM, Guy Harris wrote:
No. pcap_next_ex() returns a pointer to a packet header and a
pointer to packet data.
These are, in fact, pointers to a structure internal to libpcap and
a buffer internal to libpcap, respectively
Make that "a pointer to a stru
On Jan 27, 2009, at 9:17 AM, Benoit wrote:
I've start a simple protocol to communicate with FPGA using only MAC
layer.
This software should run under linux and windows, however i've a
problem
with the timeout of pcap_next_ex() function under linux.
There is no guarantee that, with a timeo
On Jan 27, 2009, at 4:43 PM, Matthew Luckie wrote:
I think the problems with select on BPF devices on FreeBSD have been
solved for a long time. Certainly on all currently supported
versions of FreeBSD.
I think it's fixed on sufficiently recent versions of all of the
*BSDs, but
1) som
On Jan 27, 2009, at 5:14 PM, Aaron Turner wrote:
What is the solution on *BSD/OS X where you want a timeout
If you want a timeout, in the sense of something that means that
you'll *never* block forever waiting for packets to arrive, then:
if you *only* care about platforms where the time
On Jan 28, 2009, at 1:48 AM, Benoit wrote:
Okay so I should use something like this:
int ret=0;
Assigning 0 to ret isn't necessary, as you're setting it to the return
value of pcap_select_ms() immediately after assigning 0 to it.
if((ret =pcap_select_ms(ifhard->adhandle,ifhard->timeout)
On Jan 29, 2009, at 12:04 PM, Bibudh Lahiri wrote:
I've installed tcpdump 4.0.0 (with libpcap 1.0.0) over Red Hat
Enterprise Linux 2.6.18-128.el5 #1. But when I'm trying to run
tcpdump from my Linux command prompt, I'm getting the following error:
tcpdump: Exec format error. Wrong Ar
On Feb 2, 2009, at 5:39 AM, Johan Mazel wrote:
My problem is that when I'm not running the program as root, I got the
"Erreur de bus" in French (or "Bus Error" in english I guess) and my
program
suddenly stops.
That is either a bug in your program, a bug in libpcap, or a bug in
some othe
On Feb 5, 2009, at 9:03 AM, Tyler Littlefield wrote:
I'm in a college course, which is using a program that is not
working with my screen reader. I am blind, and am using a reader
that takes the text on the screen and reads it in synthasized
speech. There are some programs that don't work
On Feb 6, 2009, at 7:24 AM, David Andrey wrote:
Can 2 threads (in the same process) start each one a sniffing session
on the same interface, but with different filter. Is it safe and
reliable ?
It should work *IF* each thread opens a separate pcap_t for the
interface and sets its own filte
On Feb 9, 2009, at 8:54 AM, David Andrey wrote:
I open two different pcap_t's and become two different handles. The
filter are different, but with low differences ( AND operation on 1
byte).
@Guy
You say that "filters aren't per-thread" ... does it mean that the
second filter "delete" the firs
On Jan 23, 2009, at 4:22 PM, Tron McConnell wrote:
Do you have a suggestion as to how I should resolve this issue?
Try including instead; that's what's in the version at
the top of our Git tree.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 12, 2009, at 12:28 PM, Gisle Vanem wrote:
* Added header-guard.
* Include IP6_misc.h unconditionally (why treat MingW specially?)
Checked in and pushed to the main Git branch.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 12, 2009, at 12:29 PM, Gisle Vanem wrote:
* nametoaddr.c with DECNETLIB defined needs
included. And which again needs .
* Remove "IP6_misc.h" since it's already included in pcap-stdinc.h
(ref. my patch to this file).
Checked in and pushed to the main Git branch.
-
This is the tcpdump
On Feb 6, 2009, at 7:32 AM, Sebastien Roy wrote:
Any input on the OpenSolaris issues I pointed out a few weeks back?
Again, I have a fix that i can provide, but as I haven't contributed
code to libpcap before, a quick primmer on what your process is would
help me out.
Either send a patch to t
On Feb 8, 2009, at 10:13 AM, Marc Weber wrote:
I've had some type missmatch errors caused by int != pcap_t on amd64
The following patch makes it compile.
Unfortunately, it also falsely claims that pcap_activate() returns a
pcap_t *, which it doesn't. It does in pcap-null.c, but that's a bu
On Feb 12, 2009, at 10:19 AM, Lidwa, Eric (GSFC-582.0)[SGT] wrote:
I cannot submit the patch, could somebody please put the fix in.
An different fix was checked in earlier.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
1001 - 1100 of 2496 matches
Mail list logo
