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 no
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
a
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 length.
Would it make sense to have tcpdump d
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 htt
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" the
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 libpc
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 t
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.
-
Th
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 li
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
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 1, 2009, at 6:36 AM, Romain Francoise wrote:
The new formatting carelessly removed this check and put
it inside the block only, meaning that seqno won't be
printed at all unless at least -v -v are given.
Checked into the main Git branch.
Signed-off-by: Ilpo Järvinen
I've converted
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 la
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, there's
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'
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 i
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 pcap_if_t.address
On Mar 3, 2009, at 7:33 PM, Chris Morgan wrote:
Right. I had to look at the sa_family value to differentiate the two
under linux but I don't believe windows even has the same values for
sa_family.
The numerical values don't matter *if* you have the same #defined AF_
name for the family in w
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 fla
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
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
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 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
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 yo
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,
fil
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 buf
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 conf
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 rese
On Mar 26, 2009, at 6:47 PM, Darren Reed wrote:
On 26/03/09 05:23 PM, Guy Harris wrote:
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
{ DL_HDLC, DLT_HDLC }, /* ISO HDLC protocol support */
"HDLC" is a catch-all term for various types of networking, usually
me
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 that have
passed (or are passing) from active use to "unsupported" and call it
DLT_UNSUP (0xfff
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 t
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 unde
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 BPF),
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 lin
On Mar 25, 2009, at 6:49 PM, Ken Bantoft wrote:
Fixed in git... was missing from CSRC list on in Makefile.in
Actually, the right list for it is HDR, as it's a header file (a
"make" appeared to try to compile it). I've moved it.
-
This is the tcpdump-workers list.
Visit https://cod.sandelm
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 shoul
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 deli
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 6, 2009, at 5:02 PM, Diego Valverde wrote:
When you say implement the filtering in the kenerl, you mean for
example
hooking mad-wifi to some custom made module that passes only the
packets
matching the 1:N criteria, ie. not using libpcap, or you mean
modifying
exisitng libpcap ker
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)
Ex
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 tcpdu
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
#include
#include
+#ifdef HAVE_SYS_FCNTL_H
+#includ
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 determin
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 packet
On Apr 15, 2009, at 11:19 AM, Eddie Harari wrote:
how come 22 bytes offset with no Qos ?
in the case both are not set (TO DS and From DS ) then Address 1 is
destination , adress 2 is source and address 3 is bssid , so there
are
18bytes of addresses,
There are 18 bytes of address, *but* wh
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'v
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 wit
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 ?
tcpdu
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 dst
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 information
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 fi
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 1.0,
On May 12, 2009, at 7:05 AM, Michael Richardson wrote:
What is "AOS"?
Advanced Orbiting Systems, according to
http://public.ccsds.org/publications/archive/732x0b1s.pdf
and
http://standards.gsfc.nasa.gov/reviews/450-502/450-502.pdf
-
This is the tcpdump-workers list.
Visit h
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 3:04 PM, Eddie Harari wrote:
Byte 1 is version
byte 2 is pad
and byte 3-4 is length of radiotap in bytes right ?
Right.
does this info sit in offset 0 of the data i get when i am sniffing ?
At offset 0 of the data you get from libpcap is the version byte.
At offset 1
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 #defi
On May 14, 2009, at 5:41 PM, Andrej van der Zee wrote:
I am having a problem with the timestamps in .cap files. I receive
.cap files captured on machines in a different timezone (GMT +1 or GMT
+3). When I do a "tcpdump -r en0.cap -n -" then the timestamps
are corrected to my local timezon
On May 14, 2009, at 6:10 PM, Andrej van der Zee wrote:
Thanks a lot for your email. I wish .cap files stored some
meta-information such as local timezone, IP address, etc.
pcap-NG:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html
can store a 4-byte "Time zone for GMT suppo
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 gmtime
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 15, 2009, at 12:43 AM, Jefferson Ogata wrote:
This has come up before, back when we were talking about the NG
format.
I guess I got confused by the current context; if pcap files are
natively UTC (which I had thought they were until this thread arose,
seeming to suggest they weren't),
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 aggregate
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 wi
On May 16, 2009, at 10:32 AM, Johan Mazel wrote:
I suppose that the values for linktype are the ones I'm talking in
my first
mail : 01 for Ethernet, 06 for Token Ring, 07 for ARCnet, etc... ???
Libpcap has two sets of link-layer type values - the DLT_ values,
which are what are returned b
On May 14, 2009, at 11:58 AM, Pierre KARAMPOURNIS wrote:
Furthermore, if we try to use tools using libpcap to read nsec-pcap
files,
it won't work
What should "work" mean?
It can't mean "supply time stamps with nanosecond precision", as that
would break source and binary compatibility. T
On May 16, 2009, at 4:01 AM, Florian Forster wrote:
From: Florian Forster
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
now longer than four bytes.
Check
On May 16, 2009, at 3:05 PM, Florian Forster wrote:
From: Florian Forster
The function does the same as `mask2plen' but for IPv6.
Checked into the main branch and pushed. (Again, --whitespace=fix
needed.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe
On May 16, 2009, at 3:05 PM, Florian Forster wrote:
From: Florian Forster
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" function.
The code isn't very n
On May 26, 2009, at 6:22 AM, Francois-Xavier Le Bail wrote:
Here is a patch to do that.
Checked into the main Git branch.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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 w
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 he
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 18, 2009, at 11:30 PM, Lakshmana Reddy wrote:
I walked through the tcpdump/pcap code to see what going on.. so far
my
understanding is that the pcap_loop(), to capture the packets on the
given
device invokes the recvfrom() sys call to get the raw packets from the
kernel and parses th
On Jun 23, 2009, at 6:44 PM, Jenny Guo wrote:
Does anyone know why "any" is no longer supported in libpcap 1.0.0?
Because there's a bug in libpcap 1.0.0.
Is there a way to make "tshark -i any" work?
Try installing and building with the "current development version" of
libpcap from Git;
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 there
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.
On Jun 3, 2009, at 12:47 PM, Sam Roberts wrote:
Wireless HART is a wireless industrial control protocol that uses the
IEEE 802.15.4 physical layer, but_ NOT_ the IEEE data-link layer.
The encapsulation consists of the entire data-link PDU (similar to
802_15_4).
The spec is available for a
On Jul 1, 2009, at 12:04 PM, Behdad Forghani wrote:
Gianluca asked me to forward this to the mailing list. During
Sharkfest09 he had mentioned that Winpcap cannot is not re-entrant
and thread-safe because Lex uses global variables. As you can see,
one solution to this is to use re2c for le
On Jun 24, 2009, at 2:21 PM, Guy Harris wrote:
...does this happen with standard 1.0? If not, this might be a side-
effect of a bug fix in top-of-tree - it turns out that you are *not*
finished with a packet when the callback returns; consider how
pcap_next() and pcap_next_ex() are
On Jun 29, 2009, at 6:35 PM, kahou lei wrote:
Yes, the packet starts with the R_CTL field.
OK, so I've assigned 224 to DLT_FC_2 (as it's for Fibre Channel FC-2
frames).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jul 6, 2009, at 9:39 AM, Dragos Ilie wrote:
I traced the issue to pcap-linux.c:pcap_read_linux_mmap(), which is
the
read handler selected when HAVE_PACKET_RING is defined. The handler
calls poll() with a negative value, which means an infinite timeout.
This occurs when the libpcap variable
On Jul 6, 2009, at 11:08 AM, Dragos Ilie wrote:
My application is not setting the timeout. This corresponds to the
case
where p->md.timeout == 0. The function pcap_setnonblock_mmap first
checks the nonblock flag and if it is set *and* if p->md.timeout > 0
it
maps the value to p->md.timeou
On Jul 8, 2009, at 6:22 AM, Peter Volkov wrote:
Hi. libpcap currently links with libnl if it exists on the system.
Attached patch makes it user configurable: by default it'll do the
same
but in case user requested --with/--without-libnl it will force to
link
with or without libnl. Please,
On Jul 9, 2009, at 3:34 PM, Gianluca Varenni wrote:
This actually makes sense to me (I actually have the same problem
with WinPcap, and I do ship the generated files in the WinPcap
source package). Are there any cons to this?
The only potential risk would be if the version of Flex or Bison
On Jul 10, 2009, at 2:16 AM, Varjonen Samu wrote:
+/* supports only hex print, modified from print_int64 in print-
nfs.c */
+static void
+hip_print_int64_hex (const u_int32_t *dp, int hostorder)
+{
+#ifdef INT64_FORMAT
+u_int64_t res;
+
+ if (hostorder)
+ res = ((u_
On Jul 10, 2009, at 2:16 AM, Varjonen Samu wrote:
diff -N -r -u --strip-trailing-cr tcpdump-orig/configure.in tcpdump/
configure.in
--- tcpdump-orig/configure.in 2009-05-20 11:29:46.0 +0300
+++ tcpdump/configure.in2009-05-17 13:13:13.0 +0300
@@ -158,7 +158,7 @@
--di
pcap_next() and pcap_next_ex() rely on the packet data pointer handed
to their pcap_dispatch() callback still pointing to the same packet
data after the callback returns.
If the packet data is being read into a buffer with read()/getmsg()/
recvfrom()/etc., that works.
If, however, the pack
On Jul 10, 2009, at 3:35 PM, Gianluca Varenni wrote:
I just discovered an interesting leak with the libpcap 1.0 or the
current top-of-tree.
On Fedora 10, kernel 2.6.27.5 or 2.6.27.12, there is a memory leak
by which a simple program like this one will eventually use all the
memory on the
On Jul 10, 2009, at 5:09 PM, Gianluca Varenni wrote:
I think the routine usb_cleanup_linux_mmap(pcap_t* handle) should be
modified as follows:
...
I'm not too happy about querying again the fd for the RING_SIZE (it
should be stored in the pcap_t structure), but I tried it on my VM
On Jul 13, 2009, at 11:59 PM, Chandru S wrote:
1)When I use pcap funcions for a single time it is working fine.But
when we run a batch of traffic testcases for many hours It is
dumping(segmentation fault) .Also core files gives us a indication
that it happens mostly in PCAP functions such
On Jul 14, 2009, at 9:05 AM, Dustin Spicuzza wrote:
I'd like to get information on how much of the mmap'ed ring buffer is
being used so that I can deal with dropped packets more effectively. I
was going to add a patch for this, but its not clear to me the best
way
to expose the information.
1101 - 1200 of 2521 matches
Mail list logo
