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,
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.ca
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
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
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.
add
a new
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
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 if
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
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
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
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
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
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
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
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
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 structure
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
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)
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
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
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 other
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
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 first
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 linux/if.h 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 netdnet/dnetdb.h
included. And which again needs sys/types.h.
* 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
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
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
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.
On Jan 25, 2009, at 2:05 AM, Andreas Rieke wrote:
I have forgotten to mention that I use libpcap 1.0.0.
...which means that, at least on Linux, libpcap's probably using the
memory-mapped interface...
Since I placed a debug output before and after each call to pcap, I am
very sure that
On Feb 15, 2009, at 9:22 PM, Ambika Tripathy wrote:
Can I use pcap_compile() on a stream which is opened by using
pcap_open_offline().
Yes.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 20, 2009, at 1:46 AM, Johan Mazel wrote:
I'm trying to use libpcap to capture packets on two interfaces (eth0
and
wlan0).
Linux, I presume?
My problem is that packets are only captured in the wlan0 thread.
What happens if you run one instance of tcpdump capturing on wlan0 and
Is there any networking hardware out there that does TCP checksum
generation for outgoing packets but doesn't do IP or UDP checksum
generation? If not, -K might as well imply that IP and UDP
checksums aren't valid for outgoing packets, either.
-
This is the tcpdump-workers list.
Visit
On Feb 22, 2009, at 11:41 AM, Johan Mazel wrote:
What happens if you run one instance of tcpdump capturing on wlan0
and
another instance capturing on eth0? Do they both report packets
being
captured, or does just the one capturing on wlan0 report packets?
Yes, I just checked.
Yes they
On Feb 23, 2009, at 1:29 PM, Aaron Turner wrote:
tcpdump/Wireshark will show you the Linux SLL header.
...although that's not the format of the link-layer header on packets
on the Linux loopback interface; those packets have fake Ethernet
headers.
(The SLL header is synthesized by
On Feb 23, 2009, at 3:14 PM, Oliver Zheng wrote:
How does Libpcap do it then if it's not with raw sockets?
To what does it refer in how does libpcap do it?
If by it you mean capture and send raw link-layer packets, then,
on Linux, it uses a PF_PACKET socket (raw or cooked) rather than a
On Feb 24, 2009, at 9:26 AM, William J Hulley wrote:
Find attached a small patch to print ethernet frames encapsulated
in GRE using the Transparent Ethernet Bridge ethertype (0x6558),
as used in a recent addition to the Linux kernel, gretap.
Checked in and pushed to the main Git branch.
-
On Feb 26, 2009, at 4:49 PM, Pierre Karampournis wrote:
I am currently working in a university lab and I need to capture
packets with a nanosecond precision timestamp using the Pcap format.
There's precision, and there's accuracy. If, for example, the
mechanism that delivers packets to
On Feb 26, 2009, at 5:22 PM, Guy Harris wrote:
The *accuracy* is limited by the fact that most network adapters
aren't designed primarily for use when capturing traffic, so they
don't do their own packet timestamping, and libpcap normally just
plugs into the OS's built-in facilities
On Feb 27, 2009, at 9:03 AM, Pierre KARAMPOURNIS wrote:
I worked on old Linux Kernel versions so I will try the latest ones
to see
hardware timestamping. So now I have to search for Network cards
which can
timestamp the packets with nanosecond resolution (Endace DAG cards can
apparently do
On Mar 3, 2009, at 9:49 AM, Johan Mazel wrote:
Ok, I'm running libpcap 0.9.8-5 on Ubuntu 8.10.
Despite that this function is in the man version of libpcap and that
I don't
have any compilation error, it looks like it's not working since I
have have
a segmentation error each time I try to
On Mar 2, 2009, at 3:42 PM, Giovanni Venturi wrote:
I'm using libpcap 3.9.8. I made a GUI application under KDE that
when I ask to
start sniffing packets from the network, than it starts another
application
(not a GUI) that captures all the packets and write them into a file.
Gee,
On Mar 3, 2009, at 11:06 AM, Guy Harris wrote:
Look at the source of the dumpcap program in Wireshark for an
example of how to do the capture side of that. The secret is that
it doesn't just write to the file and not communicate with the
program on whose behalf it's capturing - every
On Mar 3, 2009, at 3:33 AM, NADEZHDA PLOTNIKOVA wrote:
I am using the following string
WinDump.exe -tt -nnr file.pcap
but the time stamps I am getting in the output text file are in
decimal format.
Yes. Unformatted does not necessarily mean hexadecimal.
Does anyone know how to make it
On Mar 3, 2009, at 6:44 PM, Chris Morgan wrote:
I would be looking for the local adapter mac addresses. Under linux
with pcap and the adapters I have, ethernet and wireless, I see
hardware mac addresses in pcap_if_t.addresses. I wasn't sure if there
were any known cases where
On Mar 4, 2009, at 9:19 AM, Gianluca Varenni wrote:
In the case of Windows/WinPcap, we have an internal Packet API to
get the MAC address, the main problem is exposing such MAC address
at the pcap API level. I actually didn't know that findalldevs was
returning the MAC address on (some
On Feb 20, 2009, at 7:08 PM, Guy Harris wrote:
The tcp in tcpdump is a bit old - people use it for doing more
than just looking at TCP headers these days - and it sounds as if
the problem Torsten Krah had tring to decrypt ipsec traffic was due
to the packets being cut short by a snapshot
On Feb 20, 2009, at 7:10 PM, Guy Harris wrote:
Is there any networking hardware out there that does TCP checksum
generation for outgoing packets but doesn't do IP or UDP checksum
generation? If not, -K might as well imply that IP and UDP
checksums aren't valid for outgoing packets
On Mar 9, 2009, at 4:10 PM, Chris Morgan wrote:
Opening a live capture as root (using sudo), on a vmware bridge device
on Linux 2.6.27, using a timeout of 1000ms. I'm seeing pcap_next() and
pcap_dispatch() getting stuck reading, no timeouts are occurring. Is
there a robust and efficient way of
Chris Morgan wrote:
On Mon, Mar 9, 2009 at 7:51 PM, Guy Harris g...@alum.mit.edu wrote:
Well, the first question is why is blocking forever an issue?
Is the application also going to, for example, accept input from other
sources while it's reading captured packets?
Well I noticed the issue
On Mar 10, 2009, at 9:52 AM, Chris Morgan wrote:
Does mac osx have epoll?
No. It has poll(), but that, as noted, doesn't work with character
special files, such as the BPF devices used for traffic capture in OS
X. (BPF devices *do* work with poll() in *BSD.)
You mentioned that Linux
On Mar 10, 2009, at 5:40 PM, Chris Morgan wrote:
Hmm. Yeah I'll make sure to put in a comment about mac os support.
Note that select() *does* work with BPF devices on OS X - modulo the
traditional BPF bug wherein the timer starts when a read is done,
*not* when a select() is done, so you
On Mar 17, 2009, at 3:33 PM, Shaked, Nitzan wrote:
In general, it's a bad thing to mix buffered IO (stdlib, such as
fread,fread,fseek, etc) with kernel io (read/write/seek/select, etc).
At least when it comes to mixing stdio and select(), it's not a bad
thing, you just have to know what
On Mar 17, 2009, at 4:38 PM, Guy Harris wrote:
If that means that you can't tell the difference between end of
file on the pipe, no more packets available right now, and an
error occurred while reading from the pipe, as might be the case,
file a bug on that.
This will almost certainly
On Mar 19, 2009, at 2:39 AM, Shaked, Nitzan wrote:
2) I believe the current code doesn't have the notion of non-
blocking,
which it doesn't have the notion of I read only part of what was
request, maybe half a packet, or half a header,
...and it would even need that if you got rid of
On Mar 19, 2009, at 4:01 AM, Romain Francoise wrote:
Subject: [PATCH] Change USB device prefix to 'usbmon'
Ethernet USB devices (supported by the usbnet driver in Linux) are
by default named 'usbX', which is also what libpcap uses for its
usbmon pseudo-interfaces. To avoid this namespace
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
I'm trying to work out how to correctly map the DLPI data link
types that are used to each of the relevant DLT's that are
supplied in bpf.h. Some of them are easy, some are repeats,
some not so...
...and some DL_ values appear to have been
On Mar 27, 2009, at 1:45 PM, Darren Reed wrote:
On 27/03/09 11:27 AM, Guy Harris wrote:
On Mar 27, 2009, at 10:58 AM, Darren Reed wrote:
Seriously, for my purposes, it is Cisco HDLC.
So it should be mapped to DLT_C_HDLC.
For the purposes of my table, I'd like to map the mediums
On Mar 27, 2009, at 7:01 PM, Sebastien Roy wrote:
The only hitch is that DL_IPNET devices behave like DLT_RAW by
default.
The DL_IOC_IPNET_INFO ioctl enables the inclusion of the ipnet
header.
The thinking here was that with a tiny modification to libpcap,
existing
applications that
On Mar 29, 2009, at 10:59 PM, Darren Reed wrote:
What I am considering is:
And what Sebastien is suggesting is, I think:
using the DL_IPNET link-layer header for loopback devices, as
documented in the loopback device man page, in your Solaris BPF,
rather than inventing a new header;
On Mar 31, 2009, at 2:42 PM, Tobias Weber wrote:
libpcap comes with Mac OS, but to use it from GUI applications
without changing permissions in /dev is complicated.
Nothing unique about Mac OS X here - the situation on *BSD is the same
(not surprisingly, as *BSD and Mac OS X both use
On Apr 1, 2009, at 8:32 AM, Shameem Ahamed wrote:
In that case also, we should be able to get the source and
destination IP address from the below code
printf(Source IP: %s \n,inet_ntoa(ipHeader-ip_src));
For me it gives me Segmentation Fault.
inet_ntoa() takes a struct in_addr as an
On Apr 1, 2009, at 1:34 PM, Bert Vermeulen wrote:
I've attached a patch that adds a basic USB packet printer for the
Linux
usbmon capture facility. Up until now, only writing to a file was
supported.
Also, if you tried to show a live USB capture, the error message
indicated that the data
On Apr 6, 2009, at 2:52 PM, Diego Valverde wrote:
Is there a way to specify 1 out of every N packets sampling using an
existing filter combination?
No. The filtering mechanism was created in order to filter based on
packet content, and that's all it supports checking.
if not where
On Apr 6, 2009, at 3:53 PM, Guy Harris wrote:
I'm assuming the embedded device is running an operating system such
as Linux, so that packets have to be copied from kernel space to
user space (unless libpcap is using the memory-mapped access
mechanism on Linux or FreeBSD) to be delivered
On Apr 6, 2009, at 4:17 PM, Darren Reed wrote:
What you might be able to do is construct a filter that only matches
Ipv4 packets that have an ipid field that is 0 in base 4.
...if the sampling rate is 4, so that 1 out of 4 packets are processed.
Unfortunately, there's no % operator in the
On Apr 1, 2009, at 1:42 AM, Tobias Weber wrote:
On 01.04.2009, at 00:47, Guy Harris wrote:
A set-UID program that does what privileged stuff it needs to do
(opening a pcap_t,
(what I've seen is using libpcap in the helper tool only and remote
controlling that from the GUI)
Exactly
On Mar 19, 2009, at 5:56 AM, Shaked, Nitzan wrote:
What's next? Realistically speaking, should I hold my breath for those
changes? (Should I implement them and submit a patch?)
Yes. I can't guarantee I'll have time to look at implementing them in
the immediate future.
-
This is the
On Apr 10, 2009, at 8:23 PM, Darren Reed wrote:
The URL below contains the necessary changes for BPF on Solaris to
just work. To summarise, Solaris needs a few extra includes
@ -37,6 +37,12 @@ static const char rcsid[] _U_ =
#include sys/file.h
#include sys/ioctl.h
#include sys/utsname.h
On Apr 12, 2009, at 12:06 AM, Eddie Harari wrote:
802.11 headers there is data field, what it this data field ?
According to IEEE Std 802.11-2007, section 7.1.2 General frame
format, an 802.11 frame has:
a 2-byte frame control field;
a 2-byte duration/ID field;
On Apr 14, 2009, at 8:54 AM, Eddie Harari wrote:
so when i sniff a packet from my monitor mode intel chipset
based wifi
card ,
how do i know which radio info is preceding the 802.11 header ?
The same way that, when you sniff a packet from any network adapter,
you know what link-layer
On Apr 14, 2009, at 9:24 AM, David Young wrote:
On Tue, Apr 14, 2009 at 11:54:50AM -0400, Eddie Harari wrote:
so when i sniff a packet from my monitor mode intel chipset
based wifi
card ,
how do i know which radio info is preceding the 802.11 header ?
The DLT that you have set determines
On Apr 15, 2009, at 2:41 AM, Eddie Harari wrote:
My data link type is 802.11_RADIO,
If you mean DLT_IEEE802_11_RADIO, then that means that the raw packet
data begins with a radiotap header, not an 802.11 header, and the
802.11 header follows the radiotap header.
when i sniff the
On Apr 10, 2009, at 8:23 PM, Darren Reed wrote:
The URL below contains the necessary changes for BPF on Solaris to
just work. To summarise, Solaris needs a few extra includes and for
BPF to be checked before DLPI.
http://www.opensolaris.org/os/community/networking/files/libpcap.diff.gz
I've
On Dec 23, 2008, at 1:57 AM, Matthias Wenzel wrote:
We can't care too much about proprietary extensions, so I suggest just
one LINKTYPE_DECT, and we'll add a metadata field for the band.
Sorry about forgetting about this - I've just checked in a change to
add DLT_DECT/LINKYPE_DECT, both
On Apr 27, 2009, at 8:19 PM, Eddie Harari wrote:
BUGS section:
Filter expressions on fields other than those in 802.11
headers will
not correctly handle 802.11 data packets with both To DS and
From DS
set.
is this only for libpcap programmers ? or also tcpdump users ?
On Apr 27, 2009, at 7:12 AM, Miroslav Lichvar wrote:
I've received a bug report that tcpdump crashes when -i option is
used and there are no interfaces available.
I've checked in a different-but-similar fix.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Apr 28, 2009, at 2:26 AM, Javier Gálvez Guerrero wrote:
I'm trying to catch DHCP Requests/ACK and IEEE 802.11Probe Requests
and
Association ACK packets in a custom C program using libpcap but I'm
facing
some problems when applying filter chains different than simple ones
like
'ether
On May 7, 2009, at 7:34 AM, Javier Gálvez Guerrero wrote:
I want to get the information included in bootp/dhcp packets captured
through tcpdump. I tried adding -v, -vv and -vvv options to the issued
command but all the information I got was like this:
...
I know that more
On May 9, 2009, at 12:42 PM, Julien Iguchi-Cartigny wrote:
The best solution is to use libpcap but It doesn't seem easy. My
first solution was to create my own instance of pcap_t and change
function pointers to my own functions. But on most distribution pcap-
int.h is not available (this
On May 10, 2009, at 7:52 AM, Asier Martínez wrote:
I'm a bit confused in which is the behavior of Libpcap under Linux
when it is used to capture packets.
If I'm not wrong, Libpcap under Linux ignores timeout argument to_ms,
so, Libpcap is returning per captured packet?,
Libpcap, prior to
On May 13, 2009, at 11:38 AM, Johan Mazel wrote:
My program work like this:
-I initialize my process of capture on my network interface (eth0)
through
these 2 functions : pcap_create, pcap_activate (I also use some
function
like pcap_set_timeout, pcap_set_direction but this is not really
On May 13, 2009, at 4:41 PM, Rick wrote:
AIX libpcap 9.8-2 seems to create these when it's loaded. Is there
some way to configure it to create more of these ?
You might have to ask IBM that.
Somebody contributed to tcpdump.org's libpcap code to create those
devices; that code has a
On May 14, 2009, at 7:20 PM, Jefferson Ogata wrote:
But the point of storing the mostly irrelevant zone data as metadata
is so that it can be recorded when pcap timestamps are UTC, as they
always should have been. I'd like to find the person who decided to
store localtime instead of
On May 14, 2009, at 8:23 PM, Andrej van der Zee wrote:
Hi,
2) does, but helpfully converts the time to local time (in
which
case, whoever decided to be helpful needs to be hit with said
sock).
I found that tcpdump with - converts to local time, but tcpdump
-tt report GMT.
On May 13, 2009, at 3:46 PM, Johan Mazel wrote:
My reason of doing this is that I want to be able to aggregate
different
source of packets (eg.: I have eth0, eth1 eth2 and eth3 and I want to
capture on eth0 and eth1 only and build a trace from these
interfaces only).
My goal is to
On May 16, 2009, at 3:18 AM, Johan Mazel wrote:
Does this restriction means that I can't aggregate trace of different
version of Ethernet (eg.: 802.3 and 802.11) ?
(802.11 isn't a version of Ethernet.)
If your 802.11 device supplies fake Ethernet headers, you can
aggregate its packets
On May 16, 2009, at 4:01 AM, Florian Forster wrote:
From: Florian Forster o...@leeloo.lan.home.verplant.org
Especially not to do pointer arithmetic.
This is a real problem even without malicious people around if you use
OLSR via IPv6, because the message IDs didn't change but addresses are
On May 16, 2009, at 3:05 PM, Florian Forster wrote:
From: Florian Forster o...@leeloo.lan.home.verplant.org
Unfortunately OLSR uses the same IDs for IPv4 and IPv6 packets, even
though the size of messages differ. The version of the internet
protocol
is therefore handed to the olsr_print
On Jun 8, 2009, at 4:47 AM, Nikola Ciprich wrote:
I've spent some time playing with tcpdump and pcap with regard
to vlans. Using libpcap 1.0.0 + tcpdump 4.0.0, I can able to
correctly dump packets including (reconstructed) vlan headers.
But it seems that using the vlan filter keyword does not
On Jun 10, 2009, at 11:12 AM, Guy Harris wrote:
There are special hooks in Linux's BPF interpreter to allow
filtering on some data that's not in the packet data; libpcap
already uses that to handle fields in the constructed DLT_LINUX_SLL
header (it generates code assuming the header
On Jun 11, 2009, at 1:12 AM, Nikola Ciprich wrote:
thanks for your replies. OK, I see. I'm pretty ignorant in this area,
so please forgive my maybe dumb questions. So couldn't the solution
be in disabling hw VLAN headers stripping and letting the kernel do
the job for the time of dumping?
If
On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote:
I've noticed this a few times, and got reminded of it again
recently...
It seems that libpcap-devel did something to the get_selectable_fd()
which causes tools that use it to go into a fast spin on select -
the fd
is always 'hot', but
On Jun 24, 2009, at 1:40 PM, Mike Kershaw wrote:
Yes, it's linux, sorry for not including that.
As you might guess, I suspected it was a problem with the memory-
mapped capture stuff in Linux; that and the FreeBSD memory-mapped
capture stuff were the most likely 1.0 changes to cause this,
On Jun 24, 2009, at 9:50 AM, kahou lei wrote:
I would like to request a new DLT value for raw fibre channel. I am
currently working on wireshark to dissect raw fibre channel packet
in data
link layer.
So does raw fibre channel packet mean a packet beginning with the
Frame_Header, e.g.
701 - 800 of 1908 matches
Mail list logo
