On Sep 15, 2007, at 8:01 PM, Jonathan Leffler wrote:
I ended up with a successful compile (under GCC and Sun C) by hacking
config.h, denying that any of the RPC features was present:
What if you instead *don't* hack config.h, leaving it believing you
have getrpcbynumber, but just remove the
On Sep 7, 2007, at 1:23 AM, Abeni Paolo wrote:
following the discussion about the missing direction information in
bluetooth H4 captures(see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1751)
, I would like to request a new DLT type for a modified bluetooth
linktype.
I'm planning to
On Aug 24, 2007, at 2:33 PM, Luis EG Ontanon wrote:
Hi,
I Need to register two DLTs they would be:
DLT_MTP2_MULTISTANDARD
that will have a one byte pseudo header of which the MS bit indicates
the direction the next three bits are reserved and must be set to zero
in writing the last nibble is u
On Sep 19, 2007, at 12:09 AM, Abeni Paolo wrote:
Thanks! The attached patch used the newly added DLT for hci h4
frames, adding an informative header to each frame.
The header carries (in the first bit in network byte order) the
direction bit for the associated frame and nothing else.
It also
On Sep 19, 2007, at 1:33 AM, Luis EG Ontanon wrote:
On 9/19/07, Guy Harris <[EMAIL PROTECTED]> wrote:
Is a capture likely to have a mix of packets for different MTP3
standards? And are there likely to be more types in the future?
I got few text dumps containing a mix of china and it
On Sep 19, 2007, at 11:49 PM, Varuna De Silva wrote:
I tried to compile a program which includes pcap-int.h,
Why is the program including an internal libpcap file that's *NOT*
part of the official libpcap/WinPcap interface?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca
On Sep 20, 2007, at 5:37 AM, Paolo Abeni wrote:
Hopefully this time the attachment should be plain text and avoiding
strange MS encoding.
Yup, it worked.
Checked in, along with updates to FILES and INSTALL.txt.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscrib
Varuna De Silva wrote:
> 1. what is really meant by the callback routine, what does it do? How
> should I write this function?where should this be written. please be kind
> to guide me to starting place. my idea is that it is the higher layer sw
> which makes use of libpcap.
Yes, the callback fun
On Sep 23, 2007, at 9:08 PM, Varuna De Silva wrote:
On 9/23/07, Guy Harris <[EMAIL PROTECTED]> wrote:
If you're modifying libpcap to support a new type of capture, you
don't
write the callback function,
I am doing this for my device to be supported by wireshark. As I
un
On Sep 24, 2007, at 11:25 AM, Eygene Ryabinkin wrote:
OpenBSD 4.1 introduced an incompatible change to their pflog device
packet header:
...and didn't introduce a new DLT_ value.
It appears that FreeBSD will be doing the same for 7.0, so we just
gave up and said "no pflog dissection except
On Sep 22, 2007, at 12:37 AM, Varuna De Silva wrote:
This is the program pcap-xxx.c which includes in it xxx_open_live()
in it.
That's not a "program" in the sense of an executable program; it's
something you're adding to libpcap, so it's allowed to include pcap-
int.h.
I've checked in
On Sep 24, 2007, at 1:15 AM, Paolo Abeni wrote:
The attached patch is my first attempt to add support to tcpdump for a
'new' DLT (exists in libpcap head, but is currently unknown to
tcpdump).
It print some basic information (hci frame direction) regarding
bluetooth capture.
Checked into the m
On Sep 25, 2007, at 4:33 AM, Varuna De Silva wrote:
1. How should I work around so that pcap_findalldevs() will add my
device in
the list?
If you're doing this on Windows, you will have to:
modify pcap_findalldevs() in fad-win32.c to, right before it does
if (ret =
Varuna De Silva wrote:
> Next I removed the following part from the above code, and the build
> succeeded.
> if (pcap_add_if(alldevsp, "any", 0, any_descr, errbuf) < 0)
> return (-1);
>
> Is this process acceptable of me removing the above part?
Yes. That code is specific to Linux, which
On Sep 25, 2007, at 6:19 AM, Varuna De Silva wrote:
Hello,
I am trying to add support for my device in libpcap(/winpcap) and I
have
some
doubts regarding the xxx_read() function in the pcap-xxx.c file. This
function is there
for the packets to be read in, as I understand. For a previous rep
Varuna De Silva wrote:
> And when we use this FT_Read(), we wait and read in 3968 bytes at a time
So, presumably, if the device has more than 3968 bytes available, only the
first 3968 bytes are read?
What if it has fewer than 3968 bytes available? Does the read return only
what's available?
If
On Oct 1, 2007, at 2:13 AM, Varuna De Silva wrote:
What if it has fewer than 3968 bytes available? Does the read
return only what's available?
It waits checking until it receives 3968 bytes and then read it in
Will it wait forever? If so, that might be a problem if fewer than
3968 byte
On Oct 4, 2007, at 1:58 PM, Stephen Donnelly wrote:
Unmatched parenthesis.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Oct 4, 2007, at 3:06 PM, Stephen Donnelly wrote:
The attached patch includes:
* Improved error checking in dag_read().
* More efficient dag_platform_finddevs().
* Support for new DAG API function dag_get_stream_erf_types().
* Fix to pcap/pcap.h mismatched parenthesis.
On Oct 2, 2007, at 5:42 AM, Luis Martin Garcia wrote:
I enclose two simple patches to update the "last updated" date of the
manpages.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 19, 2007, at 12:07 PM, Stephen Donnelly wrote:
It seems that if it is worth making the change, it is also worth
using a
couple of bits to indicate whether a 16 or 32-bit CRC/FCS is present
as
Guy suggested. This could then be used on linktypes such as PPP_SERIAL
which can have
On Apr 3, 2007, at 2:57 PM, Richard Stearn wrote:
Guy Harris wrote:
pcap-linux.c could map ARPHRD_AX25 to DLT_AX25_KISS, which means AX.
25 captures done on Linux will have a file type of DLT_AX25_KISS.
As in:
declare DLT_AX25_KISS as X
and change:
pcap-linux.c
1140 case
On Oct 5, 2007, at 3:35 PM, sagun shakya wrote:
Improvements after adding support to libpcap:
-
* Observe all IP layer network traffic, including loopback, IPMP
group, IP tunnel traffic and IP layer network traffic flowing to and
from a zone.
Th
On Oct 9, 2007, at 9:12 AM, Gerrit Renker wrote:
having submitted three patches last year on this list which were
accepted but
apparently never made it into the repository,
No, Hannes Gredler checked them into the main branch near at the end
of 2006 - and acknowledged at least two of them
On Oct 10, 2007, at 1:20 AM, Gerrit Renker wrote:
So what happens next - I think that the bug fix should go to the
other branches
as well, since the tool prints the wrong values.
The only relevant branch is the x.9 branch (the other branches are
dead; nobody's going to make an 0.7.x relea
On Oct 19, 2007, at 9:15 AM, Fulko Hew wrote:
Attached is patch file for enabling DLT_SITA support in libpcap.
(so that it can be included in the imminent 1.0 release.)
Checked into the main and 1.0 branches.
Was there a namespace collision with a PPC in some SITA header file?
The PPC in
On Oct 18, 2007, at 9:32 PM, Varuna De Silva wrote:
Hello,
We are trying to decode raw LAPD messages tapped from a
E1 line, with wireshark.
So you're getting, for example, one of the E1's timeslots, which has
an ISDN D channel on it? And the packet data starts with the 2
address octets,
Varuna De Silva wrote:
Yes, Exactly. This is the version LAPD running between two, PABX's.
OK, I've assigned the value 203 to DLT_LAPD.
Note that "the packet data starts with the 2 address octets" means that
the packet contains no indication of whether it's a user-to-network or
network-to-u
Fulko Hew wrote:
Rats! I see it used in one spot in tcpdump/print-atm.c
and it seems that atmuni31.h is also included as part of tcpdump.
So I guess it needs to be changed in that CVS too.
Can you take care of that?
I've preceded all the #defines of VCI values in atmuni31.h with VCI_,
and u
On Oct 24, 2007, at 8:44 AM, Thomas King wrote:
I use libpcap 0.9.7 as provided by openSuSE 10.3. The problem I face
is
exemplified in the source code I attached to this email. The source
code is
an artificially created example to pin-point the problem I have.
Everything
works create unti
Gianluca Varenni wrote:
the attached patch fixes some of the problems in the current wlan code
generation of pcap_compile.
In particular it should fix these problems:
1. the 802.11 header size of a data frame has not a fixed size. When the
QoS bit is set in the subtype field (QoS DATA frame),
On Oct 30, 2007, at 3:42 AM, Guy Harris wrote:
I won't be able to fix that tonight, but, if we delay the release a
couple of days, I might be able to fix that.
Actually, a combination of a brain spasm (see the time above - that
was local time...), a possible watch misconfigur
Guy Harris wrote:
On Oct 30, 2007, at 3:42 AM, Guy Harris wrote:
I won't be able to fix that tonight, but, if we delay the release a
couple of days, I might be able to fix that.
Actually, a combination of a brain spasm (see the time above - that was
local time...), a possible
On Nov 5, 2007, at 2:49 PM, Gianluca Varenni wrote:
I plan to compare this with the old version with the three possible
link layers (bare 802.11, radiotap, PPI)
Actually, there are also 802.11+Prism radio header and 802.11+AVS
radio header; I have some captures with, I think, all of those
Gianluca Varenni wrote:
I think I found the problem:
Yup, I just discovered that myself.
I've checked in a change that fixes it to do
(000) ldb [3]
(001) lsh #8
(002) tax
(003) ldb [2]
(004) or x
(005) st M[0]
(006) tax
(007) txa
(008) add #24
(009) st M
Gianluca Varenni wrote:
I already noticed that the new BPF code doesn't check the
link-type in the PPI header properly: the check against the linktype
should be done before checking if the frame is a data frame.
Should any packets with a linktype other than DLT_IEEE802_11_RADIO pass
the filt
Gianluca Varenni wrote:
Theoretically, PPI supports multiple linktypes, so we should generate
code for some(all?) link types. However at the moment PPI is used only
for 802.11 packets with AirPcap, so when I patched the BPF compiler I
decided to implement support for DLT_IEEE802_11 over PPI
(
On Nov 7, 2007, at 5:36 AM, [EMAIL PROTECTED] wrote:
I have got tcpdump 3.9.8 and I would like to use -K option.
Unfortunately it is not supported. Do I need install additional
packets?
Is my version to old?
Yes. It's only in the main and 4.0 branches, not in any of the x.9
branches, so
On Nov 14, 2007, at 10:57 AM, Barry Reinhold wrote:
I am attempting to use libpcap to capture Bluetooth exchanges
(DLT_BLUETOOTH)
Presumably you mean DLT_BLUETOOTH_HCI_H4 or
DLT_BLUETOOTH_HCI_H4_WITH_PHDR; there is no DLT_BLUETOOTH with that
name.
and am working with the head of the cv
Barry Reinhold wrote:
I just want to confirm that installing the bluez-libs-devel-3.7-1.i386 rpm
(built on Fedora 6) worked on CentOS 5 and resolved the problem.
I should have caught the clue in config.log - that was an explicit message
that had the needed information, however, I appreciate the
sagun shakya wrote:
I have developed a prototype with the option 1 proposed. I would like to
hear from you if you have any comments or feedback.
The changes made to the libpcap library can be seen at the link below:
http://cr.opensolaris.org/~sagun/libpcap/
Unless you expect there to be syste
Saikiran Madugula wrote:
From the tcpdump configure options I could not see a facility to
specify libpcap includes and library directories. Is there a way to
dynamically
link tcpdump against a libpcap.so* ?
Yes. Build on a system that already has a dynamic libpcap library
(which means it's
Max Laier wrote:
this problem was reported by Giorgos Keramidas as a FreeBSD PR.
When dumpping from a file (-r) hitting ^T (sending SIGINFO) results in an
endless stream of "pcap_stats: Statistics aren't available from
savefiles". The attached patch should fix this and other possible error
Max Laier wrote:
I'm not sure that's the best sollution. For one, libpcap could choose to
implement pcap_stats for files later on.
Most of the statistics would be meaningless unless the capture file has
packet drop, etc. statistics in it - libpcap format doesn't support
that, although pcap-
Mohan Lal Jangir wrote:
How can I capture "only wrong checksum packets" using tcpdump (specially
wrong udp checksum)?
Unfortunately, there's no way to do so with an unmodified tcpdump.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Will Barker wrote:
Please may I request some additional libpcap DLT_ values? I need these to
map onto the following wiretap values:
1. WTAP_ENCAP_PPP_WITH_PHDR
2. WTAP_ENCAP_CHDLC_WITH_PHDR
3. WTAP_ENCAP_FRELAY_WITH_PHDR
4. WTAP_ENCAP_LAPB
What is the format of the extra in
Gregor Maier wrote:
the attached patch fixes a small inconsistency in pcap.3: The original
manpages reads: "NOTE: errbuf in ...".
pcap_open_dead() is listed in the 'list of cunction', however,
pcap_open_dead() doesn't take an errbuf argument.
Checked into the main and 1.0 branches.
-
This is
Alexey Neyman wrote:
The format of the capture is a 5-byte pseudo header followed by the
actual I2C data. The MS bit of 1st byte of pseudo-header indicates
whether the packet contains data or is an event detected on the I2C
controller. The remaining 7 bits contain the minor number of the I2C
Will Barker wrote:
What is the format of the extra information you'll be putting at the
beginning of the {PPP, Cisco HDLC, Frame Relay, LAPB} packets to hold
the packet direction? (Number of bytes, values to be put there, etc.)
It should just be akin to the pseudo header used for generic p2p
v rakesh wrote:
It was said that dumping in pcap format is very easy but I
wasnt able to be so.
Dumping in pcap format is *very* easy if you use libpcap, rather than
writing your own code to dump it. Have you tried, for example, doing
pcap_t *p;
pcap_dumper_t *d;
p
Paolo Abeni wrote:
the attached patch, which was originally provided by Kris Katterjohn
([EMAIL PROTECTED]) via the web interface, fix a couple of
wrong return code check in the usbmon parsing.
Can you please give it a review ?!?
I'll assume your review was sufficient, as you wrote the orig
On Dec 5, 2007, at 5:18 AM, Andy Howell wrote:
I'm using pcap_dispatch to call my callback. Inside the callback, I
may set a new filter. This results in a core dump in bpf_filter.c,
line 239. Its calling abort because of a bad filter code. This will
only happen with a live capture.
The b
slots. The right way to do this is to provide a
general interface to set the buffering size (WinPcap has a system-
specific extension) but the problem in the past has been that some
systems, like *BSD, require the buffer size to be set when opening
the underlying (in this case, BPF) device.
Gianluca Varenni wrote:
why not using a different return value instead of a string message which
is human readable but not easily computer readable?
Probably because that's the way that other pcap APIs work. That doesn't
mean it's the *right* way to work, it just means it fits in with the wa
Will Barker wrote:
So either approach should be OK - the latter being a bit more flexible. Is
there no general preference in this regard? Or (non-formalised?) standard
approach generally adopted now in the libpcap/wireshark world?
There is no standard approach, nor any generally-adopted approa
Paolo Abeni wrote:
the attached trivial patch fix a couple of typos in the comments of
pcap-usb-linux.c.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
Any comments on this matter or on the patch are very welcome !
If, in pcap_open_live(), live_open_mmap() succeeds,
handle->selectable_fd doesn't get set.
This will break, among other programs, the current version of Wireshark,
and the upcoming version of Wireshark. (A s
Abeni Paolo wrote:
Yes, they can be used. The USB capture use a character device which implement
the poll interface.
My main concern is with mmapped access. Presumably, with mmapped
access, there are still system calls that move a "these packets have
been read" pointer and that block until
On Dec 19, 2007, at 11:09 AM, Bill Richardson wrote:
Looking at the one system that works I see it is related to Vlan
tagging:
Is the "test.pcap" file the same file in all three examples?
If so, does the "From ..." at the end of the command indicate the
machine on which you're running tcpd
On Dec 18, 2007, at 2:46 AM, Will Barker wrote:
OK - can we go for:
"zero means received, non-zero means sent"
...and 4 bytes long, as per the earlier discussion, or just 1 byte (or
2 bytes)?
Hopefully by "version-specific" you don't mean "specific to the
versions
of libpcap and Wiresh
Bill Richardson wrote:
With that I mind I wonder what F5 did to
libpcap to get tcpdump to work? They must have made some changes?
What happens if you do
tcpdump -r test.pcap -nn host 172.21.89.75 -d
on the BigIP?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to
Bill Richardson wrote:
From BigIP
tcpdump -r test.pcap -nn host 172.21.89.75 -d
...
As I suspected, they appear to interpret "host XXX" as "host XXX or
(vlan and host XXX)".
That has the advantage that it works with both untagged and VLAN-tagged
packets.
It has the disadvantag
[EMAIL PROTECTED] wrote:
checking for libpcap... yes
checking for pcap_datalink_val_to_description in -lpcap... no
What does the config.log file for ettercap say? The tests in configure
scripts are a bit tricky to get right.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca
On Dec 21, 2007, at 2:47 PM, [EMAIL PROTECTED] wrote:
Undefined first referenced
symbol in file
pcap_lex/usr/lib/libpcap.a(grammar.o)
lex_cleanup /usr/lib/libpcap.a(gencode.o)
lex_init
On Dec 20, 2007, at 4:30 AM, Will Barker wrote:
...and 4 bytes long, as per the earlier discussion, or just 1 byte
(or
2 bytes)?
We may as well make it just 1 byte since it only can specify 2
alternative
values!
OK, I added:
DLT_PPP_WITH_DIR204 /* PPP */
DL
[EMAIL PROTECTED] wrote:
Here is the output from that command:
/usr/lib/libpcap.a[gencode.o]: 00 U lex_cleanup
/usr/lib/libpcap.a[gencode.o]: 00 U lex_init
/usr/lib/libpcap.a[grammar.o]: 00 U pcap_lex
What does
ar t /usr/lib/libpcap.a
print?
-
This is the
[EMAIL PROTECTED] wrote:
Here's the table of contents:
...
scanner.o
What does
nm -pA usr/lib/libpcap.a | egrep 'scanner\.o'
print?
And what was the output of the configure script, and the build process,
for libpcap?
-
This is the tcpdump-workers list.
Visit https:/
Alexey Neyman wrote:
They bit values are not specific themselves (e.g. status bits
include "Controller lost attachment to bus", "Controller had
promiscuous mode set/cleared", etc) - most likely, these bits will be
available on different OS, too. However, the definitions of these
status bits m
[EMAIL PROTECTED] wrote:
On Sat, 22 Dec 2007, Guy Harris wrote:
And what was the output of the configure script, and the build
process, for libpcap?
You want the entirety of config.log?
That would be more than I need - and I also need the output of the build
process; something
Alexey Neyman wrote:
It can be used for any other I2C-based bus, though we only use it to
capture IPMB traffic. The capture utility is agnostic of the traffic
type - so traffic type is not present in the pseudo-header.
So if it were to be used for other I2C-based buses, would the
expectation
Alexey Neyman wrote:
If you think that choosing the type of protocol in reading application
is not enough - well, let's call it DLT_IPMB_LINUX; we'll add the
ability to select the DLT_ value in the capture utility.
Well, that would have the advantage that files are self-identifying. If
the
Alexey Neyman wrote:
Okay, I am convinced. Let it be DLT_IPMB_LINUX then.
OK, I've added it, with the value 209.
(Note that there's also a DLT_IPMB, in which the packet begins with the
I2C slave address, followed by the netFn and LUN, etc.; presumably yours
is different.)
-
This is the tcp
[EMAIL PROTECTED] wrote:
flex -Ppcap_ -t scanner.l > $$.scanner.c; mv $$.scanner.c scanner.c
scanner.l:84: bad character: %
scanner.l:84: unknown error processing section 1
scanner.l:84: unknown error processing section 1
scanner.l:84: bad character: 1
scanner.l:84: bad character: 8
scanner.l:84
[EMAIL PROTECTED] wrote:
On Sat, 22 Dec 2007, Guy Harris wrote:
What does the command "flex --version" print?
flex 2.5.34
And what does the command
sed -n 84l scanner.l
print, when run in the libpcap source directory?
%a 18400
Try upgrading to Flex 2.5.33 from Flex 2.5
Jonathan Gruenhut wrote:
I’m working on an AIX 5.3, and trying to compile a shared libpcap library
(version 0.9.8).
If you're using the source code from tcpdump.org, without any
modifications, no support is in that source code for building shared
libraries on AIX. The person who contributed
Paolo Abeni wrote:
The attached patch is the third revision of my attempt to enable memory
mapped access to ethernet devices under Linux. I tried to address some
of the major concerns emerged in the past days.
Printing a message to the standard error and exiting if ring corruption
is found is
Luca Deri wrote:
My patch also adds support for PF_RING
(http://www.ntop.org/PF_RING.html) that is a Linux packet acceleration
technique that uses a shared ring buffer between the kernel and
user-space. In addition to packet acceleration, it features also packet
filtering and classification.
Luca Deri wrote:
My patch also adds support for PF_RING
(http://www.ntop.org/PF_RING.html) that is a Linux packet acceleration
technique that uses a shared ring buffer between the kernel and
user-space.
I seem to remember an earlier PF_RING paper that said that an interface
doing PF_RING c
Gregor Maier wrote:
I'm afraid, but I think your patch has a race condition under (at least
under Linux). In Linux two syscalls are required to read a packet.
Unless I'm misinterpreting socket(7), at least on Linux systems with the
SO_TIMESTAMP socket option, you can set that option and use r
Guy Harris wrote:
Unless I'm misinterpreting socket(7), at least on Linux systems with the
SO_TIMESTAMP socket option, you can set that option and use recvmsg() to
read a packet; the control message for the packet will contain the time
stamp.
...although that doesn't address th
Luca Deri wrote:
This function is the same as pcap_next with the difference that a buffer
+ buffersize is added. This allows libpcap not to use the shared buffer
(e.g. allocated in pcap_open_xxx) so that replacing in applications
calls of pcap_next with calls to pcap_next_pkt adds reentrancy w
Paolo Abeni wrote:
- in the previous version of the patch, the capture snapshot was
incorrectly bound to 0x; this don't happen any more.
Presumably if pcap_open_live() supplies a very large snapshot length,
the attempt to allocate the ring buffer will fail if the ring buffer
would be to
Ravindranath, Chavalam wrote:
When I tried a single instance of tcpdump, it worked fine, and I don't
even have to specify the interface I want to monitor.
When I left this first instance running and started another one, I got
the message "tcpdump: no suitable device found". According to the
info
Luca Deri wrote:
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
You might want to split the PF_RING support and the reentrancy changes
into two patches.
I have enclosed the patch for PF_RING.
I've checked in Paolo Abeni's patch for memory-mapped PF_PACKET access;
your pat
Paolo Abeni wrote:
In this revision I try to handle the issues pinpointed by Guy Harris in
his previous posts.
OK, I've checked the patch into the main and 1.0 branches, with some
small typoes fixed in comments.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.c
Luca Deri wrote:
Yes it will work correctly as when the PF_RING socket is open, the call
will fail and the library will fall back to standard pcap.
...in which case it will
1) do getsockopt(handle->fd, 0, PACKET_STATISTICS, &kstats, &len) on
the PF_PACKET socket rather than doing getsockopt
Fulko Hew wrote:
I think the code is better when its more
obvious, segregated and less intrusive.
I've checked into the main and 1.0 branches changes to make it even more
segregated and less intrusive. If pcap-linux.c was compiled with SITA
support, very little of the regular Linux capture
Luca Deri wrote:
your comments are very valuable: thanks. I have enclosed a new patch
that should address all of them.
It's still not a context or unified diff, and I've subsequently made
some changes to pcap-linux.c to move the SITA support code into
pcap-sita.c, so the patch didn't apply c
Joerg Mayer wrote:
Sometimes I find patches that I was sure I had sent ages ago. This is
one of them - updated to current cvs.
Move the pcap filter syntax into its own manpage.
I've checked that into the main and 1.0 branches, with some edits, along
with updates to:
FILES - list the
lei wei wrote:
When I was compiling libpcap0.9.8 with DAG-enabled, it gave me an error as
follows:
gcc -O2 -I. -I/usr/local/dag/include -DHAVE_CONFIG_H
-D_U_="__attribute__((unused))" -c ./pcap-dag.c
./pcap-dag.c: In function `dag_open_live':
./pcap-dag.c:721: error: `p' undeclared (first use
Fulko Hew wrote:
On one hand, my version queries and interoperates with remote
devices to allow remote capture. What it does do (unfortunately
right now) is ignore any 'local' linux monitorable devices. It would
be nice to be able to monitor/select either remote (SITA) or local
(Linux) devices
Max Laier wrote:
On Saturday 05 January 2008, lei wei wrote:
Max,
I don't quite understand "surrounding struct pflog_softc in #ifdef
_KERNEL.". Could you give me some more detailed instruction?
Thanks for the help.
See attached. Apply to either the installed version directly
(/usr/include/n
Fulko Hew wrote:
I'd still need a custom findalldevs() function that knew how to find
'local' devices as well as 'SITA remote' devices.
General support for remote capturing would need
1) a way to find hosts that support remote capturing (whether by
scanning the hosts file for SITA hosts, or
Joerg Mayer wrote:
Hopefully I've managed to do that in the attached patch.
Checked in, although:
- Clarify the multiple arguments case.
...
-Multiple arguments are concatenated with spaces before being parsed.
+Multiple arguments are concatenated with spaces before being parsed,
On Jan 9, 2008, at 2:04 PM, lei wei wrote:
I'm trying to get tcpdump work with DAG interface. I installed the
dag-enabled libpcap0.9.8 and tcpdump3.9.8 on a FreeBSD5.4 system.
When I
typed "tcpdump -i dag0", it gives me the error "tcpdump: BIOCSETIF:
dag0:
Device not configured". Could anyo
On Jan 9, 2008, at 3:37 PM, lei wei wrote:
I'm actually trying to get Argus working with DAG but argus still
can't read
anything from it. Do you have any experience on it?
No, I don't.
From a quick look at the source to Argus 2.0.6, it appears to be
assuming that you can do a select() on
On Jan 7, 2008, at 4:05 PM, Andy Howell wrote:
A 'capabilities' API could be useful. It would allow the developer
to take advantage of platform specific features in a generic way.
Capabilities might include:
Can get/set receive buffer size
Has nmap
Has pf_ring
Abeni Paolo wrote:
I have some concerns about more the "open a live capture" call[s]: in
the future it could be useful to set more parameters, so in the long run
there could be a proliferation of such call. A possible solution would
be to make the "open a live capture" call extensible, adding a
Abeni Paolo wrote:
I assume that the my initial suggestion is going to be dismissed, right ?!?
The extensible live-capture-open would be better (for one thing, a
global variable would have problems with multiple threads), but it might
be nice to get *something* into 1.0, so if we can't get t
Andy Howell wrote:
How about having a generic list of options? Something like:
typedef enum {
END_OF_OPTS,
PARAM_1,
PARAM_2,
} pcap_opts;
typedef union {
void *p;
unsigned int u;
} pcap_opt_value;
That assumes that an option will either be an "unsigned int" or a pointer
801 - 900 of 2513 matches
Mail list logo
