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
On Jan 6, 2008, at 12:54 PM, Guy Harris wrote:
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring
if a PF_RING socket were being used? That'd avoid some per-packet
checks in the read_op rout
Michael Richardson wrote:
What problem is the ultra-open parameter list supposed to solve?
1) allow open options to be added without having to change the signature
of the open-live routine, so that we don't have to anticipate all the
options that might ever want to be added.
2) allow a app
On Jan 13, 2008, at 3:33 PM, Michael Richardson wrote:
I.e. we should instead have a new pcap_open() call, and then we
should
have a serious of calls that set various options or ask for various
things based upon that handle.
Thus:
pcap_t pcap_open_live(char *device, int snaplen, int promis
Luca Deri wrote:
I have considered your suggestion to move pfring into a pcap-pfring.*
file.
I didn't make such a suggestion.
I did say
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring if
a PF_RING socke
Ian Brown wrote:
- I tried sniffing in various ways , like by "tcpdump -f vlan" and
"tcpdump -f vlan and net 192.168.0.0" and "tcpdump -f vlan and udp
port 9" and many other ways . on both sides,
(192.168.0.10 and the source machine , where pktgen runs) but I could
not catch any VLAN frames.
Ian Brown wrote:
It is 8139 (RTL).
Yes, but what interface name were you capturing on? eth0 (which I'm
assuming is the RTL 8139 adapter in question), or some other interface
(or pseudo-interface)?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Alfred E. Heggestad wrote:
I am wondering if there is a libpcap option to do automatic
reassembly of UDP/IP packets inside the library?
No. Libpcap is, by design and intent, a low-level library for capturing
and sending raw link-layer packets.
If not then
I guess the solution is to implem
Peter Memishian wrote:
> I mostly fixed the comment changes, thinking they were trivial and left
> other Sun cstyle error alone. I can see how it is distracting while
> reviewing the actual changes.
It's more than distracting -- it's incorrect. Code for libpcap follows
its own style
It
sagun shakya wrote:
I mostly fixed the comment changes, thinking they were trivial and left
other Sun cstyle error alone. I can see how it is distracting while
reviewing the actual changes. I've undone such changes and posted a new
webrev at:
http://cr.opensolaris.org/~sagun/libpcap/
pcap
On Feb 1, 2008, at 10:10 AM, Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question for those more knowledg
On Feb 1, 2008, at 12:47 PM, sagun shakya wrote:
Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question
Alexander 'Leo' Bergolth wrote:
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause some displacement of the
frames, starting with the first captured frame, when using the "any"
interface.
So by "the same patch" are you referring
Abeni Paolo wrote:
*) If pcap_loop is called with cnt=0 (ngrep erroneously does that), it
will busy-loop forever. pcap_read_linux_mmap doesn't handle that case,
it returns 0, which is asymmetric to pcap_read_linux's behavior, which
reads one packet.
I think there is a little confusion about th
Alexander 'Leo' Bergolth wrote:
Sorry, I wasn't aware of the ambiguity...
It's an obscure ambiguity, but I just wanted to make sure.
I've checked your typo fix in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Alexander 'Leo' Bergolth wrote:
Hi!
On 01/31/2008 02:39 PM, Abeni Paolo wrote:
on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
I just gave your new linux mmap patch a try
thanks for the review :-)
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately
Guy Harris wrote:
*However*, unless I'm missing something, a pointer to the payload after
the SLL header is being passed to the callback;
...
I'll try it out on my Ubuntu "machine"
That appears to have been the problem; I checked in a fix that made it
work,
Abeni Paolo wrote:
Any comments are as usual very welcome.
So far, I have it compiling and working on:
Mac OS X 10.4
Mac OS X 10.5
FreeBSD 7.0 RC1
OpenBSD 4.2
Ubuntu 7.10
where "working" includes an additional pcap_set_rfmon() call to turn on
moni
BTW, my original tests of the monitor mode changes didn't work on
FreeBSD or OpenBSD, because the adapter was added when I plugged it
into the USB bus, but wasn't automatically brought up. I had to do
"ifconfig zyd0 up" to make it work.
If libpcap can determine that an adapter isn't up, sh
It's 2008. Should we enable IPv6 support by default in libpcap and
tcpdump (as long as the OS supports IPv6 to a sufficient extent that we
can compile the support in), and let users do "--disable-ipv6" if, for
whatever reason, they don't want it?
-
This is the tcpdump-workers list.
Visit https
Gert Doering wrote:
tcpdump is not actually *doing* any IPv6.
It's doing IPv6 name resolution.
However, as tcpdump no longer depends on the OS to provide headers that
define the formats of packets, that might reduce the dependency on OS
IPv6 support.
(I can do tcpdump to look at "spannin
Carter Bullard wrote:
Are you going to make it so that the routines in inet.c, such as
add_addr_to_iflist()
and pcap_lookupnet() can work with IPv6 addresses?
add_addr_to_iflist() appears to work with IPv6 addresses on my OS X
10.4.11 machine, as pcap_findalldevs() finds the IPv6 addresses fo
Carter Bullard wrote:
I think the point is that you shouldn't have routines that are 'inherently'
limited to IPv4 addresses, if you support IPv6.
Removing pcap_lookupnet() would break source and binary compatibility.
I suppose libpcap 1.0 could, in theory, break both, so we could perhaps
get
Abeni Paolo wrote:
I thought that such things (pcap API to ask for supported parameters)
could be implemented adding dedicated fields into the pcap struct (on in
a pcap_t sub structure), which must be set by the platform specific
pcap_activate().
That would mean you couldn't ask for supported
On Feb 8, 2008, at 11:38 AM, Guillermo Hurtado wrote:
This is the first time I write to this list. I just read a post
about the
behavior of function pcap_lookupdev().
Now I wonder: what if I have two or more (2...N) Ethernet NICs
installed in
my computer and I want to retrieve the name of t
On Feb 7, 2008, at 4:42 PM, Hagen Paul Pfeifer wrote:
pcap_getnonblock_mmap() and pcap_setnonblock_mmap() declaration
differs from
prototype declaration and defines them !static. This patch fix this
issue.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
Visit h
Luca Deri wrote:
is there any chance to see PF_RING support in libpcap source tree?
Please let me know if I can do something in order to push this process.
I'd sent a message to tcpdump-workers on 2008-01-24 with the subject
line "Re: [tcpdump-workers] Libpcap reentrancy and PF_RING patch", w
Paolo Abeni wrote:
On Mon, 2008-02-11 at 01:20 -0800, Guy Harris wrote:
What's the advantage of requiring that
pcap_get_monitor_mode_availability() be called after pcap_activate()?
This way all the platform/device dependent code can be placed into
pcap_activate(), elsewhere we have to
Paolo Abeni wrote:
Perhaps I'm missing the point, but I think a similar situation
currently happens in the pcap_findalldevs() function, which ultimately
calls pcap_open_live()/pcap_close() for each discovered device.
That's an implementation detail; if there were a way of determining
whether
Christian Stalp wrote:
And now the first weired thing: if I check my interface for ethernet
it passes, if I check for wlan it fails!
I infer from the name "ath0" that this is *BSD.
If so, then all 802.11 devices default to providing Ethernet headers,
for compatibility with applications that
On Feb 15, 2008, at 4:52 AM, Christian Stalp wrote:
But the result is the same. Its still the first four fields of my
MAC-address but the final two are still trash.
I.e., the first four octets of the source MAC address are valid and
have the correct values (i.e., they match the MAC address
On Feb 15, 2008, at 2:15 AM, Christian Stalp wrote:
I changed my capture-routine this way:
void packet_default(u_char *args, const struct pcap_pkthdr *header,
const u_char *packet)
{
char insertvalues[256];
memset (insertvalues, 0x0, 256 );
//struct ieee_802_11_heade
On Feb 8, 2008, at 2:20 PM, Eric wrote:
2. I've downloaded/compiled flex-2.5.34, bison-2.3, and
libpcap-0.9.8 [in /usr/local] beforehand.
3. When attempting to compile tcpdump-3.9.8 I get the following error:
==
/usr/local/lib/libpcap.a(pcap.o): In function
`pcap_datalink_name
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+ # libraries does not inclu
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Why did you add a
AC_CHECK_HEADERS(sys/bufmod.h)
check to configure.in after the check for libdlpi? It's checked for
later in the case statement if
sagun shakya wrote:
I agree, I'll add this to the configure script of tcpdump. This would
also be applicable for wireshark then?
Yes, and probably Snort and other apps using libpcap.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
801 - 900 of 2494 matches
Mail list logo
